One-way interview questions for software engineers, with model answers

A one-way interview for a software engineer is a recorded screening step. You answer a fixed set of questions on video or audio, on your own schedule, with no interviewer present. For engineers it is almost always behavioral, plus a verbal walkthrough of how you would approach a problem. It is rarely live coding. A hiring team reviews it later.

The native term for this is a one-way interview, also called an on-demand or pre-recorded interview. If the invite came from HireVue, Spark Hire, Willo, or VidCruiter, that is the same thing. This page covers the questions developers actually get, three model answers you can adapt, and the traps specific to engineering candidates.

What a one-way interview for an engineer actually tests

Here is the part that calms most people down. The recorded round is rarely where they test whether you can code. Companies generally save real coding for a take-home, a live pairing session, or an onsite. In one Reddit thread, a recruiter said their team had tried HireVue’s virtual whiteboard for technical screens and found it clunky enough that they dropped it. That is one person’s experience, not a verdict on any tool. But it tracks with why most teams keep hard coding out of the recorded stage.

So what is the recorded round for? Three things, usually:

• Communication. Can you explain a technical idea clearly to a person who is not in your head? This matters more than teams admit, and it is the easiest thing to judge from a recording.
• Behavioral signal. How you work with others, how you handle a production incident, how you take feedback, how you scope an ambiguous task.
• Verbal reasoning. A few prompts ask you to talk through how you would approach a problem. They want to hear your thought process, not see a finished solution.

Read the invite. If it mentions a code editor or a shared whiteboard, you are in one of the rarer technical formats, and you should prepare to write and narrate at the same time. If it does not, assume behavioral and verbal walkthrough.

The questions engineers actually get

These are the recurring prompts across one-way interviews for developer roles. Most teams pull three to five from a list like this.

Behavioral

• Tell me about a technical project you are proud of. What was your specific role?
• Describe a time you disagreed with a teammate about a technical decision. What happened?
• Tell me about a bug that took you a long time to find. How did you track it down?
• Walk me through a time you had to learn a new technology quickly to ship something.
• Describe a time you received hard feedback on your code. What did you do with it?
• Tell me about a time you had to make a tradeoff between speed and quality.

Verbal technical walkthrough

• How would you design a URL shortener? Talk through your approach.
• A page is loading slowly in production. Walk me through how you would diagnose it.
• Explain the difference between a SQL and a NoSQL database, and when you would pick each.
• How would you explain an API to a non-technical stakeholder?
• Walk me through how you would approach testing a new feature before it ships.

Motivation and fit

• Why this role and why this company?
• What kind of engineering culture do you do your best work in?
• Where do you want to grow technically in the next two years?

For the verbal technical prompts, you are graded on structure and reasoning, not on getting the single right answer. Say your assumptions out loud. Name the tradeoffs. It is completely fine to say “there are a few ways to do this, here is the one I would start with and why.”

Three model answers

These use a light version of the STAR method: situation, task, action, result. Keep each answer inside the time limit they give you, often a minute or two, and open with your point instead of warming up to it. The exact limit varies by employer, so check the screen before you start.

1. “Tell me about a bug that took you a long time to find.”

Last year our checkout service started throwing intermittent 500s, maybe one in every two hundred requests, so it was easy to miss but hurting conversion. My job was to find the cause without taking the service offline. I started by adding structured logging around the failing path, then noticed the errors clustered right after deploys. That pointed me at a race condition in how we were caching a config value on startup. I reproduced it locally by forcing the timing, wrote a failing test, and fixed it with a lock around the initialization. The 500s dropped to zero and the test is still in our suite, so it cannot regress quietly. The lesson I took was to reach for logs and reproduction before guessing.

Why it works: a real number, a real method, a result, and a one-line takeaway. No jargon for its own sake.

2. “Describe a time you disagreed with a teammate about a technical decision.”

