The Interview Starts Before the First Question

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 interviews. The interviewer should remove unnecessary uncertainty, not create a psychological escape room. You are not there to surprise people. You are there to evaluate them.

Resume Monologues Are Weak Signal

Many companies begin by asking candidates to walk through their experience. That is not a terrible start, but it becomes useless very quickly.

Candidates practice this part. They have said the same thing dozens of times. Sometimes hundreds. They know which projects sound impressive. They know where to pause. They know how to make a simple CRUD app sound like the control system for a space mission.

Digging too much into past experience also creates bias.

If a candidate says something worrying, your brain may anchor on it and ruin the rest of the interview. If they say something impressive, your brain may become too generous. Either way, you are not evaluating clearly anymore.

Some classic interview questions are especially weak:

"What is a mistake you made, and how did you solve it?"

Most candidates are prepared for that question. Many will give a polished answer that is technically true but practically useless. You will hear stories about harmless mistakes, minor bugs, and learning moments. You will almost never hear, "Yes, I migrated the finance database incorrectly and lost the company $10 million." People make mistakes every day. Some mistakes come from incompetence. Some come from uncertainty. Some come from bad process. Some come from unclear ownership. The question rarely gives you enough signal to know which is which.

Also, modern tooling and AI assistants can reduce some low-level mistakes, especially syntax errors, boilerplate issues, and obvious omissions. But they do not eliminate bad judgment. They do not replace architecture. They do not make weak engineers strong. They mostly make weak engineers faster at producing questionable code.

That is not hiring signal. That is just a faster printer.

Bootstrapper vs Engineer

The first thing I try to understand is whether I am speaking with a bootstrapper or an engineer. A bootstrapper is someone who can make things run. They can install a framework, follow a tutorial, connect a few libraries, and push something that works well enough for a demo.

That has value. Many products start that way. But a bootstrapper is not necessarily an engineer.

An engineer understands systems. An engineer can reason about tradeoffs. An engineer asks why something should be built a certain way, not only how to make it appear on the screen. An engineer can evaluate technologies, constraints, failure modes, and long-term maintenance. Good engineers solve problems. Strong engineers design solutions. Great engineers enable entire teams to move faster without creating a junkyard of future pain.

Bootstrappers are often very vertical. They depend heavily on other people’s tools and patterns. They rarely leave their comfort zone. They can be productive inside familiar stacks, but when the problem moves outside the happy path, they get lost. This is why I do not start by asking only language-specific trivia. I start by asking about the business.

Did the candidate research the company? Do they understand what we do? Do they understand the industry? Do they know our competitors? Can they explain our product back to us in simple terms?

Most candidates do not do this. And by "most," I mean a shocking percentage. Somewhere around "please tell me you at least opened the website" levels.

Then I move into systems, design patterns, data flow, APIs, reliability, and architecture. Not because every candidate must be an architect, but because I need to know whether they understand software beyond the framework they used last Tuesday.

The Live Coding Session Is Not a Circus

Live coding is controversial. Some candidates hate it. Some companies abuse it. Some interviewers turn it into a humiliation ritual, which is both useless and stupid. But when done correctly, live coding is one of the best tools an interviewer has. A live coding session is like joining a military unit after claiming you know how to shoot. Someone hands you the rifle and says, "Great, hit that target." If you have never touched one before, everyone knows immediately.

Software is similar.

A candidate can say they know TypeScript, Node.js, Java, Go, React, distributed systems, dependency injection, design patterns, and microservices. Then the exercise starts, and within minutes you see the truth.

Not because the exercise is hard. Because the basics are missing.

Common patterns appear again and again:

• The candidate reads the exercise too fast.
• They start coding before understanding the problem.
• They do not ask clarifying questions.
• They assume there are no edge cases.
• They focus on syntax before the algorithm.
• They spend too much time on irrelevant setup.
• They do not write down the rules.
• They do not verify the output.
• They are afraid to open official documentation.
• They try to bluff through confusion.

This is not about catching people. It is about observing how they work. Do they understand the problem? Do they restate it? Do they ask what should happen with invalid input? Do they identify edge cases? Do they write a small algorithm before coding? Do they test their own solution? That is signal.

Do Not Worship LeetCode

I do not like starting with LeetCode style exercises. Candidates practice those. They memorize patterns. They solve binary trees at midnight like medieval monks copying manuscripts. That can be useful for some roles, but it is not always the best hiring signal. For many engineering roles, especially backend, full-stack, platform, product engineering, and internal tools, I prefer small practical exercises.

Start simple. Then build on top of it.

