The best questions to ask at the end of a technical interview are specific engineering questions your interviewer can answer from their own week: how code gets to production, how the team tests and reviews it, what broke recently and what changed afterward, and what the hardest problem on their plate is right now. Ask one or two, keep the exchange inside the time you are given (often about five minutes), and if the round went badly, use those minutes to close calmly instead of re-arguing your solution.
That closing slot is part of the interview, not small talk. Meta's published prep guide for software engineers (last updated in 2022) splits its 45-minute coding interview into about 5 minutes of introductions, 35 minutes of coding and 5 minutes for your questions, and says design interviewers typically save the last five minutes for questions as well. The Tech Interview Handbook makes the same point from the candidate side: you are generally expected to ask something. For recruiter and manager calls, see our guides to questions to ask a recruiter and an engineering manager, or the full list of questions to ask the interviewer.
Why the close of a technical round is different
In a recruiter screen or a hiring-manager conversation, questions about scope, growth and process fit naturally. In a coding or system design round you are usually talking to a working engineer who has just spent forty minutes watching you think. That changes what is worth asking.
- They know the day-to-day firsthand. Build times, code review habits, on-call load, the flaky test everyone complains about. A recruiter often cannot answer these; an engineer can, in detail.
- They may not know the business details. Pay bands, headcount plans and leveling usually sit with the recruiter or the manager. Asking an engineer about them puts them on the spot.
- They may not be on your future team. At larger companies, candidates commonly report that screeners and some onsite interviewers come from elsewhere in the org. Ask about their work, not “your team,” unless they have said they are on the team you would join.
- The questions are mostly for you. How much they count varies by company and interviewer, and in structured loops the coding or design signal carries most of the weight. A good question will not rescue a failed round, but it leaves a clear last impression and gets you information no careers page will. Amazon's advice for engineering candidates calls interviews “a two-way door” (while encouraging clarifying questions); the close is the other natural place to use it.
Engineering questions that build rapport
Good closing questions are concrete, answerable in two or three minutes, and invite the interviewer to talk about something they actually did. Software engineer Julia Evans, in a 2013 post listing the questions she was asking in interviews, described spending about 20 minutes before each interview picking which ones to ask. Do the same: choose three from the topics below for each company.
- Stack and tooling. “What does your day-to-day stack look like, and is anything in the middle of a migration?” “How long does it take a new engineer to get a working local setup and ship a first change?”
- Deploys and releases. “Walk me through how a change gets from a pull request to production. How often do you deploy?” “When a deploy goes wrong, how do you find out, and how do you roll back?”
- Testing and code review. “What runs automatically before a merge, and what still depends on manual checks?” “What does a typical code review look like here: how big are pull requests, and how long do they usually wait?”
- On-call and incidents. “Is there an on-call rotation for this role, and what does a normal week on call look like?” “What was the last real incident, and what changed afterward?”
- Interesting problems. “What is the most technically interesting thing you have worked on here?” “Is there an early technical decision the team is still living with, good or bad?”
- Tech debt and priorities. “How does the team balance feature work against maintenance? Is there time set aside for it?”
The answers also tell you a lot about the team. A few things to listen for:
| Area | Encouraging signs | Worth a follow-up |
|---|---|---|
| Deploys | Frequent, routine releases; rollback is easy | Long freezes, or one person who does every deploy |
| Testing | Tests run before merge; flaky tests have owners | “QA catches it” with little automation |
| Code review | Small pull requests, reviewed within a day or so | Reviews that sit for a week, or a single gatekeeper |
| On-call | Clear rotation; incidents get a written follow-up without blame | Frequent pages and no follow-up |
| Tech debt | Explicit time for it in planning | “After the next launch,” every quarter |
Push gently for specifics. “We deploy a lot” tells you less than “a few times a day.” Evans also suggests asking the same question to more than one person; across a full loop, comparing answers is one of the best reads on a team.
Tie your question to the problem you just solved
The question that tends to land best with an engineer connects the interview problem to their real work. It shows you are still engaged, and it is easy to answer because it is about their system, not a hypothetical. A few patterns:
- After a graph or BFS problem: “Does anything like this show up in your codebase, say dependency resolution or permission checks?”
- After an interval or scheduling problem: “Do you deal with time-window logic like this in production? How do you test the edge cases?”
- After designing a rate limiter: “What does your team actually use for rate limiting, and where has it caused trouble?”
- After designing a news feed: “How does your system handle accounts with a huge number of followers? Did you end up with a hybrid approach?”
- After a caching discussion: “How do you handle cache invalidation in practice? Has it ever been the cause of an incident?”
Keep the tone curious, not quizzing. You are asking how they solved it, not testing whether they know. For the common design building blocks and tradeoffs in one place, see our system design interview quick reference.
Match the question to the round
| Round | Time for questions | Best question type | Example |
|---|---|---|---|
| Technical phone screen | A few minutes if coding stays on schedule | The interviewer's own work | “What are you working on right now?” |
| Onsite or virtual coding round | Often about five minutes; Meta budgets 5 of 45 | Engineering practice or a tie-back | “How does a change get to production here?” |
| System design round | Often the last five minutes | Tie-back to what you designed | “How does your team handle hot keys?” |
| Last technical round of the day | Varies by company | A question you have not asked yet, or one to compare | “What surprised you most after you joined?” |
Timing varies by company and interviewer, so treat the middle column as typical, not guaranteed. Our technical phone screen guide covers the first call in more detail.
How to time-box the last five minutes
- Glance at the clock when you finish coding. Know whether you have ten minutes left or two.
- Have three questions ranked. One tie-back (pick it while you are testing your code), one engineering-practice question, one about the interviewer. Ask in order and stop when time runs out.
- Ask short, then listen. Your question should take about ten seconds; their answer gets two or three minutes. One good follow-up beats a second new question.
- Watch for the wrap-up signal. If they mention another meeting or look at the time, finish your thought in one sentence.
- Close by name. “Thanks, [name]. Hearing how you handle rollbacks was really useful.” One specific detail is enough.
| Time left | What to do |
|---|---|
| 10+ minutes | Two or three questions with follow-ups. Let it become a conversation. |
| About 5 minutes | One or two questions and one follow-up. |
| 1–2 minutes | One short question, or: “I know we're at time. I'll send anything else through the recruiter.” |
| Already over | Thank them and stop. They may have another interview right after yours. |
If coding ran long because you were still debugging, the interviewer chose to give you that time. Do not try to win it back by squeezing in three questions. On video calls the ending can feel abrupt; our live coding interview tips for Zoom and Teams cover the rest of the remote setup.
Recovering from a rough round
Some rounds go sideways: you missed the optimal approach, needed hints, or ran out of time with a bug on screen. Do not check out early, because you probably cannot tell how it went. In an interviewing.io analysis of 254 technical interviews on its platform where both sides left feedback, candidates' ratings of their own performance only loosely tracked their interviewers' ratings (an R-squared of about 0.24), and the author noted a non-trivial amount of impostor syndrome. Candidates who thought they had done poorly were also about three times less likely to want to work with their interviewer, so a bad feeling can color how you see the company too.
A calm close after a hard round looks like this:
- One sentence of closure, only if it helps. “If I had another minute, I'd fix the off-by-one on the loop bound and rerun the second test.” It shows you know where the bug is. Keep it under twenty seconds.
- Then ask a real question. Genuine curiosity resets the tone. A tie-back works well here: “Is this kind of problem close to what your team works on day to day?”
- Do not re-argue. Skip re-explaining your approach, debating the hint, or apologizing more than once. The interviewer has already seen the work.
- Do not ask how you did. Interviewers usually are not in a position to tell you on the spot, and the question makes the last minute awkward for both of you.
- Reset before the next round. Stand up, drink water, write one line about what happened, then close the notebook. Our guide to interview anxiety techniques has short resets that work between back-to-back rounds.
One bad round is rarely the whole story. Onsite loops usually collect feedback from several interviewers. The worst outcome of a rough coding round is carrying it into the next one.
Questions to skip, and what to ask instead
| Skip | Why | Ask instead |
|---|---|---|
| “How did I do?” | Usually cannot be answered on the spot | “What does strong work look like for an engineer in their first few months here?” |
| Salary, bonus, time off | Recruiter territory; an engineer may not know | Save it for the recruiter call |
| Anything on the careers page or engineering blog | Signals you did not look | “I read your post on the migration. How did it turn out?” |
| “What's the culture like?” | Too broad to answer well in two minutes | “When two engineers disagree on a design, how does it usually get settled?” |
| “What was the optimal solution?” | Questions are often reused, so many interviewers will not walk through it | Look it up afterward; ask about their real system instead |
| “Why is your app so slow?” | Sounds like a challenge, not curiosity | “What are the hardest performance problems you're working on?” |
The open-source reverse-interview list on GitHub makes a similar point: pick the few questions that matter to you, do not try to ask everything, and check what is already published before you ask.
Practice the close, not just the problem
Many candidates rehearse the coding and improvise the ending. Write your three questions for each company the night before, and say a closing question out loud at the end of every practice session so the switch from “I'm done coding” to “I'm curious about your work” feels natural. A free AI mock interview in CoPilot Interview gives you a round to rehearse on: paste the job description and your résumé, pick a coding and system design mix, and an AI interviewer builds questions from your résumé, reads them aloud, and scores each spoken answer with what worked and what to improve.
After each round, jot down what the interviewer told you. Those notes give you specific details for a thank-you email after the interview and let you compare answers across the loop.
Rehearse the full round, start to finish
Pick a coding or system design mix, answer out loud, and get a score on every answer plus an interview report with likely next-round questions. The free plan includes 15 minutes a day with no credit card.
Try a free AI mock interviewFAQ
How many questions should I ask at the end of a technical interview?
One or two, with a follow-up if there is time. Have three ready and ranked, then stop when the clock says stop.
What should I ask an engineer interviewer?
Ask about things they handle every week: how changes get to production, how testing and code review work, what on-call looks like, and the most interesting problem they have worked on. A question tied to the problem you just solved usually lands best.
What if there is no time left for questions?
Thank the interviewer and say you will send any other questions through the recruiter. Do not hold them past the scheduled end.
Should I ask how I did at the end of a coding interview?
No. Interviewers usually cannot share results on the spot, and the question puts them in an awkward position. Ask a genuine question about their work instead.
What should I do in the last few minutes if the round went badly?
Mention the fix in one sentence if it helps, then ask a real question and close politely. Candidates are often poor judges of their own performance, so do not write off the round or let it affect the next one.