On a previous team we were deciding whether to introduce a message queue for a new notifications feature. A senior engineer wanted to add one for scalability. I thought it was premature for our volume and would slow us down. Rather than argue in the abstract, I pulled our actual traffic numbers and sketched both designs with the real tradeoffs. We agreed to ship the simpler synchronous version first, with the interface built so we could swap in a queue later if volume grew. Volume did grow about six months on, and we added the queue then, with no rewrite. What I learned is that disagreeing with data instead of opinion usually gets you to a better answer than either person started with.

Why it works: it shows judgment and the ability to disagree without making it personal. It ends with a result and growth.

3. Verbal walkthrough: “A page is loading slowly in production. How would you diagnose it?”

First I would confirm the scope. Is it everyone or one region, all pages or one route, started suddenly or always been slow. That tells me where to look. Then I would check the obvious layers in order. On the front end, open dev tools and look at what is blocking, large bundles, render-blocking requests, slow images. On the network, check the time to first byte to separate front end from back end. If the server is slow, I would look at the slowest endpoint, check for an N-plus-one query or a missing index, and look at recent deploys and traffic spikes. I would not optimize anything until I had measured where the time actually goes. If I had to guess a common culprit, it is usually a database query that got slow as a table grew. But I would measure first.

Why it works: it is structured, it narrates a process, and it resists the trap of jumping to a fix. “Measure first” is exactly the instinct interviewers listen for.

Role-specific traps for engineers

The format punishes a few habits that engineers are especially prone to.

• Going silent to think. In a real interview you can pause and the interviewer waits. On a recording, ten seconds of silence reads as a freeze. Narrate. Say “let me think about the data model for a second” out loud. The thinking is the signal.
• Answering a behavioral question like a coding problem. “Tell me about a disagreement” is not asking for the technically correct answer. It is asking how you handle people. Engineers often skip the human part and just describe the architecture. Do not.
• Reciting a memorized definition. Some candidates trade interview question lists. One Reddit post had someone offering to pay for a bank’s HireVue questions. Even if you know what is coming, a rehearsed, word-for-word answer reads as flat and hurts you. Use a few bullet points off to the side, not a script.
• Over-engineering the walkthrough. When asked to design something simple, some engineers immediately reach for microservices, queues, and sharding. Start simple, then say “if this needed to scale, here is what I would add.” Showing you know when not to add complexity is itself a strong signal.
• Forgetting it is still a conversation. Look at the lens, not your own face. Talking to the little camera dot reads as eye contact. Watching yourself does not.

About the “is it scored by AI” worry

This is the question engineers ask most, and the honest answer has two parts.

A tool can transcribe your answers, organize them, and in some setups run automated scoring to help a recruiter triage a large pool. That part is real and increasingly common. On older HireVue setups, candidates worried that the camera was grading facial expressions and eye contact. One candidate wrote that HireVue “used AI to analyze your answers that you record (including things like eye contact, body language)” and worried about bias against neurodiverse and international applicants. That concern was fair. Two things are worth knowing. HireVue has said publicly that it stopped using facial analysis in its scoring, and by recruiters’ own accounts on Reddit, most companies never switched the facial module on in the first place. As one put it, “most if not all don’t use that module.”

What that means for you, practically: answer the question clearly and specifically. Do not try to perform for an algorithm or hold a frozen smile. A person should be the one deciding whether you advance, and clear, structured, specific answers are what survives both a human reviewer and an automated transcript. If you want the fuller picture of who is on the other side, read whether employers actually watch one-way interviews.

If you stumble

You probably will, on at least one answer, and it matters less than it feels like it does. Whether you can re-record is set by the employer, not the tool. On HireVue and similar platforms the company decides whether retakes are allowed and how many. Some give unlimited takes until you submit, some give one. Check the first screen before you start.

If retakes are off and you fumbled a single question, keep going. One candidate posted that they had “bombed a question on Hirevue,” and the reply they got was blunt reassurance: “Hirevue is a joke, you will pass.” Take the bravado with a grain of salt, but the underlying point holds. Reviewers are watching for whether you can think and communicate across the whole interview, not for one perfect take.

When you are ready to set up and record well, the practical checklist is in how to prepare for an asynchronous interview.