Question 1

You are responsible for AI tool adoption on your team. What is your plan?

Accepted Answer

Give a staged plan with an exit criterion per stage: 1. Pilot (2-4 weeks, 2-3 people). Goal: identify which tasks benefit. Exit: a concrete list and what the repo needs. 2. Repo preparation. CLAUDE.md, permission rules, first skills. Exit: a newcomer starts with zero setup. Skipping this stage is the most common mistake. 3. Rollout. An onboarding doc, team rules, a help channel. 4. Standardisation. Review rules, security configuration, CI. 5. Measure and improve. A periodic review. Measurement: cycle time, bugs found in review, production incidents. I would not make line count a KPI — it inflates with an agent and says nothing about quality. What I would not do: Mandate it — that creates resistance. Roll out without repo preparation — the first experience turns negative. Silence the sceptic — their concern usually points at a real problem and should become a rule. The boundary: "The decision about data leaving the company isn't mine — it belongs to legal and security. My job is to present the options and the controls."

Question 2

What do you see as the biggest risk of using AI?

Accepted Answer

Give an unexpected answer — it makes the point memorable: "The biggest risk isn't hallucination. Hallucination is visible: compilation breaks, tests break, review catches it. The biggest risk is the accumulation of code the team doesn't understand. The mechanism: writing code got cheap, understanding code did not. So code volume outgrows the capacity to understand it. Two or three years in, a project has regions nobody can explain — not the author (an agent wrote it), not the maintainer. That is more dangerous than hallucination because: It accumulates slowly — no sharp signal. It doesn't show in metrics — tests pass, coverage looks fine. It is hard to reverse — you can't refactor what you don't understand." Countermeasures: A "don't merge code you don't understand" rule — and checking it in review. A PR size limit. A documentation requirement — recording why something was done this way. Code ownership — a human owner per area. This answer shows preparation and independent thinking — both sought in a lead role.

Question 3

Management says "let's halve the team with AI". How do you respond?

Accepted Answer

This is a hard question and the interviewer is testing whether you can hold a position. Don't answer emotionally — answer with data and mechanism. 1. Surface the assumption: "That assumes writing code is the bottleneck. By our own measurements it isn't — most time goes to understanding requirements, architectural decisions, review, debugging and coordination." 2. Be concrete about what changed: "Writing code got faster. But the verification layers — review, tests, incident response — need humans, and they get more loaded as code volume grows. Some work increases." 3. Name the risk: "If we shrink the team, the volume of code we don't understand grows and there's nobody left to maintain it. That won't show for six months, then the incident rate climbs." 4. Offer the alternative: "Doing more with the same team is realistic — the work that always slips: technical debt, test coverage, documentation. We can measure that." 5. Acknowledge the boundary: "Headcount isn't my decision. My job is to show the risk and the real picture. If the decision is made, I'll prepare the transition plan." This answer shows both a position and a willingness to work with the decision — together a strong signal.

Question 4

How would you manage the cost of AI tooling on a team?

Accepted Answer

Get the order right: measure first, optimise second. Measurement: which kinds of work cost what. For CI runs, the --output-format json output carries a per-invocation cost estimate you can log. Cost you can't see, you can't manage. Optimisation layers: 1. Model fit — a cheap model for mechanical work, a strong one for hard work. Document the decision table for the team. 2. Context hygiene — narrow tasks, a short CLAUDE.md, splitting long sessions. This improves both cost and quality. 3. Limiting CI triggers — on PR open rather than every commit. 4. Turning repeated work into skills so the same instructions aren't retyped. What I would not do: cut quality where it matters (review, security, migration) purely on cost. A comparison frame (worth offering): "In a cost discussion the question isn't 'what does it cost' but 'compared to what'. Compare the price of one AI review against the price of one bug reaching production. Without that comparison, the cost always looks large."

Question 5

One developer on the team doesn't want to use AI. What do you do?

Accepted Answer

Start by finding out why — that is the key to the answer. The reasons differ and each has a different response: "Quality gets worse" → A real concern. Ask for the concrete cases they've seen; usually they point at a gap in the process. Turn the concern into a rule — a review item or a CLAUDE.md line. That both fixes the problem and turns them into an ally. "It will replace my job" → Explain concretely what changes; don't offer empty reassurance. "I don't have time to learn it" → If the repo isn't prepared, this is entirely fair. I take on the learning cost: ready configuration, an onboarding doc, one paired session. "I just don't like it" → Also acceptable. What I would not do: force it. A mandate produces performative use — the developer hands the tool a task and merges the result unread. That is worse than not using it. The boundary: "Not using it is a choice. But the team's rules — review quality, PR size, documentation — apply to everyone. Whether or not they use AI, they work to the team's standards." That shows respect and a clear boundary at once.

Question type	What the interviewer wants
"How would you bring it to the team?"	A staged plan, exit criteria, avoiding a mandate
"How would you manage the risk?"	Layered defence and bounding the damage
"How would you measure the benefit?"	Quality metrics; why line count is a bad one
"How would you manage cost?"	Measure then optimise; don't trade away quality
"What about the sceptic on the team?"	Turn the concern into a rule; no bans

Lead decisions: architecture, risk, cost

📚 Sources and documentation