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 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 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 live-coding is highly relevant to the job. A frontend engineer fixing a real bug in a React component is useful — that's Monday's work. A backend engineer tackling a real API design problem is also useful. Make the exercise resemble actual work, not a competitive programming round.
Most companies don't do this. They ask "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 — time, no pressure, real work. They test how much time the candidate will 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 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 is useful when it's short and clearly bounded — "spend two hours, send what you have, we'll discuss" — and when 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.
They intend to assess team compatibility. They usually involve vague questions, vague answers, and a vibe-based assessment that correlates with "did they remind me of myself." This leads to homogeneous teams. The data on culture-fit interviews is brutal — low predictive validity, high bias, and often the deciding factor in offers, which is the worst combination.
To assess culture, use structured questions 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 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 common failure mode in 2026, despite bootcamps). It's cheap. The signal is limited but the cost is also limited.
What actually works.
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. It's a conversation between engineers about a problem.
Look for: clear thinking, good questions, comfort with ambiguity, engagement with the problem, real engineering conversation.
Don't look for: 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. Pre-defined questions: "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."
Questions are about specific past situations, not hypotheticals. (Hypotheticals are nearly useless — people perform their best self in hypotheticals.) Listen for: ownership of failures, articulation of learning, honest reflection on contributions and mistakes, specificity, ability to name collaborators and their contributions.
This is the highest-signal interview I've found. Structured behavioral interviews have the best predictive validity of any standard format. Most companies skip this for another 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 emerge. They talk fluently about real systems they built, articulate tradeoffs, know what went well and what didn't, and are honest about the messy parts.
The catch: candidates who can't share their work (because it's 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 controversial. 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 behave when problem-solving, when stuck, when collaborating.
Advantages: by far the strongest signal. It's what they'll do if hired. Bias-reduction is huge because everyone operates in the actual context. We've identified great hires and bad fits much earlier with this.
Disadvantages: candidates with jobs can't always do this. Candidates we don't hire still get paid, which costs 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'll accept elsewhere. Compress the loop. From first call to offer should be under two weeks for senior hires, under one week for hot candidates. 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 assumed, and the cost is low. 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. Identify this in the portfolio review and 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.
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 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 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.