Software engineer interview questions and how to answer them
Questions on the skills open software engineer listings mention and on the core work of the role. For each: what the interviewer is checking, and a STAR answer outline with placeholders for your own example.
Based on the 500 most recently confirmed of 2,057 open software engineer listings on ROLIVA as of . Each question below is about a term from ROLIVA’s skills vocabulary that appears in at least two of these listings, most-mentioned first.
01 Describe something you built or ran on AWS. Which services did you choose, and what went wrong at some point?
Why this question: AWS is mentioned in 239 of 500 listings.
What the interviewer is checking. Whether you understand the trade-offs behind the services you used, including security, cost and failure modes, rather than just naming them.
Answer outline (STAR)
Situation.[The system and what it did, e.g. an API, a data pipeline or a batch job].
Task.[Your part in building or operating it].
Action.[The services you used and why, how you handled permissions and cost, and how you dealt with the failure].
Result.[How the system ran afterwards and what you changed to prevent a repeat]. If there is no number you can support, say what changed as a result or what you learned.
02 Walk me through a Java service or component you worked on. What design decision are you most and least happy with?
Why this question: Java is mentioned in 225 of 500 listings.
What the interviewer is checking. Whether you can explain design trade-offs in a typed, object-oriented codebase and reflect honestly on your own decisions.
Answer outline (STAR)
Situation.[The system and your part in it].
Task.[The requirement or problem that shaped the design].
Action.[The decision you made, the alternatives you considered, and how you tested it].
Result.[How the design held up in production, and what you would change]. If there is no number you can support, say what changed as a result or what you learned.
03 Walk me through work you did on Azure. How did you handle identity, access and environments?
Why this question: Azure is mentioned in 198 of 500 listings.
What the interviewer is checking. Whether you can work safely in a cloud platform: least-privilege access, separate environments, and repeatable deployment instead of manual changes.
Answer outline (STAR)
Situation.[The system or migration and the Azure services involved].
Task.[What you were responsible for and the constraint, e.g. a compliance requirement].
Action.[How you set up access, environments and deployment, and any problem you solved along the way].
Result.[The result, e.g. a successful migration or fewer manual changes]. If there is no number you can support, say what changed as a result or what you learned.
04 Tell me about something you built or automated in Python that other people relied on. What would you do differently now?
Why this question: Python is mentioned in 190 of 500 listings.
What the interviewer is checking. Whether you write Python that works beyond your own laptop: structure, error handling, tests or checks, and whether you can judge your earlier work honestly.
Answer outline (STAR)
Situation.[The task or problem, and who depended on the script, notebook or service].
Task.[What it had to do and any constraint, e.g. data size, run frequency or a deadline].
Action.[The approach and libraries you used, how you handled failures or bad input, and how you tested it].
Result.[What it replaced or made possible, and the one thing you would change today]. If there is no number you can support, say what changed as a result or what you learned.
05 Tell me about a problem you diagnosed in a Kubernetes environment. How did you find the cause?
Why this question: Kubernetes is mentioned in 180 of 500 listings.
What the interviewer is checking. Whether you understand how workloads actually run (pods, resources, probes, networking) and can debug methodically under pressure.
Answer outline (STAR)
Situation.[The service and the symptom, e.g. restarts, failed deployments or slow responses].
Task.[Your role: on call, owner of the service, or helping another team].
Action.[The steps you took, e.g. events, logs, resource limits or probe settings, and the fix].
Result.[How the service behaved afterwards and what you changed to catch it earlier]. If there is no number you can support, say what changed as a result or what you learned.
06 Tell me about a system you built or operated on Google Cloud. How did you decide between the managed services available?
Why this question: GCP is mentioned in 134 of 500 listings.
What the interviewer is checking. Whether you choose services for a reason (operational effort, cost, scale, team skills) and understand what you gave up.
Answer outline (STAR)
Situation.[The workload and its requirements, e.g. traffic, data volume or latency].
Task.[The decision you had to make or the part you owned].
Action.[The options you compared, the one you chose, and how you set up access, monitoring and cost controls].
Result.[How it performed in use and anything you would choose differently]. If there is no number you can support, say what changed as a result or what you learned.
07 Tell me about C++ code you wrote where performance or memory safety mattered. How did you verify it?
Why this question: C++ is mentioned in 119 of 500 listings.
What the interviewer is checking. Whether you understand ownership, memory and performance in C++, and whether you measure and test rather than assume.
Answer outline (STAR)
Situation.[The system and why performance or safety mattered there].
Task.[The specific problem or goal].
Action.[What you changed, e.g. ownership with smart pointers, fewer copies or a better data structure, and the tools you used to verify it, e.g. a profiler or sanitizers].
Result.[The measured improvement or the class of bug you removed]. If there is no number you can support, say what changed as a result or what you learned.
08 Tell me about Scala code you worked on, for example with Spark or a backend service. How did you keep it readable for the rest of the team?
Why this question: Scala is mentioned in 95 of 500 listings.
What the interviewer is checking. Whether you balance Scala’s expressive power with code that colleagues can maintain, and understand the runtime behaviour of what you write.
Answer outline (STAR)
Situation.[The codebase and what it did].
Task.[The task or the readability problem you faced].
Action.[The approach you took, e.g. simpler types, clear naming or agreed style rules, and how you tested it].
Result.[What changed for the team, e.g. faster reviews or fewer defects]. If there is no number you can support, say what changed as a result or what you learned.
Questions about the core work of a software engineer
These follow from the work the role title describes, not from a count of listings.
09 Walk me through a significant technical design decision you made. What alternatives did you reject and why?
What the interviewer is checking. Whether you reason about trade-offs such as complexity, performance, cost and maintainability, consider alternatives honestly, and can explain your part separately from the team’s.
Answer outline (STAR)
Situation. Describe [the system, the problem being solved] and [the constraints: scale, deadline, team size].
Task. Explain [your responsibility: author of the design, contributor or reviewer].
Action. Walk through [the options you considered], [the criteria you used], [why you chose one], and [how you got feedback on it].
Result. State [a result you can support, e.g. latency, cost or delivery time]. If the decision has not been tested at scale yet, say [what you would watch for].
10 Tell me about the hardest bug you have tracked down.
What the interviewer is checking. Systematic debugging: forming and testing hypotheses, using logs, tests and tools, persistence, and fixing the cause rather than the symptom.
Answer outline (STAR)
Situation. Describe [the symptom], [where it appeared] and [why it was hard: intermittent, production-only, across services].
Task. Explain [why it fell to you and how urgent it was].
Action. Walk through [the hypotheses you tested in order], [the tools or instrumentation you used], and [how you confirmed the root cause].
Result. Give [the fix and a result you can support] and [what you added to prevent a repeat, such as a test or alert].
11 Describe a time you disagreed with feedback in a code review, or gave feedback someone disagreed with.
What the interviewer is checking. Whether you engage with technical disagreement respectfully, argue from evidence, change your mind when you should, and keep reviews about the code.
Answer outline (STAR)
Situation. Describe [the change under review] and [the point of disagreement].
Task. Explain [your role: author or reviewer].
Action. Walk through [the arguments on each side], [any evidence you gathered, such as a benchmark or a test], and [how you reached a decision].
Result. State [what was merged and whether it held up]. If you were wrong, say [what you learned].
12 Tell me about a production incident you were involved in. What was your part, and what changed afterwards?
What the interviewer is checking. Ownership under pressure: mitigating first, communicating clearly, and contributing to a blameless review that leads to real changes.
Answer outline (STAR)
Situation. Describe [the incident and its impact on users], leaving out confidential detail.
Task. Explain [your role: on call, author of the change, or helper].
Action. Walk through [how you mitigated it], [how you found the cause], and [the follow-up actions you owned].
Result. Give [the result you can support, e.g. time to mitigation or no recurrence]. If the follow-ups were not finished, say [why and what you would push for].
Using the outlines
One real example per answer. Replace every [bracketed] part with something you did and can talk about in detail.
Keep the situation short. Spend most of the answer on what you did and why.
Say “I” for your part. Name the team’s work as the team’s, and your own decisions as yours.
Results you can support. If there is no number, say what changed or what you learned. Never estimate a figure you cannot back up.
How these questions are chosen
Each open software engineer listing’s description and stated skills are checked, on whole words, against the fixed skills vocabulary ROLIVA uses on its job pages, resume examples and monthly skills reports. A listing counts once per term. A mention is not a requirement, and the counts change as employers open and close roles. The questions and outlines are preparation prompts written for this role. They are not a record of what any employer has asked, and no employer’s process is described here.
Interview Studio prepares questions and STAR outlines for a real job from its description and the experience you have confirmed. No generative AI: when a detail is missing, it asks you instead of inventing one.