I've hired hundreds of engineers over fifteen years across two companies and advisory roles. I've reviewed hiring processes at two dozen others. The standard interview loop most companies run is mostly noise — it identifies whether the candidate can prepare for the format, not whether they can do the job. Engineers who aced our process turned out mediocre. Engineers I almost passed on turned out exceptional. The interview poorly correlates with on-the-job performance, yet we keep running the same broken process.
Here's what's broken and what works.
Whiteboard coding and live-coding interviews mostly don't work.
They claim to test clear thinking and coding under pressure. In reality, they test if the candidate spent the last three weekends on LeetCode. The questions are algorithmic puzzles unrelated to the job. The pressure is artificial. The signal is whether the candidate prepared, not whether they're good.
The exception is when the live-coding session is highly relevant to the actual job. If you're hiring a frontend engineer and give them a real bug in a React component to diagnose and fix, that's useful — that's Monday's work. If you're hiring a backend engineer and present a real API design problem with real constraints, also useful. The trick is making the exercise resemble actual work, not a competitive programming round.
Most companies don't do this. They give "reverse a linked list" or "two-sum" because it's easy to administer and grade. The candidate studies for that format, gets the offer, and never reverses a linked list at work. The hire was selected for the wrong skill.
Take-home tests are mostly worse, despite better optics.
Take-homes look better — the candidate has time, no pressure, can show real work. The problem is they test how much time the candidate is willing to spend on a speculative interview. Senior engineers with options decline four-hour take-homes for uncertain jobs. Junior engineers desperate for a job spend twenty hours and over-deliver. The take-home thus selects against the people you most want to hire.
Calibration is also an issue. The take-home is graded by whichever engineer reviews it, and "good" varies wildly. The same submission could pass or fail depending on the reviewer. The bar moves.
A take-home can be useful when it's short and clearly bounded — "spend two hours on this, send what you have, we'll discuss" — and when it's used as discussion fuel rather than a pass/fail gate. Beyond two hours, the cost to the candidate exceeds the signal you'll get.
"Culture fit" interviews are usually a hidden bias machine.
The intent is to assess team compatibility. The execution is usually a conversation with vague questions and answers, leading to a vibe-based assessment that correlates with "did they remind me of myself." This is how teams end up homogeneous in unintended ways. The data on culture-fit interviews is brutal — low predictive validity, high bias, often the deciding factor in offers. The classic meta-analysis here is Schmidt & Hunter, The Validity and Utility of Selection Methods in Personnel Psychology (1998), which found work-sample tests and structured interviews outperform unstructured "vibes-based" conversations.
To assess culture, use structured questions, ideally about specific past situations. "Tell me about a time you disagreed with a teammate about a technical decision" is better than "are you a team player?" Structured behavioral questions are tedious to ask, but the signal is better, and the bias is reduced.
Coding screen as a phone interview is fine if it's calibrated.
A 45-minute phone or video coding screen with a focused, realistic problem is a reasonable first filter. It catches candidates who can't code at all (a real and common failure mode in 2026, despite all the bootcamps). It's cheap. The signal is limited but the cost is also limited.
What actually works.
After trial and error, here's the loop I converged on at Mayven and refined at Capital One.
Step one: a realistic, scoped technical conversation. Forty-five minutes, video call, a senior engineer on our side. The candidate is given a small, realistic problem — usually a system design or a debugging walkthrough relevant to the role. The interviewer is engaged — they ask clarifying questions, push on assumptions, share constraints, take the conversation in interesting directions. This is not a pop quiz. It's a conversation between engineers about a problem.
What you're looking for: does this person think clearly? Do they ask good questions? Are they comfortable with ambiguity? Do they engage with the problem or perform a memorized answer? Can they navigate a real engineering conversation?
What you're not looking for: whether they got the "right" answer. Most realistic problems don't have one. The answer is in the thinking.
Step two: a structured behavioral interview. Forty-five to sixty minutes, video, ideally with someone other than the technical interviewer. The questions are pre-defined: "tell me about the most ambitious thing you've shipped." "Tell me about a time you were wrong about a technical decision." "Tell me about a conflict with a teammate and how it resolved." "Tell me about a project that failed and what you took away."
The questions are about specific past situations, not hypotheticals. (Hypotheticals are nearly useless — people perform their best self in hypotheticals.) You're listening for: do they take ownership of their failures? Are they able to articulate what they learned? Do they reflect honestly on their own contributions and mistakes? Are they specific or vague? Can they name the people they worked with and what those people contributed?
This is the highest-signal interview I've found. Structured behavioral interviews have the best predictive validity of any standard interview format. Most companies skip this in favor of one more coding round, which is exactly backwards.
Step three: a portfolio review. Sixty minutes, video, with a small group. The candidate shows real work. A GitHub repo they wrote, a system they designed, a project they led, a problem they solved. They walk through what they did, why, what was hard, what they'd do differently.
This is where senior engineers really emerge. They can talk fluently about real systems they built. They can articulate tradeoffs. They know what went well and what didn't. They are honest about the messy parts.
The catch: candidates who can't share their work (because everything they've done is proprietary) need an alternate path. The alternate is a deep technical conversation about a hypothetical system — "tell me how you'd build this thing for our company." It's not as good as real work but it's close.
Step four: a working session. This is the controversial one. For senior hires, I want them to work with us — for a half day, a day, or sometimes two days — on a real problem we have. We pay them for the time. We work alongside them. We see how they actually behave when they're problem-solving, when they're stuck, when they're collaborating.
The advantages: this is by far the strongest signal. It's what they'll actually be doing if we hire them. The bias-reduction is huge because everyone is operating in the actual context. We've identified great hires and we've also identified bad fits much earlier with this.
The disadvantages: candidates with current jobs can't always do this. Candidates we don't end up hiring still got paid for their time, which costs real money. Not all candidates are willing.
For roles where a working session is feasible, I run it. The hit rate is substantially higher.
A few smaller things that matter.
Speed of process. A great candidate has multiple offers. If your process takes three weeks, they will accept somewhere else. Compress the loop. From first call to offer should be under two weeks for senior hires, under one week for hot candidates. The companies that consistently win on hiring have fast processes.
Reference checks are underrated. Talk to two or three people who worked with the candidate, ideally including someone they reported to and someone who reported to them. Ask specific questions. The signal here is much better than people assume, and the cost is low. The candidates who lie or exaggerate are usually filtered out at this stage if you actually do the calls.
Stop relying on resumes. Resumes have always been weak signal. They are now near-noise — LLMs polish them, the average resume is far better written than the candidate is. A candidate's portfolio, GitHub, technical writing, talks, or open-source work tells you much more than a resume.
Stop discounting non-traditional backgrounds. The best engineer I ever hired was a self-taught former teacher with no CS degree. The worst was an MIT graduate with all the right credentials. Your interview process should evaluate on what they can do, not where they went to school or how many years they've been doing it.
Look for taste. This is hard to measure but matters enormously. Does this person have opinions about technology? Are those opinions informed? Can they tell good code from bad? Do they care about craft? Engineers with taste write better code, mentor better, and make better technical decisions. Try to identify this in the portfolio review and the technical conversation.
Reject quickly and respectfully. The candidates you don't hire still talk about your company. Make the rejection fast (within days), specific where possible (don't pretend "we went with another candidate" if the real answer is "you didn't pass the bar"), and respectful. The way you treat candidates who don't make it is the most visible signal of your engineering culture to the market.
AI-tool fluency is now part of the bar, but not the way most companies are testing it. A senior engineer in 2026 who hasn't fluently integrated Claude Code, Cursor, Codex, or equivalent into their daily workflow is probably 2x slower than peers who have. The cost of code is going to zero, and the engineers who treat that as a fact rather than a fad are the ones worth hiring. The trap in assessing this: do not ban AI tools in interviews. That's the modern equivalent of banning a search engine in a 2010 interview — you're filtering for people who pretend not to use the standard toolkit, not for people who use it well. Instead, watch them use the tools in the working session. Do they prompt well? Do they catch the model's mistakes? Do they know when to take over and when to delegate? That signal is much richer than whether they can solve a problem from scratch on a whiteboard.
The hardest skill to hire for, by far, is judgment. The ability to make good decisions when constraints are unclear, when tradeoffs are subtle, when the data is incomplete. This is the senior engineer's actual job, and it's the thing whiteboard coding tests not at all and structured interviews barely touch. The portfolio review and the working session are the best surfaces for it. If you have to choose what to optimize the hiring loop for, optimize for judgment.
Hiring engineers is the highest-leverage thing an engineering leader does. A great hire compounds for years. A bad hire compounds, also, in the wrong direction. Spend the time. Run the better process. The ROI is enormous.