Question 1

How would you give this task to the agent? (The interviewer gives you a concrete task)

Accepted Answer

Narrate the four elements as you write the prompt — let the interviewer see your reasoning: 1. Context: "First I'd point at a similar existing file so the project's pattern gets reproduced." 2. A concrete requirement: what to build, with what structure. 3. Constraints: "don't add new dependencies", "don't touch this folder". 4. Verification: the compile/test command and the done criterion. A sample prompt (Android): "Add an order details screen in the feature/orders/ module. Look at feature/profile/ui/ProfileScreen.kt for the pattern. Split stateful and stateless Composables; a @Preview for every public Composable (loading/empty/error/populated). Use collectAsStateWithLifecycle for Flow collection. Strings in strings.xml. Don't add new dependencies. Done when ./gradlew :feature:orders:compileDebugKotlin passes." Add at the end: "For a larger change I'd start in plan mode — catching a wrong direction in the plan is cheaper than reverting 20 files."

Question 2

The agent writes wrong code during the live task. What do you do?

Accepted Answer

Stay calm — this is expected, and it is actually your opportunity: this is exactly where the interviewer sees judgement. Steps: 1. Name the mistake concretely (out loud): "State hoisting isn't right here — the Composable holds its own state, so it can't be reused." 2. Decide and explain: small mistakes I fix myself (faster); pattern mistakes I have the agent fix, and I include the why so it doesn't recur. 3. Systematise: "In a real project I'd write this note into CLAUDE.md, because it's the recurring kind." Don't: apologise for the agent's output ("sorry, it's usually better than this"). The agent's mistake isn't yours — your job was to catch it, and you did. The strength of this answer is that it presents the error as a normal part of the process rather than a problem. Interviewers read that as a real-experience signal, because anyone who works with an agent knows it happens daily.

Question 3

Time is short in the live task. How much do you rely on the agent?

Accepted Answer

Explain the prioritisation openly — it demonstrates planning: "With little time I focus the agent where it helps most: boilerplate, repetitive structure, test skeletons. Logic and architectural decisions I do myself — explaining those to the agent takes longer than doing them." A concrete split: To the agent: the screen skeleton, data classes, repetitive Composables, test skeletons. To me: the architectural decision, the business logic, which cases must be covered. An important addition: "Even short on time, I don't accept a diff unread. Not reading isn't saving time — an error found later costs more." Close with the frame: "Same principle in real work: the agent saves time because writing gets faster — but shortening the verification layer isn't a saving, it's a debt." This answer shows both sides: practical prioritisation and not compromising the principle.

Question 4

The interviewer says: "Don't use the agent, write it yourself." How do you react?

Accepted Answer

Take it in stride and write — don't argue. The question really tests two things: whether your fundamentals are intact, and whether you're dependent on the tool. Start with "of course", then proceed like an ordinary coding interview: think out loud, start with the simple solution, then improve it. What not to do: Object with "but in real work I use an agent". That signals dependency. Show that you can't write it without one. Worth adding at the end (if it lands naturally): "In real work I'd hand the skeleton of this to the agent — but the logic and structural decisions would be the same. The agent speeds up writing, not deciding." That shows both things at once: the fundamentals are there and your relationship with the tool is healthy. Which is exactly what the interviewer is checking.

Question 5

After the live task: "explain this code". How do you prepare?

Accepted Answer

This question is prepared for during the live task, not afterwards. So the answer is about process: "I read the diff at every step during the task — not for this question but as my own habit. So no separate preparation is needed to explain it." The explanation structure: 1. The overall purpose — what this code is for. 2. The structure — what the parts are and why it's split this way. 3. The decisions — why this approach, what the alternative was. 4. The limits — what isn't covered, what I'd add in a real project. If there's a part you don't understand, be honest: "I haven't fully verified this part; in a real project I'd ask the agent to explain it or simplify it before merging." That is far stronger than inventing an explanation — and the interviewer spots the difference instantly. The core principle (worth stating): "I don't merge code I don't understand. That's a rule on our team too — because code you merge is your code."

Do	Don't
Think out loud	Type silently and wait for output
Add a verification path to the task	Say "fix this" and accept whatever comes back
Read the diff and comment on it	Move on without reading
Move in small steps	Ask for everything in one prompt
Type the trivial thing yourself	Send everything to the agent, even one line
Note the agent's mistake calmly	Apologise for the agent's output

The live task: demonstrating agentic coding

📚 Sources and documentation