Interview Questions for Software Engineers: What Strong Answers Cover
The title “software engineer” covers two different jobs. On an established team with a tech lead and a written plan, the engineer turns well-shaped work into tested, working changes. At a company without that structure, the same title belongs to the person who works out what a request means, chooses an approach and owns what gets built. Useful interview questions for a software engineer start from which of those jobs you are filling, because the questions that separate candidates are not the same.
The 14 questions below all use one example system, a booking platform for a chain of fitness studios with class schedules, waitlists, memberships and a calendar integration, so every prompt has enough detail to answer properly. Replace it with your own system when you run the interview. The notes after each question describe what a good answer tends to include. Treat them as a basis for discussion rather than an answer key; if a candidate argues for a different design and the argument holds up against your system’s constraints, score the argument. An interview gives you evidence about how someone reasons; how they perform on your actual work is the real evidence.
Which Questions Fit the Role You Are Hiring For?
Weight the question groups by the job, not the title. An engineer joining a team that already has architecture, priorities and review in place needs to execute well inside that plan. The first or only technical person on a product needs to develop the plan as well, and the interview should spend most of its time there.
| Question group | Executing within a plan | Developing the plan |
|---|---|---|
| Turning a request into work | Light: clarifying a defined ticket | Heavy: this is much of the job |
| Data and state | Medium | Heavy |
| Concurrency and correctness | Heavy | Heavy |
| Integrations | Medium | Heavy |
| AI-assisted code | Heavy | Heavy |
| Ownership after release | Medium | Heavy |
This bank concentrates on the decisions behind a feature. For debugging, code review and rollout scenarios, the technical interview questions we published earlier cover that ground, and language-specific rounds belong in their own session.
Turning a Request Into Work
This group shows whether a candidate can turn an informal request into something buildable without either stalling on ambiguity or guessing past it.
1. A Studio Manager Asks for a Waitlist. What Do You Ask Before Building It?
Good candidates ask about behavior before tables. When a spot opens, does the next member get booked automatically, or get a notice and a window to claim it? How long is that window, and does it shrink close to class time? Is a class-pack credit held while someone waits? What do instructors see at the door?
Listen for the line between decisions that belong to the engineer, such as how the queue is stored, and decisions that belong to the business, such as the claim window. A strong candidate names who should answer the second kind and proposes a sensible default to put in front of them. Then ask a follow-up: the manager says “just make it like the airline ones.” See whether the candidate can turn that into specific behavior.
2. How Would You Break That Waitlist Into Pieces You Can Ship?
Look for a thin slice that works end to end first: members can join a waitlist and front-desk staff promote people by hand. Automatic promotion comes next, then notifications, then edge cases such as late cancellations. Each piece should be deployable on its own and useful to someone.
The better answers also name the riskiest assumption and test it early. If the whole design depends on members claiming spots within an hour of an email, shipping the manual version first shows whether they do before anyone builds the automation.
3. What Is Wrong With a Spec That Emails Everyone on the Waitlist When a Spot Opens?
A candidate who reads specs for consequences will see the race it creates: the fastest reader wins the spot, and everyone else gets an email inviting them to book a class that is already full. Ask them to show the failure concretely, for example by walking through what three members see in the two minutes after the email goes out, and then to propose a version the studio manager could approve, such as offering the spot to one member at a time.
This is the habit that matters most for engineers who will develop the plan. In one engagement, our engineer worked from detailed Figma mocks for a fintech administrative hub and still found gaps in the initial requirements, raising technical considerations for white-label theming and real-time notifications that the client had not yet documented.
Data and State Questions
Data decisions outlive the code around them, so these questions carry more weight for engineers who will shape the schema.
4. How Would You Model Memberships, Class Packs and Bookings?
A good model separates the plan a member bought (an unlimited monthly membership, a 10-class pack with an expiry date) from the bookings they make against it. Strong candidates often keep a ledger of credit movements instead of a single mutable “credits remaining” number, so a refund, a late-cancel penalty or a disputed charge can be traced. They also put a uniqueness constraint on a member and a class session, so the same person cannot hold two spots in one class.
Follow up with a collision: a member’s pack expires while they are fourth on a waitlist. The candidate should treat that as a product question with a data consequence and say where the rule would live.
5. How Would You Add an Index to a Bookings Table That Takes Writes All Day?
A careful candidate first asks to see the slow query and its plan, because an index that the planner will not use only adds write overhead. Then comes locking. On PostgreSQL, a standard CREATE INDEX lets other sessions read the table but blocks inserts, updates and deletes until the build finishes, which on a busy bookings table means members cannot book. CREATE INDEX CONCURRENTLY avoids that lock at the cost of two table scans and a longer build. Source: PostgreSQL documentation, CREATE INDEX
Strong candidates know the catches. A concurrent build cannot run inside a transaction block, which matters because many migration tools wrap each migration in one. If the build fails, it leaves an invalid index that queries ignore but writes still pay to maintain, so the migration needs a check for it and a plan to drop it and try again.
6. A Recurring 6 p.m. Class Shows Up at 5 p.m. After a Clock Change. What Went Wrong?
The likely cause is that the schedule was stored as UTC instants computed once, when the class was created. A recurring class is a wall-clock commitment: 6 p.m. in the studio’s local time, whatever the UTC offset happens to be that week. A good answer stores the local time with an IANA time zone name and expands occurrences in that zone, while still recording real events, such as when a booking was made, as instants.
Studios in different time zones, and states such as Arizona that mostly do not observe daylight saving time, make a useful second prompt. Candidates who have been bitten by this tend to answer quickly and specifically.
Concurrency and Correctness Questions
Both tracks need this group, because a booking system’s worst defects appear only when two things happen at once.
7. Two Members Book the Last Spot at the Same Moment. What Happens?
If the code reads the count, checks it against capacity and then inserts a booking, both requests can pass the check. Good answers move enforcement into the database: a conditional update that increments the count only while it is below capacity and reports whether a row changed, a row lock on the class session, or a stricter isolation level with retries.
Ask about that last option. PostgreSQL defaults to Read Committed, and under Repeatable Read or Serializable a transaction can fail with a serialization error, so the application has to be ready to retry the whole transaction. Source: PostgreSQL documentation, Transaction Isolation A lock held in application memory is a weak answer, since it stops working as soon as a second instance of the service runs.
8. The Job That Promotes Waitlisted Members Runs Twice. What Breaks?
Overlap happens in practice: a scheduler retries after a timeout, or two instances both run the job during a deploy. Without protection, one open spot can be offered to two people and the same member can get three emails.
Look for promotion written as a conditional state change, moving a waitlist entry from waiting to offered only if it is still waiting, plus a lease or advisory lock so one run works on a class session at a time. Notifications should be sent from the recorded state, not from the job’s memory, so a rerun does not send them again.
Integration Questions
Third-party services fail on their own schedule. The candidate should design for that from the start.
9. How Would You Consume Webhooks From a Calendar Provider?
Members sync bookings to their personal calendars, and the provider sends webhooks when an event changes. A solid answer verifies the signature on every request, acknowledges quickly and processes the event from a queue, and records event IDs so duplicates are ignored.
The follow-up that separates candidates is ordering. Webhooks can arrive late, out of order or not at all, so a good design compares versions or timestamps before applying a change, or fetches the current state from the provider instead of trusting the payload. A periodic reconciliation job catches whatever the webhooks missed.
10. The Calendar Provider’s API Is Down for an Hour. What Should the Product Do?
The booking itself should still succeed. Calendar sync is a convenience, so a strong answer keeps it off the critical path: outbound calls get timeouts, failed syncs go to a queue, and members see that their calendar will update shortly.
Ask what happens when the provider recovers. Replaying an hour of backlog at full speed can trip the provider’s rate limits and cause a second outage, so the candidate should drain the queue at a controlled pace.
Questions About AI-Assisted Code
Most teams now ship some code an assistant wrote. The skill to probe is judgment about what that code does at the boundaries.
11. How Do You Review a Large Pull Request Written Mostly by an AI Assistant?
The same standard applies as for any pull request, with extra attention where generated code tends to go wrong: authorization checks, database access policies, migrations, error handling, and tests that assert real behavior rather than restating the implementation. Good candidates ask for the change to be split if it is too large to read properly, and they run it.
The stakes are concrete. While moving a WealthTech platform from AI-built prototype to production, we caught a regression in which an AI-assisted update nearly exposed the entire user table through a misconfigured row-level security policy.
12. When Would You Choose Not to Use AI Assistance?
There is no single right answer, which makes the reasoning visible. Reasonable answers include security-sensitive code where every line needs to be understood, unfamiliar domains where the candidate could not judge the output, and code covered by a client’s confidentiality rules.
Probe how they verify generated code they do accept. A candidate who describes reading, testing and sometimes rewriting it is showing the judgment that matters, because assistants make ordinary code easier to produce while data modeling, failure modes and security boundaries remain the hard part.
Ownership After Release
Ownership questions carry the most weight when the engineer will answer for the feature once it is live.
13. You Ship the Waitlist. How Do You Know It Works?
Uptime is the shallow answer. A stronger one defines the signals before launch: how many spots the waitlist fills, how long an opened spot stays empty, how often offers expire unclaimed, error rates in the promotion job, and what studio managers report in the first weeks. The feature ships behind a flag so it can be turned off for one studio without a deploy.
Candidates who measure the business behavior the waitlist was meant to change, filled classes, are thinking like owners.
14. What Would You Set Up Before Taking On-Call for a Service You Built Alone?
Look for alerts on symptoms members would notice, a dashboard for the promotion job and sync queue, a short runbook for the failures they expect, and at least one other person who can deploy and roll back. A service that only one engineer can operate carries key-person risk, and a good candidate raises that without being asked.
A Practical Exercise That Matches the Work
A short exercise shows how someone works, which a conversation cannot. Give the candidate a small booking service with three planted problems: a capacity check that races under concurrent requests, a recurring class stored as a fixed UTC time, and a missing test around waitlist promotion. Ask them to find and fix what they think matters most.
Follow it with a conversation about what they fixed first and what they left alone. The order of their fixes shows how they rank risk, which often tells you more than the fixes themselves.
How Should You Score the Answers?
Score each area separately, and write down the answer that earned the score so a later reader can see why. The table gives a simple three-level scale. It helps interviewers compare evidence; it does not predict performance, and an average should not hide a weak area the engineer would own alone.
| Area | Limited evidence | Solid | Strong |
|---|---|---|---|
| Scoping | Starts building without questions | Asks the right questions | Separates product and technical decisions, proposes defaults |
| Data | Mutable counters, no constraints | Sound model with constraints | Ledger, safe index changes, time zone handling |
| Concurrency | Checks in application code | Database-level enforcement | Explains isolation trade-offs and retries |
| Integrations | Trusts payloads and order | Verifies and deduplicates | Reconciles, degrades gracefully, controls backlog |
| AI-assisted code | Accepts output as written | Reviews boundaries | Explains how they verify and when they refuse |
| Ownership | Measures uptime | Adds alerts and runbooks | Measures business outcome, reduces key-person risk |
Red Flags Worth a Follow-Up Question
Probe further when a candidate starts writing code before asking what the waitlist should do, enforces capacity with an in-memory lock, stores recurring schedules as fixed UTC times, applies webhook payloads in arrival order, or treats generated code as reviewed because the tests pass. Defining success for a feature as “no errors in the logs” deserves a question too.
One weak answer should lead to another question, not a verdict. A pattern of weak answers in an area the role depends on is the signal to take seriously.
How Gun.io Thinks About Software Engineering Fit
At Gun.io, the first thing we want to know about a software engineering role is which of the two jobs it really is. An engineer who will execute inside a client’s established plan and an engineer who will clarify requirements, recommend an approach and own the build can both be excellent, and they are rarely interchangeable. Seniority matters here through the judgment and independence the work demands, more than through years or a title.
Our evaluation of technical capability and professional fit happens in human interviews, and it continues after an engineer starts, because the work itself is what proves the fit. The shape of the work also decides the engagement: staff augmentation suits a team that can direct the engineer day to day, while scoped project delivery suits a client who needs more of the plan developed for them, across the engineering areas we work in.
Frequently Asked Questions
Should I Ask Algorithm and Data Structure Questions?
Ask them only where the work needs them, and root them in your domain. Merging overlapping class time slots or finding the next open session for a member tests the same reasoning as an abstract puzzle, and it shows whether the candidate connects the algorithm to a real constraint.
Can Candidates Use AI Tools During a Software Engineer Interview?
They can if you decide that in advance and tell every candidate the same thing. If your team uses assistants daily, allowing them in a practical exercise and asking the candidate to explain each change shows how they verify output, which is closer to the real job than a ban.
How Do I Adapt These Questions to My Own System?
Keep the shape and change the domain. Each question pairs a specific decision with a failure that tests it, such as two people booking the last spot, so replace the studio examples with the equivalent moments in your product: the shared resource, the scheduled job, the external service you cannot control.
What Should I Ask a Junior Software Engineer?
Use the data modeling and concurrency questions at a smaller scale, and drop most of the plan-ownership questions. A junior candidate who explains why two requests can both pass a capacity check, and is honest about what they have not built yet, is showing a good foundation.
Should Software Engineering Interview Questions Be Language-Specific?
Most of them should not be, because the decisions they test carry across languages. Add a separate, shorter round on the language and framework the engineer will use daily, and weight it by how much of the role depends on that depth.
How Can I Tell a Senior Candidate From a Mid-Level One?
A senior candidate raises the questions you did not ask, such as what happens to a waitlisted member whose pack expires, and explains the trade-offs of each option before you probe. Mid-level candidates usually answer the question as posed and answer it well, which is exactly what many roles need.
Interview for the Work Behind the Title
Decide whether you need someone to execute a plan or to develop one, then weight these questions toward that job and let the engineer’s performance on real work confirm what the interview suggested. If you are filling a role like this, tell us about the system the engineer will work on, how much of the plan already exists and who will direct the work day to day.
