Question 1
Given a problem this role would actually face, what is the brute-force version and its cost?
Approach. State input and output, the naive cost, then one improvement. Do not skip the first version.
Software engineer interview questions from a job description
Paste a software engineer job description and get the coding, system, and behavioral questions it is likely to produce, grouped by requirement.
Matched in your browser from the requirements in the posting and Luna’s interview-question hub. These are practice prompts, not a claim that this wording will be asked.
Requirements in the posting
Software Engineer
We are hiring a software engineer to build and own customer-facing product features end to end.
You will:
- Write JavaScript and TypeScript for product features and the APIs behind them
- Design backend services that stay reliable as traffic grows, and discuss system design tradeoffs such as latency and failure
- Model data in Postgres and review SQL with the team
- Partner with cross-functional stakeholders and drive work you will own after launch
- Care about algorithms and data structures when a feature needs a real complexity story
We look for people who can explain a tradeoff, test the boundary, and collaborate without taking the problem away from a partner.
We are hiring a software engineer to build and own customer-facing product features end to end.
You will:
- Write JavaScript and TypeScript for product features and the APIs behind them
- Design backend services that stay reliable as traffic grows, and discuss system design tradeoffs such as latency and failure
- Model data in Postgres and review SQL with the team
- Partner with cross-functional stakeholders and drive work you will own after launch
- Care about algorithms and data structures when a feature needs a real complexity story
We look for people who can explain a tradeoff, test the boundary, and collaborate without taking the problem away from a partner.
Likely questions
Coding
Data structures and algorithms
Care about algorithms and data structures when a feature needs a real complexity story
Question 2
Which data structure fits the access pattern in the posting, and where is it the wrong tool?
Approach. Name the operation you care about and a case that breaks the clever choice.
System design
System design
Design backend services that stay reliable as traffic grows, and discuss system design tradeoffs such as latency and failure
Question 3
Design the system behind the main workflow in this posting. What has to be fast, and what can wait?
Approach. Users and API first. Name one bottleneck and the piece you will not build in the interview.
Question 4
How would you estimate capacity before picking a database?
Approach. Use rough numbers, label every assumption, and say which number would change the design.
Behavioral
Collaboration
Partner with cross-functional stakeholders and drive work you will own after launch
Question 5
Tell me about a disagreement with someone who did not report to you. What did you do with their objection?
Approach. Name the objection, what you changed, and what you did not. Do not flatten it into “we aligned.”
Coding
JavaScript
Write JavaScript and TypeScript for product features and the APIs behind them
Question 6
Walk through a JavaScript function you would write for this role and the bug you would check before calling it done.
Approach. Restate the input, give the naive version, then name one edge — empty, duplicate, or async — and how you would prove it.
Coding
SQL and data modeling
Model data in Postgres and review SQL with the team
Question 7
What tables would you need for the core object in this posting, and what is the grain of each?
Approach. Name the entity, the key, and one query you must keep fast.
Coding
TypeScript
Write JavaScript and TypeScript for product features and the APIs behind them
Question 8
Where would types earn their keep in this job, and where would they just slow a change down?
Approach. Name one boundary — an API payload or a shared component — and one place you would keep the type loose on purpose.
System design
Backend services
Design backend services that stay reliable as traffic grows, and discuss system design tradeoffs such as latency and failure
Question 9
Where would you draw the service boundary for this product, and what would you keep in one process for now?
Approach. Start from the request that must be fast, then name the split you would postpone.
Behavioral
Ownership
Partner with cross-functional stakeholders and drive work you will own after launch
Question 10
Tell me about something you owned after it shipped, when the interesting part was over.
Approach. Spend the time on the follow-through: the metric, the bug, or the user you went back to.
What to prepare
- Dry-run three cases — empty, typical, and the boundary you fear — on one problem.
- Narrate one design in sixty seconds before you draw any boxes.
- Have one story where someone disagreed and you kept the working relationship.
- Rehearse one array transformation out loud, including the empty case and the cost.
- Practice one join out loud: the grain of the result, then the filters.
- Pick one function and say which types you would write, and which you would leave inferred.
- Draw one service boundary and say what you would not split out yet.
A software engineer posting is a map of the loop, not a personality test. Lines about languages and data structures point at a coding screen. Lines about services, latency, or “scale” point at a design conversation. Lines about ownership and cross-team work point at the behavioral round, even when they sit under “requirements” instead of “soft skills.”
Read the first screen for the product, then the bullets for the verbs. “Build,” “own,” “debug,” and “review” are different jobs. A posting that says you will own a service end to end will ask what you did after launch. A posting that lists algorithms and complexity will ask you to narrate a brute-force baseline before a clever one.
Prepare one coding story, one production bug, and one tradeoff. Put a number in the result when you have one. The sample below is a generalist product-engineering posting: the tool highlights the requirements and lists the questions those lines usually become.
Sample job description
The posting below is already in the tool. The questions are the ones its requirements point to. Replace it with a posting you are actually interviewing for.
Related: Google coding questions · Amazon system design questions · Coding interview communication