The exercise should reveal whether the candidate understands:

• Data structures
• Control flow
• Ordering rules
• Defensive thinking
• Naming
• Function boundaries
• Testing
• Edge cases
• Communication

The rules should be simple:

• Use your preferred editor.
• Use your preferred programming language.
• Disable coding assistants.
• You may use official documentation.
• Explain your thinking.
• Ask questions when something is unclear.

That last rule matters. A candidate who asks good questions is usually safer than a candidate who starts typing immediately like the keyboard owes them money.

Basics Matter More Than People Admit

I once asked a candidate, "Do you know what an array is?" The candidate said yes. Then I asked them to explain it. The answer was a cloud of unrelated words floating around the concept of an array without ever landing on the runway. This happens more often than people want to admit.

Many developers use tools they do not understand. They use TypeScript without understanding types. They use databases without understanding indexes. They use React without understanding rendering. They use distributed systems vocabulary without understanding failure.

This is a problem because weak fundamentals become expensive inside a team. People who do not understand basics will avoid making decisions. They will wait for instructions. They will become what my CEO would call "order-taker developers": people who do not move unless someone tells them exactly what to do.

You do not want too many order-takers on an engineering team. You want people who can think, challenge, clarify, and propose.

Preparation Is a Signal

Preparation starts before the interview. Did the candidate join on time? Did they join a few minutes early? Is the camera working? Is the microphone working? Is the room quiet? Is the internet connection stable? Is their development environment ready? Most candidates underestimate how much this matters.

They show up late. The camera is off. The microphone does not work. The browser cannot access the meeting. The coding setup is broken. Then the explanations begin.

"My internet is acting weird."

"My webcam was working yesterday."

"This is my personal computer."

"I normally use another machine."

Of course, sometimes life happens. We all know that. But repeated lack of preparation is not bad luck. It is a pattern.

I once interviewed a backend developer for a Node.js and TypeScript role. During the live coding session, I asked for a decorator exercise.

• First problem: Node.js was not installed.
• Second problem: the candidate did not know how to install Node.js.
• Third problem: TypeScript was not installed.
• Fourth problem: decorators were not configured.
• Fifth problem: after 15 minutes of setup pain, it became clear the candidate did not know what a decorator was.

That was not an environment issue. That was the interview politely removing the mask.

Why Node.js, TypeScript, and Decorators Are a Good Test

This example exposes a common misunderstanding. Installing Node.js does not automatically give you a complete TypeScript development environment.

Modern Node.js can execute some TypeScript files through type stripping, but that is not the same as having a full TypeScript toolchain. It does not replace the TypeScript compiler. It does not perform full type checking. It does not behave like a complete project build. It does not automatically honor every setting in tsconfig.json. And it does not transform language features that require compilation.

Decorators are a good example.

TypeScript has supported legacy decorators for years through compiler options such as experimentalDecorators. Many backend frameworks, including NestJS, rely heavily on decorators and sometimes require metadata support through options such as emitDecoratorMetadata and packages such as reflect-metadata.

On top of that, TypeScript 5 introduced support for the newer decorators model, which behaves differently from legacy decorators. In other words, "I know TypeScript decorators" is not a small claim. It is not just putting an @ sign above a class and hoping the runtime gets inspired.

In normal human language: if you are interviewing for a TypeScript backend role and the exercise involves decorators, you should not be discovering your setup during the interview.

That is like showing up to a cooking interview and asking where they keep the fire.

Watch How Candidates Answer

One of the strongest signals in an interview is how the candidate answers questions. Good candidates answer the question. Weak candidates answer a nearby question, then keep walking.

If you ask, "What does your current product do?" a strong answer sounds like this:

"The product helps small businesses manage employee scheduling and payroll from one dashboard."

Simple. Clear. Business-first. A weak answer sounds like this:

"We use React, Node, Kafka, PostgreSQL, Redis, Kubernetes, and we are migrating some services into..."

Stop.

That may be technically relevant later, but it did not answer the question. If a candidate cannot explain the product, they may not understand the business. If they do not understand the business, they are probably solving local technical tasks instead of real company problems.

The same applies to role questions.

If you ask, "What is your current position and what are your responsibilities?" a good answer is direct:

"I am a senior backend engineer. I own the payments module, including architecture, implementation, documentation, and production support."

That gives signal. A bad answer is a five-minute monologue that sounds like someone is reading the back of an enterprise software brochure. If the candidate starts ranting, interrupt politely. Bring them back.

"Let me stop you there. I am asking specifically about your responsibilities, not the full project history."

