Delivery Lead / Engineering Manager interview preparation
Use this guide to prepare for Delivery Lead / Engineering Manager interviews, with a focus on lifecycle selection, sdlc, waterfall fit. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Lifecycle selection
SDLC
Waterfall fit
Discover to operate
Security integration
DevSecOps
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Mid-level
1. How would you choose a software delivery lifecycle for a regulated system?
Answer guide
I begin with the constraints: how stable the requirements are, what assurance evidence regulators expect, how often we can release, the level of risk and how much feedback stakeholders can give. Regulated work usually needs traceable approvals and validation records, which suits stage gates, but I still prefer short cycles inside them so misunderstandings appear early. I tailor gates to the risk, heavier for safety-relevant changes and lighter for cosmetic ones. The main pitfall is leaving validation to the end, when correction is most expensive.
What this question explores
Whether you choose and tailor a lifecycle by risk, evidence needs and feedback, not by fashion.
Common mistakes
Choosing a method by popularity, such as saying Agile is always better.
Treating compliance as documentation done at the end, after the system is built.
Practise a follow-up
How would you keep an Agile team compliant with audit evidence requirements?
What would you put in a tailoring plan for low-risk changes?
2. How would you review whether an organization's SDLC is working in practice?
Answer guide
I would trace a few representative changes from the original need through to operation, and inspect the decisions, the evidence, the exceptions and the outcomes along the way. Then I would compare the written process with actual behaviour, by speaking to the people involved. Improvements should be aimed at the points where information or accountability fails, rather than rating success by template compliance alone, since a perfectly completed form can sit on top of a poor decision. I would present findings to leaders with examples and a short list of prioritized actions.
What this question explores
Whether you review a lifecycle by following real changes and comparing practice with the written process, not by auditing templates.
Common mistakes
They check that templates are completed and conclude the lifecycle works.
They interview only managers and never trace real changes to see what actually happened.
Practise a follow-up
How would you choose which changes to trace in the review?
How would you handle finding that teams routinely work around the official process?
3. When might a sequential delivery approach be sensible?
Answer guide
A sequential approach can be sensible when scope is fairly stable, external approvals or contracts require defined stages, and evidence at each gate matters, as in some construction, hardware or regulated projects. The clarity of phases helps planning and audit. Even then, I would validate assumptions early through prototypes, reviews or a thin end-to-end slice, because late discovery is the classic failure. The choice is about uncertainty and cost of change: the more either is expected to grow, the less suitable a strictly sequential approach becomes.
What this question explores
Whether you can name the conditions favouring sequential delivery and the safeguards it needs.
Common mistakes
Calling waterfall outdated and always wrong without saying when it fits.
Running it with no early validation, so surprises arrive at final testing.
Practise a follow-up
How would you introduce early feedback into a waterfall project?
What signals would tell you to move from sequential to iterative?
4. What lifecycle stages would you expect from idea through retirement?
Answer guide
A typical journey starts with discovery, where the problem and value are understood, followed by requirements, design, build and verification. Then come deployment, operation and support, and continuing improvement as users give feedback. At the end the system is retired, with data and users moved safely. These stages are not always a straight line, because modern teams loop through them in small cycles. Security, quality and feedback belong in every stage, and a small app may pass through all of them in a few weeks.
What this question explores
Whether you know the full life of a system, including operation and retirement, and that stages overlap.
Common mistakes
Stopping the list at go-live and forgetting operation, improvement and retirement.
Describing the stages as strictly one-way with no feedback or overlap.
Practise a follow-up
Which stage do you think is most often rushed, and what goes wrong?
How does the lifecycle differ between a waterfall and an Agile project?
Security appears at every stage. Early on I run threat analysis and add security requirements, such as authentication rules and data protection needs. In design and coding, secure design reviews, safe libraries and code review keep issues out. Before release, dependency scanning, static and dynamic analysis and targeted penetration testing provide evidence, and after release monitoring, patching and incident response handle what was missed. The depth of each control should match the risk of the system, so a payment service gets more than an internal noticeboard.
What this question explores
Whether you place proportionate security activities across every phase rather than one late test.
Common mistakes
Treating security as a single penetration test performed just before release.
Applying the same heavy controls to every system regardless of its risk.
Practise a follow-up
What is threat modelling and when would you do it?
How do you handle a critical vulnerability found the day before release?
6. What does shifting security left fail to cover by itself?
Answer guide
Shifting left catches design flaws and coding mistakes early, which is valuable, but it leaves gaps. Some problems only show at runtime, such as misconfiguration, abuse patterns and attacks on live systems. New vulnerabilities also appear in dependencies after release, so patching and monitoring continue. Detection and incident response, along with governance of the software supply chain such as build integrity and third-party components, sit outside early checks. I would assign owners across the full lifecycle and measure time to detect and fix.
What this question explores
Whether you see that early checks must be paired with runtime defence, response and supply-chain governance.
Common mistakes
Treating shift-left tools as the whole security programme once scans pass in the pipeline.
Leaving operations out of the conversation, so no one owns patching and response.
Practise a follow-up
How would you measure whether security practices are improving?
Who should own vulnerable third-party dependencies after release?
7. What is useful about a V-model view of development and testing?
Answer guide
The V-model pairs each specification or design stage with a matching verification level: business requirements with acceptance testing, system design with system testing, detailed design with integration testing and code with unit testing. Its benefit is that test intent is thought through early, as each specification is written, so gaps show up before build. It does not mean waiting until the end to run tests, since reviews, static checks and prototypes belong on the left side. It also helps explain to auditors how each requirement will be shown to work.
What this question explores
Whether you see the V-model as a way to plan verification early, not a rule to delay testing.
Common mistakes
Saying testing only begins after all coding is finished because that is how the V works.
Memorising the diagram without being able to pair each level with what it verifies.
Practise a follow-up
How would you adapt the V-model to short iterations?
What is the difference between verification and validation?
8. What does an iteration help you learn that a big-bang release hides?
Answer guide
A working increment in the hands of users shows things a plan cannot: integration problems, usability issues and whether the priorities were right. A big-bang release hides these until the end, when they are costly. Each iteration lets the team replan from evidence, drop low-value items and adjust direction. It works only if each increment meets a coherent quality bar, meaning it is tested, integrated and usable; otherwise iterations produce half-finished work that misleads everyone about progress. A demo of a real workflow beats a status slide.
What this question explores
Whether you understand what iterative feedback reveals early and the quality discipline it needs.
Common mistakes
Describing iterations as just shorter phases without any real user feedback.
Releasing unfinished increments and calling that progress.
Practise a follow-up
What would you do if stakeholders are not available to give feedback each iteration?
How do you define a coherent increment when features depend on each other?
9. A release deadline encourages bypassing tests. How do you decide?
Answer guide
First I make the risk explicit: which tests would be skipped, what they protect and what failure would cost. I protect the controls that guard critical paths, money, data and safety, and look for ways to reduce scope or phase the release rather than remove evidence silently. If a shortcut is still chosen, it is recorded as debt with an owner, a funded plan and a date, and the authorised decision maker accepts the risk in writing. That keeps the conversation honest and stops hidden liabilities surfacing later as incidents.
What this question explores
Whether you handle schedule pressure by making risk visible and getting an accountable decision.
Common mistakes
Quietly skipping tests to hit the date and hoping nothing breaks.
Refusing any compromise and blocking the release without offering options.
Practise a follow-up
How would you make the cost of technical debt visible to a sponsor?
What would you do if the decision maker accepts a risk you think is too high?
10. What must be planned when retiring an application?
Answer guide
Retiring an application is a project in itself, so I plan what happens to the data: retention rules, archive or migration to a successor, and secure deletion where required. I map every integration and consumer so nothing fails silently, agree communication and training with users, and schedule access removal and contract termination. Audit evidence and backups stay available for the required period, and a rollback route remains until the successor is proven. The risky mistake is switching off a system that a forgotten process still depends on.
What this question explores
Whether you plan retirement as a controlled programme covering data, dependencies, people, contracts and evidence.
Common mistakes
Treating retirement as switching the servers off once users have moved.
Forgetting data retention and audit obligations until someone asks for old records.
Practise a follow-up
How would you discover hidden dependencies on a legacy application?
When would you keep a read-only archive rather than migrating all data?
11. How would you help a new team member understand what successful contribution looks like?
Answer guide
I would sit down in the first week and agree responsibilities, expected outcomes, working boundaries and who to approach for help. Then I would use concrete examples, such as a recent piece of good work, and ask them to explain it back so I can check understanding. A job title or task queue alone may not explain the decisions and behaviors the role requires, for instance when to escalate or when to decide alone. I would revisit the picture after a few weeks, because expectations become clearer once real work arrives.
What this question explores
Whether you can turn a vague role into clear outcomes, boundaries and support routes, and check that the newcomer has actually understood them.
Common mistakes
They hand over a job title and a task list and assume the person will work out what good looks like.
They explain expectations once in a long induction talk and never check understanding or revisit it later.
Practise a follow-up
How would you handle it if their first output is far from what you expected?
What would you do if the team gives the new joiner conflicting signals about priorities?
12. How do you preserve traceability from a business need to a deployed feature?
Answer guide
I connect the chain from the business objective to the approved requirement, then to the design decision, the work item, the tests, the release record and finally the outcome measure. Each link is kept in a tool with version history, so a change to one element shows what else is affected. This supports audits and also everyday questions, such as why a feature exists and whether it delivered the benefit expected. The effort should be proportionate: lightweight links in the work tracker usually beat a heavy matrix nobody reads.
What this question explores
Whether you can link intent to delivery to outcome in a way that is maintained and actually used.
Common mistakes
Stopping traceability at the test case and never linking to business outcomes.
Building a huge matrix by hand at the end of the project for the auditors.
Practise a follow-up
How would you show the value delivered by a feature after release?
What would you do if requirements live in emails and chats?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.