The Interview Starts Before the First Question - Minid.net<br>June 14, 2026<br>The Interview Starts Before the First Question

After interviewing more than a thousand engineers over 27 years, I have learned that great hiring is not about clever questions, resume theater, or gut feeling. It is about structure, signal, preparation, and the ability to separate people who can merely make things run from people who can actually think, design, debug, and own complex systems. This article is a practical, opinionated guide for interviewers and candidates who want engineering interviews to be less random, less theatrical, and far more useful.<br>Why Engineering Interviews Fail So Often

If you want to get better at interviews, either as an interviewer or as a candidate, here is the uncomfortable truth: most interviews are badly designed.

I have interviewed more than 1,000 engineers during my career. That kind of repetition gives you a strange superpower. After a while, you begin to recognize patterns very quickly. In many cases, I can tell within the first 10 minutes whether the interview is going in the right direction.

But that does not mean I trust "gut feeling."

Gut feeling feels great when it works. It makes you feel like a talent wizard. You look at a candidate, ask a couple of questions, and think, "Yes, this person gets it." Then, three months later, you are debugging not only their code, but also your hiring process. Gut feeling is useful as a signal, but it is dangerous as a decision-making system. It is subjective. It is biased. It is inconsistent. It rewards charm, confidence, and rehearsed answers. It can also punish quiet, careful engineers who may be excellent but do not perform like TED speakers.

The goal of an engineering interview is not to find someone who sounds impressive. The goal is to find someone who can think.

The Interviewer Can Ruin the Interview

Let us start with the interviewer, because this part is often ignored. A bad interviewer will ruin the interview. It does not matter how good the candidate is. If the interviewer does not know how to assess the role, the process becomes noise. You cannot properly interview someone for a technical role if you are not strong enough in the subject matter. This does not mean you need to know every framework, every syntax detail, or every library version. It means you need to understand the domain well enough to separate real competence from memorized vocabulary.

For engineering roles, that usually means understanding:

Software design

Systems thinking

Data modeling

APIs

Debugging

Testing

Security basics

Performance tradeoffs

Team collaboration

Product context

Delivery under real constraints

A CTO, CEO, founder, or hiring manager who does not have enough technical depth should not pretend otherwise. Bring stronger people into the interview. Use wingmen. Let different people assess different areas. There is no shame in that. The shame is hiring badly because you wanted to look like the smartest person in the room.

Another responsibility of the interviewer is to actively invite questions from the candidate, not only at the end but sometimes during the interview as well. Good candidates evaluate the company just as much as the company evaluates them. The questions candidates ask often reveal more than their answers. If a candidate repeatedly avoids asking questions, claims they already know everything they need to know, or shows no curiosity about the company, the product, the team, or the challenges ahead, that is a warning sign. Likewise, if their first and only questions are about salary, perks, vacation days, or "can you explain what the project is about?" despite having applied for the role and accepted the interview, that usually demonstrates poor preparation.

Compensation matters. Benefits matter. Nobody works for applause and warm office lighting. But candidates who never move beyond those topics are usually telling you something important: they are evaluating a paycheck, not an opportunity.

A Good Interview Needs Structure

A bad interview can fail in 10 minutes. A good interview usually takes around one hour. A great interview can take two or three hours, depending on the seniority of the role and the complexity of the position. Length alone does not make an interview good. I have seen long interviews that produced almost no signal. I have also seen short interviews that were brutally clear because the interviewer knew exactly what to test. Before asking questions, the interviewer should explain the structure of the interview. Not a 20-minute lecture. Just enough context so the candidate knows what is coming.

For example:

First, we will talk about your background and current role.

Then, we will discuss system design and engineering judgment.

After that, we will do a short live coding exercise.

At the end, you can ask questions.

This matters because candidates are anxious. Even excellent engineers can become nervous in...