This is not rude. It is necessary. Interviews are not podcasts.

Candidates Should Admit What They Do Not Know

A candidate should never say "yes, I know that" when the real answer is "I have heard of it."

There is a professional way to say it:

"I am familiar with the concept, but I have not used it in production."

That is a good answer.

It tells the interviewer where the boundary is. It also avoids the classic disaster where the candidate says yes, then immediately collapses under the first follow-up question. Good interviewers will catch false confidence quickly. If a candidate claims to know Rust, TypeScript decorators, database indexing, distributed queues, OAuth, or Kubernetes, the next question will reveal whether that knowledge is real.

It is much better to be honest. Nobody knows everything. But pretending to know everything is a reliable way to prove you do not know enough.

The Candidate Side: Research the Company

Now let us switch sides because I want you all land a good job position. If you are looking for a job, the first thing to understand is that not every company is worth your time.

Research the company.

Research the product. Research the market. Research the leadership. Research the funding. Research the competition. Research the engineering blog if they have one. Research the people interviewing you. This prepares you for the interview, but it also protects you. A job interview is not only the company evaluating you. You are evaluating them.

As an executive, I do a lot of research before entering a business relationship. Candidates should do the same. You do not want to join a company and discover two weeks later that the architecture is a landfill with a login screen.

At some point in the interview, you will probably be invited to ask questions. This is not a decorative moment. It is not the part where you politely say, "No, I think you covered everything," and disappear into the pile of forgettable candidates.

Ask real questions.

A good engineer asks about the problems the company is trying to solve. Ask about the current technical challenges. Ask about scale, reliability, architecture, delivery process, product strategy, code ownership, incident response, and how decisions are made.

For example, if they say, "We are having trouble scaling our API versioning," do not jump into professor mode and start educating them like you discovered software yesterday. Ask follow-up questions:

"Where is the main pain today? Routing complexity, backward compatibility, client migrations, documentation, or deployment coordination?"

That kind of question shows expertise without arrogance. You can also share relevant experience carefully:

"I have dealt with something similar before. We moved toward clearer module boundaries and route versioning, and it allowed us to run multiple API versions on the same instance without making every release painful."

That is useful. That is respectful. That shows you are thinking about their problem.

What you should avoid is turning the interview into a consulting session where you diagnose their architecture after 14 minutes and two vague sentences. Nobody enjoys being told their house is on fire by someone standing outside with binoculars. Good questions also show business awareness. Ask what customer problem the product solves. Ask what market pressure they are facing. Ask what makes the product hard to build. Ask what success looks like for the role after six months.

If you demonstrate that you researched the business, even without being an expert in the industry, you send a strong signal: you care about more than finishing Jira tickets. That matters.

Your Resume Is Part of the Interview

Your resume should be clean, clear, and accurate. No spelling mistakes. No fake expertise. No endless list of technologies you touched once in 2018 during a panic sprint. No inflated claims that collapse when someone asks a basic question.

If your resume says TypeScript, you should understand TypeScript.

If your resume says PostgreSQL, you should understand indexes, joins, constraints, transactions, and query plans at a reasonable level.

If your resume says architecture, you should be able to discuss tradeoffs without turning into a motivational poster.

Also, have code ready to show when appropriate. It does not need to be your employer’s private code. It can be personal projects, open-source contributions, experiments, libraries, or technical writing. Real work tells a story that a resume cannot.

Your Setup Tells a Story

Your interview setup matters. You do not need a Hollywood studio. You do need to look and sound like someone who knows how remote work functions.

Have:

• A quiet room
• Good lighting
• A decent webcam
• A good microphone
• A stable internet connection
• A working editor or IDE
• Your development stack ready
• The meeting software tested

Do not use terrible audio. Do not rely on laptop microphones if you can avoid it. Do not make the interviewer listen to keyboard explosions, room echo, or your neighbor’s dog participating in system design. Invest in your gear. Engineers spend thousands of hours in front of computers. If your tools are bad and you do not care, that tells me something. Maybe not everything, but something. A good engineer usually has a capable machine, a reliable setup, and the ability to start coding quickly.

If the interview starts and you need to install your own stack from scratch, you are already losing signal.

Learn Before Someone Pays You To Learn

The best engineers I have met are constantly learning. They do not wait for a project to require Rust before opening a Rust book. They do not wait for a production incident to learn observability. They do not wait for a database migration to understand transactions. They explore. They build. They read documentation. They test ideas. They compare tools. They break things locally so they do not break them in production. This matters because engineering is not only a job. It is a trade. You can do the job without loving the trade, but there is a ceiling. At some point, curiosity separates people.

