All jobs / Engineering manager / tech lead
Code & Development Practices interview questions
Code & Development Practices questions a Engineering manager / tech lead can be asked, from first job to senior. Open one to see the strongest answer and why it works.
As tech lead, what is code review on your team for?
The strongest answer: Shared understanding and catching defects early — anyone reviews anyone, and the lead is not the only approver
Why it works: Exactly. Review spreads knowledge; a single-approver gate turns you into the bottleneck.
- Review spreads understanding.
- Anyone can review anyone.
- Automate style, discuss design.
- Never approve to save the number.
A developer asks what the CI pipeline is actually for. What do you tell them?
The strongest answer: It builds and tests every change the same way on a clean machine, so within minutes we know whether the branch is safe to merge — not on someone’s laptop, not next week
Why it works: Exactly — the same build for every change, on a clean machine, with an answer fast enough to act on.
- Every change, same way, fast.
- Clean machine, not a laptop.
- An answer in minutes.
- Red means stop.
When is a story done on your team?
The strongest answer: When it meets the definition the team agreed — reviewed, tested, deployed, and observable in production — not when someone says so
Why it works: Exactly. Done is a shared, written definition that ends in production.
- Done is agreed and written.
- It ends in production.
- Reviewed, tested, observable.
- Not merged, not demoed.
Pull requests on your team sit for two or three days, and the branches grow while they wait.
What do you do?
The strongest answer: Make review part of the day rather than a spare-time task: an agreed turnaround such as same day, smaller pull requests, and a visible queue so nobody has to chase
Why it works: Exactly — waiting time is the problem, and smaller changes plus a named expectation are what shorten it.
- Review is the day’s work.
- Agree a turnaround expectation.
- Keep pull requests small.
- Make the queue visible.
The test suite fails on about one run in five, and the team has learned to hit “re-run”.
What is your policy?
The strongest answer: Treat a flaky test as a broken test: take it out of the blocking suite with a ticket, an owner and a date, fix it or delete it, and keep the quarantine list visible
Why it works: Exactly — out of the blocking path, owned and dated, with the list visible so it cannot quietly grow.
- A flaky test is broken.
- Quarantine, with owner and date.
- Fix it or delete it.
- Keep the list visible.
You inherit a team with almost no automated tests. Where do you start?
The strongest answer: Agree a testing strategy with the team, start where failures hurt most, and make tests part of the definition of done for new work
Why it works: Exactly. Strategy with the team, highest-pain first, and done means tested.
- Strategy with the team.
- Start where failures hurt.
- Tests are part of done.
- Coverage numbers are not a strategy.
Trunk-based development or long-lived feature branches — which do you put a team on, and why?
The strongest answer: Trunk, with small changes merged daily behind feature flags: merge pain and surprise integrations grow with branch age. Long-lived branches only where releases genuinely are versioned separately
Why it works: Right — the cost is a function of branch age, and flags are what make merging daily safe.
- Branch age is the cost.
- Merge small changes daily.
- Hide unfinished work behind flags.
- Long-lived only for versioned releases.
The pipeline takes fifty minutes, and most of it is end-to-end tests running against a deployed environment.
What do you change?
The strongest answer: Split it: fast unit and integration tests block the merge, the end-to-end set runs in parallel and after merge, and each check moves to the cheapest level that can still catch its bug
Why it works: Right — stage the feedback, and push each check down to the cheapest level that still catches the bug.
- Stage the feedback.
- Fast checks block the merge.
- End-to-end runs in parallel.
- Test at the cheapest level.
Your organisation releases once a month, in an evening, with everyone on standby. How do you get to weekly or better?
The strongest answer: Separate deploying from releasing with feature flags, make the pipeline the only route to production, shrink the batch, automate the rollback — then raise the cadence while change failure rate and restore time hold
Why it works: Right — smaller batches with flags and a rehearsed rollback are what make frequency safer, and the stability metrics are your evidence.
- Smaller batches, safer releases.
- Separate deploy from release.
- One automated route to production.
- Rehearse the rollback.