How to Run a Technical Interview Senior Engineers Respect
The candidate is assessing the session while you assess them. A prompt nobody has tried, ten minutes lost to a broken dev environment, or an interviewer answering Slack messages tells a senior engineer how your team plans and how it treats people’s time. Strong candidates with other options act on that impression.
A technical interview is one structured session in which an engineer works through a problem drawn from the real job while an interviewer collects evidence about how they reason, build and communicate. Running it well comes down to five decisions: what the session needs to tell you, which format shows that, a prompt taken from problems your team has already solved, how you behave while the candidate works, and how you record what you saw. The session gives you evidence. How someone performs on the job is the real evidence, and a well-run technical interview is designed with that limit in mind.
What Should One Technical Interview Tell You?
One session can answer one or two questions about a candidate well, and five questions badly. Decide before you write the prompt which uncertainty this hour is meant to reduce. For a backend engineer joining a team that ingests vehicle telemetry, the open question might be whether they handle messy, late and duplicated data sensibly. For an engineer joining a product team with no technical lead, it might be whether they ask the right questions before building anything.
Write that question at the top of the interview plan. It decides the format, the prompt and what counts as strong evidence, and it stops the session drifting into whatever the interviewer happens to find interesting. If you need a bank of questions by skill area to draw from, the published set of technical interview questions grouped by the skill they examine is a good starting point. Choosing questions is the smaller part of the job; running the hour well is the larger one.
| What you need to learn | Format that shows it best |
|---|---|
| How they reason through an unfamiliar problem with you | Paired live coding |
| How they structure code and tests when nobody is watching | Scoped take-home with a follow-up discussion |
| What they notice in code that already exists | Code review exercise |
| How they shape a system before writing it | Design conversation |
Live Coding, Take-Home or Code Review: Which Format Fits?
Each format shows something real and misleads in a predictable way. Choose the one whose blind spot matters least for the role, rather than the one your last company used.
| Format | What it shows | What it costs the candidate | Where it misleads |
|---|---|---|---|
| Paired live coding | Reasoning, debugging, how they take a hint | An hour of performing under observation | Penalizes people who think best in silence; rewards speed over care |
| Scoped take-home | Structure, tests, written trade-offs | Unpaid evening hours unless you cap the scope | Says little about authorship without a follow-up conversation |
| Code review exercise | Judgment about risk and priority | The least preparation of any format | Weaker evidence about writing new code |
| Design conversation | How they shape a system and handle constraints | Little, if the prompt is bounded | Can reward rehearsed patterns over thinking |
Live coding works best for roles with close collaboration or on-call debugging, where how someone works with another person matters as much as the code. Treat it as pairing: you are a teammate who answers questions, not a proctor.
A take-home suits roles where most of the work is done alone and asynchronously. It is only fair with a written time cap, clear acceptance criteria and the rubric shared in advance. An open-ended take-home measures how much free time a candidate has, which tends to screen out people with caregiving responsibilities and people already working demanding jobs.
A code review exercise tends to feel the most realistic to senior candidates, because it resembles their week. Give them a realistic pull request with a few seeded problems of different severity and ask them to rank what they find.
A design conversation fits roles that will shape systems before anyone writes code. Keep the prompt bounded by real constraints; a set of system design interview questions with answer notes shows the kind of scenarios that work.
Decide Your Policy on AI Coding Assistants
Many engineers now write code with an AI assistant, and candidates will ask whether they can use one. Decide before the session and tell them in the invitation. Either answer can be reasonable: allowing it shows how they review and correct generated code, which is a large part of the job; disallowing it isolates their own reasoning. What does not work is an unstated rule that the candidate discovers halfway through, or one interviewer allowing it while another penalizes it.
How Do You Prepare a Prompt From Your Own Work?
Take the prompt from a problem your team has already solved, simplified until it fits the time. For the telemetry team, a good prompt might be: given a list of GPS pings for one truck, some arriving late and some duplicated, produce a trip summary with start time, end time and distance. That problem is small enough to finish, and it has natural places to probe judgment, such as what to do with a ping timestamped before the trip started.
Prepare three things alongside it:
- A working environment. A repository that clones, installs and runs its tests in a couple of minutes, in the language the role uses. If you are hiring a Python engineer for a data or backend role, write the starter code in Python. Setup problems eat the session and tell you nothing.
- Two or three extensions. Conditions you add once the base problem is solved, such as pings arriving from several devices on the same truck, or the summary needing to update as new pings arrive. Extensions let a strong candidate show more without making the base problem harder for everyone.
- A written note of what strong evidence looks like. For the trip summary: asks how duplicates are defined before deduplicating, sorts by event time rather than arrival time, writes a test for the late ping, and names the trade-off when told the data will keep arriving.
Then run the prompt yourself, or have a colleague do it under the same time limit. If a teammate who knows the domain needs the whole hour, the prompt is too big.
Make the Session Accessible
Ask every candidate in advance whether they need any adjustments, and treat the answer as routine. Let them use their own editor and keyboard setup if they prefer. Send the format, the time split and any setup instructions ahead of time, and schedule across time zones so nobody is solving problems at midnight.
How Should You Open the Session?
Spend the first five minutes on context, because a candidate who knows what to expect can show you their real work. Introduce yourself and the team, say what the role will own, and explain the format: the problem, the time split, what tools they can use and that you will offer hints.
Say plainly that asking questions is expected and that taking a hint is normal. Many experienced engineers have learned that interviews punish questions, so they guess at requirements instead of asking. If clarifying the problem is part of what you want to see, you have to make it safe to do.
What Should the Interviewer Do While the Candidate Works?
Talk less than you think you should, and ask open questions when you do. “What are you weighing here?” gets more evidence than “Are you sure about that loop?”, which tells the candidate the answer is wrong and turns the next five minutes into recovery.
When the candidate solves the base problem, change one condition and watch how they adapt. Tell the telemetry candidate that pings can now arrive hours late after a truck leaves a dead zone. A strong engineer reasons about whether the summary must be recomputed, what the consumer of the summary expects, and what they would ask the product owner. How someone revises a working solution often tells you more than the first version.
When a candidate is stuck, use a ladder of hints rather than a rescue. Start by restating the requirement, then point to the area of the code, then name the concept. Note which rung they needed. A candidate who needed one nudge and then moved quickly has shown you something useful; letting them flounder for fifteen minutes has shown you only how they handle being ignored.
Write notes as observations, not verdicts: “Sorted by arrival time; changed to event time after the late-ping test failed” is evidence. “Seemed junior” is an impression that will be hard to defend in the debrief. Keep the clock, and stop the coding with at least ten minutes left for the candidate’s own questions.
How Should You Score a Technical Interview?
Score immediately after the session, on your own, against the criteria you wrote before it. Waiting until the debrief lets the most confident voice in the room set the score for everyone.
An evidence note that records what is still unknown is more useful than a single number:
| Criterion | What the candidate did | What it suggests | Still unknown |
|---|---|---|---|
| Clarifies before building | Asked how duplicates are defined; did not ask about timezones | Checks the data model first | Whether they ask about the consumer of the output |
| Handles changed conditions | Moved to recomputing summaries when pings arrive late | Comfortable revising a working design | How they would do this at higher data volume |
| Tests what matters | Wrote a test for the late ping, none for an empty list | Tests the risky case first | Habits on a larger codebase |
| Communicates trade-offs | Named the cost of recomputation unprompted | Thinks about downstream effects | How they explain trade-offs to non-engineers |
A rubric score is an interview aid that keeps interviewers consistent; it is not a validated predictor of how someone will perform. The “still unknown” column keeps everyone honest about what one session could show. Some of those gaps can be explored in a conversation with the hiring manager. Others can only be answered by how the person works once they start.
What Loses Strong Candidates?
Strong engineers usually leave a process for reasons the interviewer controls. The common ones:
- Problems with no connection to the job. Puzzle questions and memorized algorithms tell a senior candidate the team does not know what it is hiring for.
- An unprepared interviewer. Reading the prompt for the first time on the call, or being unable to answer basic questions about the team, signals how the team runs everything else.
- Moving the goalposts. Adding requirements that were never stated, then marking the candidate down for missing them.
- Judging by speed. Rewarding the fastest typist over the person who asked the question that would have prevented a production bug.
- No room for their questions. A senior developer is deciding whether to spend years of their career with you. Leaving no time for their questions treats the decision as one-sided.
- Silence afterward. Weeks without a decision, or a rejection with no explanation after an investment of several hours.
None of these needs more process to fix; each comes down to an interviewer who prepared and paid attention.
How Gun.io Approaches Technical Conversations
At Gun.io, a technical conversation exists to answer a practical question: what responsibility can this engineer carry in a particular engagement, with the amount of direction the client can give? Our assessment of engineers rests on human interviews that weigh technical capability alongside professional fit, and those conversations center on the kind of work an engagement involves rather than generic puzzles.
An interview gives us evidence about how someone reasons. How they perform on the actual work is the evidence that counts, which is why selection continues after an engineer starts. You can see the engagement models and engineering areas we work in, including staff augmentation and scoped project delivery.
Frequently Asked Questions
How Long Should a Technical Interview Be?
Sixty minutes is a workable default for one live session: about five minutes of context, forty to forty-five on the problem and its extensions, and ten for the candidate’s questions. A design-heavy senior role may need longer for the design conversation, but a longer session is not automatically a better one.
Should Every Candidate for a Role Get the Same Prompt?
Yes, for candidates at the same level in the same role, because evidence can only be compared when people faced the same problem and the same extensions. Keep two or three equivalent prompts ready, and retire one if it appears online or a candidate has already seen it.
How Long Should a Take-Home Coding Assignment Take?
A take-home should fit a stated time cap of a few hours, and the cap should be enforced by the size of the problem rather than by trust. If a teammate cannot finish it inside the cap, cut the scope. Pair every take-home with a conversation about the candidate’s choices.
What Should You Do if a Candidate Freezes Early in the Session?
Pause the problem and reset the context. Restate the requirement in plain words, offer a small first step, and say again that questions and hints are normal. Nerves in the first minutes say little about how someone works; how they respond once they have their footing says much more.
Can a Hiring Manager Without Recent Coding Experience Run a Technical Interview?
Yes, for the conversation and the evidence notes, as long as an engineer who can judge the code reviews the work. A written description of strong evidence for each part of the prompt lets a non-specialist follow the reasoning, ask useful follow-up questions and record what the candidate did.
Should You Give Feedback to Candidates Who Do Not Move Forward?
Brief, specific feedback is worth giving when your company’s policy allows it, especially after a take-home. One or two concrete observations, such as missing tests for the late-arriving data, help the candidate and protect your reputation with engineers who talk to each other.
Design the Hour Around the Evidence You Need
A technical interview earns its hour when it reduces one real uncertainty about the hire and leaves an honest record of what it did not settle. If you are hiring for a role where that evidence matters, tell us about the hire you’re planning and bring the problem the engineer will face first, along with the constraints around it.