If you only learn when assigned a ticket, you will always be late.

Practice Interviews

Practice answering questions. Not fake answers. Clear answers. This helps more than most candidates imagine. The first time you do a serious job interview, it is normal to derail. You may over-explain. You may forget obvious examples. You may answer a simple question with a ten-minute historical documentary. Then, after enough interviews, your ideas become sharper because you have repeated them, tested them, and cleaned them up.

Do not wait until interview number 20 to become clear.

Start earlier.

Practice does not mean memorizing scripts. Scripts are dangerous because good interviewers will break them quickly. Practice means learning how to express your real experience with structure, precision, and context. A candidate should be able to explain their current product in one or two clear sentences. Not the stack. Not the deployment pipeline. The product.

For example:

"The product helps logistics companies track shipments, predict delays, and communicate delivery changes to customers."

That is clear. After that, you can explain the architecture, your responsibilities, the technical challenges, and the tradeoffs. But if you cannot explain the product first, the interviewer will wonder whether you understand the business at all.

You should also practice explaining your role without hiding behind vague language.

Bad answer:

"I work with the backend team on different things and support several initiatives."

Better answer:

"I am a senior backend engineer. I own the billing service, including API design, database modeling, integrations with payment providers, production support, and technical documentation."

That answer gives shape. It tells the interviewer what you actually do.

You should practice explaining systems you have owned. Pick two or three real examples from your experience and prepare them properly. For each one, know the business problem, the constraints, your role, the architecture, the tradeoffs, the mistakes, the result, and what you would improve today. That last part matters. Strong engineers can look back at their own work and say, "This was good for that stage, but today I would change this." Weak engineers defend every past decision like it was written on stone tablets.

Practice technical explanations too. Take basic concepts from your trade and explain them out loud: what an array is, how an index works, what a transaction is, what dependency injection solves, why caching is hard, what makes distributed systems fail, how authentication differs from authorization. If you cannot explain a concept simply, you probably do not understand it well enough. Or you understand it, but your communication is not ready. Both are problems in an interview.

Live coding also needs practice. Do not only practice solving the problem. Practice the behavior around the problem.

Read the prompt slowly. Restate it. Identify inputs and outputs. Ask clarifying questions. Write down edge cases. Sketch the algorithm. Then code. Then test.

That sequence alone separates many strong candidates from the chaos crowd.

You can also practice with another engineer. Ask them to interrupt you. Ask them to challenge your assumptions. Ask them to change one requirement halfway through the exercise. That is uncomfortable, but useful. Real interviews are not quiet laboratory conditions. They involve pressure, questions, and sometimes a person staring at your screen while you forget how to spell length.

Record yourself if you can tolerate the pain. Most people hate watching themselves, which is fair. Nobody opens a recording of themselves and thinks, "Finally, cinema." But it works. You will notice filler words, rambling, unclear explanations, bad pacing, and moments where you look less confident than you feel.

Interviewers should practice too.

When I started interviewing people, I was not good at it. I knew technology, but knowing technology is not the same as running a clean interview. It took many interviews to become fluent at asking questions, stopping rants politely, detecting weak signal, and keeping the process useful. A good interviewer practices the same way a good candidate does. Prepare the structure. Prepare the exercises. Prepare follow-up questions. Know what signal you are trying to get from each part. Do not improvise the whole thing and call it instinct.

Practice makes interviews less random. And randomness is the enemy of hiring.

A Note About Cheating

Interviewers also need to be aware of candidate cheating tools. Some candidates use AI assistants on a phone next to the screen. Some read from another monitor. Some hide prompts. Some try to use blurred webcams or suspicious camera angles. You can often tell.

The candidate’s eyes move strangely. Their answers arrive with odd delays. Their tone changes. They suddenly produce a perfect explanation but cannot explain one line of it. They answer a slightly different question than the one asked. A simple way to detect this is to ask follow-up questions that require context from the conversation. Another is to slightly change the problem. Or ask them to explain why they chose one approach over another. If you are confident the candidate is cheating, end the interview politely.

The role is for capable people, not for people auditioning to become a second monitor.

Final Thought

Engineering interviews should not be random. They should not reward memorized scripts, fake confidence, or framework tourism. They should reveal how a person thinks, prepares, communicates, and solves problems under realistic constraints. For interviewers, the job is to design a process that produces signal. For candidates, the job is to show preparation, clarity, honesty, and real technical ability.

The interview starts before the first question.

By the time someone asks you to code, explain a system, or describe your product, the signal is already there.