Software engineer phone screen questions for non-technical recruiters
On this page
- The ownership ladder: hearing depth without the tech
- What they built and what their part was
- Scale and constraints: asking about numbers you can't judge
- Stack verification questions anyone can ask
- Resume inflation patterns and how to check each
- Logistics that end engineering processes late
- Must-ask list and scorecard
- What not to ask
- Questions people ask
A non-technical recruiter screens a software engineer by testing ownership and specificity, not technical correctness. Ask what they built, what their personal part was, how big it was, what broke, and what they would change. Engineers with real depth answer with names, numbers and trade-offs; inflated resumes answer with the same keywords that are already on the page.
Below are the questions grouped by what they test, what strong answers sound like, the resume inflation patterns worth checking, and a scorecard. The general screen structure is in phone screen questions for recruiters.
The ownership ladder: hearing depth without the tech
Every claim on an engineering resume sits somewhere on this ladder. Your questions move the candidate up it until they stop. Where they stop is the most useful thing you learn on the call.
| Level | What it sounds like | What it usually means |
|---|---|---|
| 1. Present | "We used Kafka." "The team migrated to AWS." | It existed where they worked. They may not have touched it. |
| 2. Used | "I wrote consumers for the order events." | Worked in a system someone else designed. |
| 3. Built | "I built the retry and dead-letter handling after we lost messages." | Created a meaningful piece and can explain why it was needed. |
| 4. Owned | "I was on call for it, and I changed how we partitioned topics after an outage." | Responsible for it in production, including when it failed. |
| 5. Decided | "I argued against Kafka for the second service; the volume didn't justify it. I lost that argument, and here's what happened." | Made or influenced design decisions and can describe the trade-off. |
A senior role needs level 4 or 5 on the must-haves. A mid-level role needs a solid 3. The examples above are invented; the pattern is what matters.
What they built and what their part was
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| Tell me about the most significant thing you built in the last two years. What did it do, and who used it? | Starts with the user or business problem, then the system: "Warehouse staff needed pick lists that updated live, so I built…" | Starts with a list of technologies. Cannot say who used it. |
| What was your part, and what did other people on the team do? | Separates "I" from "we" without being pushed, and credits others by role. | Only "we", all the way through. Or only "I" on a project that clearly took a team. |
| What was the hardest part, and why was it hard? | A specific problem: a data migration that could not stop the system, a performance issue, a messy integration. | "Tight deadlines" or "communication". Real, but not engineering. |
| If you built it again tomorrow, what would you change? | A concrete regret with a reason: "I'd have split the reporting queries off the main database from day one." | "Nothing, it went really well." |
| What happened the last time it broke in production? | A short incident story: what failed, how they found out, what they fixed, what changed after. | Has never been involved when something broke, for a role that includes on-call. |
| Who reviewed your code, and whose code did you review? | Describes the review culture and something they learned from a review, given or received. | No code review at all for years, in a role that expects it. |
Scale and constraints: asking about numbers you can't judge
You do not need to know whether 2,000 requests a second is a lot. You need to know whether the candidate knows their own numbers, and what changed as the numbers grew. Engineers who have owned a system in production almost always know roughly how big it was.
- "Roughly how many users, requests or records did it handle?" Strong: an order of magnitude and the unit, stated easily. Red flag: "a lot" or "millions" with no unit.
- "What stopped working as it grew, and what did you do about it?" Strong: a specific bottleneck and the fix. Red flag: nothing ever had to change.
- "How long did a deploy take, and how often did you ship?" Strong: knows both and has an opinion on whether it was fast enough. Red flag: does not know how their code reached production.
- "How big was the engineering team, and how many people worked on your system?" Useful context for every other claim. A "platform rebuild" by a team of 60 is a different story from one by a team of three.
- "What did it cost to run, or was cost ever a conversation?" For senior and staff roles, a strong candidate has been part of that conversation.
Stack verification questions anyone can ask
Pick the two or three technologies that are true must-haves for the role and ask about each one. The questions below do not require you to know the answer. They require the candidate to have used the tool for real work.
| Claim on the resume | Question | Strong answer | Red flag |
|---|---|---|---|
| A language (Go, Java, Python, TypeScript) | "What do you like least about it, from your own work?" | A specific annoyance from daily use. | No dislikes, or a complaint copied from a well-known blog post. |
| Cloud (AWS, Azure, GCP) | "Which services did you set up yourself, and which were already there when you joined?" | Names a few services and what they configured. | "All of AWS." Cannot say who managed the account. |
| Kubernetes or containers | "Did you write the deployment config, or deploy onto a cluster another team ran?" | An honest answer either way, with detail. | Claims to have run clusters but cannot say who was paged when one failed. |
| Microservices | "How many services did your team own, and what was the most annoying thing about talking between them?" | A number and a real pain point: versioning, timeouts, debugging across services. | Microservices as a label with no problems at all. |
| Front-end frameworks (React, Angular, Vue) | "How did the app manage state, and did you ever change that approach?" | Names the approach and a reason it changed. | Only built components inside someone else's structure, described as "architected the front end". |
| CI/CD | "What happened between merging your code and it reaching users?" | Walks through the steps and the checks that ran. | "DevOps handled that", for a role that expects the engineer to own deployment. |
| AI and machine learning | "Did you train models, or call a model through an API? What did you measure to know it worked?" | Clear about which, and names an evaluation method. | "Built AI features" meaning a single API call, presented as ML engineering. |
Resume inflation patterns and how to check each
| Pattern | What it looks like | How to check on the call |
|---|---|---|
| Keyword wall | Thirty technologies in a skills section, most used once. | "Which three of these have you used most in the last year?" Then ask about only those. |
| Team credit | "Led the migration to microservices" on a team of forty. | "What was your part?" and "Who else was involved?" |
| Title inflation | "Senior" or "Lead" at a very small company, a year out of school. | "How many engineers were there, and who did you report to?" Judge the work, not the title. |
| Consultancy blur | Five client projects in two years, each listed as if they owned it. | "How long were you on each, and what was live when you left?" |
| Side project as production | A tool or cloud service used only in a personal project, listed alongside job experience. | "Was that at work or on your own?" Side projects are fine; labeling matters. |
| Overlapping jobs | Two full-time roles with overlapping dates. | Ask directly and neutrally. Sometimes it is a contract ending; sometimes it is two jobs at once, which the client will want to know. |
| Rehearsed answers | Polished, generic explanations of a concept, but vague about their own system. | Ask for a name, a date, an incident, a number. Specifics about their own work can't be looked up. |
Logistics that end engineering processes late
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| The role is hybrid, three days a week in [city]. Does that work? | Yes or no, now. "Two days is my limit" is a useful answer. | "Remote is preferred" from someone who applied to an on-site role, with no clear limit. |
| What total compensation do you need to make a move, and how do you weigh base against equity? | A base number and a view on equity: "I need 190 base; equity matters less to me at a late-stage company." | Only a number from a salary website. Ask expectations, not current pay; see salary expectation questions. |
| Where else are you interviewing, and how far along? | Stages and timing: "Onsite at one company next Thursday." | "Nowhere" from a strong candidate in a busy market, then an offer deadline appears. |
| The process has a take-home exercise and a system design round. Are you comfortable with both? | Yes, or a clear objection you can take to the client early. | Declines any assessment for a client that requires one. |
| Are you legally authorized to work in the US, and will you now or in the future need visa sponsorship? | A direct answer to both. | None from the answer. Ask the same two questions of every candidate and do not ask about citizenship or country of origin. |
The work authorization wording above follows the US Department of Justice's Immigrant and Employee Rights Section FAQ, which says an employer may generally ask whether applicants have the legal right to work in the United States and whether they will need sponsorship.
Must-ask list and scorecard
Must-ask on every engineering screen
- The most significant thing they built recently, and their personal part.
- One follow-up on each must-have technology from the stack table.
- A production incident or failure they were involved in.
- What they would change if they built it again.
- Work setup, compensation expectation, notice period, other processes.
- Work authorization and sponsorship, asked the same way for everyone.
| Area | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Ownership | Describes what the team used | Worked inside others' designs | Built significant parts, explains why | Owned in production and shaped decisions |
| Specificity | Keywords only | Some detail when pushed | Names, numbers and incidents unprompted | Explains trade-offs and what they would change |
| Must-have stack | Present only | Used | Built | Owned or decided |
| Communication | Hard to follow | Clear with prompting | Clear to a non-engineer | Clear, concise, and checks you followed |
| Logistics fit | A deal-breaker | Two open questions | One open question | All aligned |
Write the evidence next to each score in the candidate's own words. An engineering manager reading "owned the ledger migration: 'we dual-wrote for six weeks'" can decide in seconds; "strong backend skills" tells them nothing. The candidate submittal template shows how to turn those notes into the email.
What not to ask
Engineering screens have their own version of the usual mistakes. "When did you graduate?" and "How many years until you want to retire?" point at age. "Is this your first job since having kids?" points at family status. "Where did you grow up?" points at national origin. The EEOC notes that pre-employment inquiries that indicate race, sex, national origin, age or religion can be used as evidence of discrimination. Ask about the work, the dates of relevant roles and the must-haves.
If you want the ownership ladder to fill itself in, Interview Signal builds a question guide from the job description and attaches the candidate's exact words to each score, so the evidence column is done when the call ends.
Questions people ask
Do I need to understand the technology to screen a software engineer?
No. You need to hear whether the candidate can explain their own work specifically: what they built, what their part was, what went wrong and what they would change. Those answers separate depth from keywords without you judging the technical content.
Should a recruiter ask coding questions on a phone screen?
Usually not. A recruiter asking a quiz question cannot follow up on the answer, and strong candidates find it off-putting. Leave technical assessment to the engineers and use the screen to test ownership, clarity and fit with the role's must-haves.
How do I tell if a candidate is reading answers during a video screen?
Ask about details only they could know: the name of an internal service they built, the worst incident on their team, a decision they lost. Generic, textbook answers to questions about their own work are the signal, whatever the cause.
Is it fine to ask when a candidate graduated?
Avoid it. Graduation year is a close proxy for age. Ask about relevant experience and the dates of the roles that matter for the job instead.