Interview Execution Tips
How to handle the moments that aren't about knowing the answer.
When asked to refactor code live (like the DiscountService exercise): narrate your thinking as you go — name the smell you see first ("this if/else means every new customer type needs a code change, that's an Open/Closed violation"), THEN write the fix. Interviewers are evaluating the reasoning process at least as much as the final code.
When you don't know something: say so directly, then reason toward the likely answer from what you do know, out loud. "I haven't used NServiceBus sagas specifically, but based on how sagas work in other frameworks I'd expect X" is a strong answer. Bluffing and getting caught is far worse than an honest gap paired with good reasoning.
When a question is ambiguous: ask a clarifying question before answering — "when you say handle errors, do you mean transient failures or a message that will never succeed?" mirrors exactly the distinction in the Retry/DLQ topic and signals you're already thinking at the right level.
Connect answers back to their stated stack when relevant: if asked generally about testability, land on "...which is exactly why the client's preference for DI/composition over inheritance matters — it's what makes this kind of code mockable in a unit test." Showing you've internalized their stated architectural preferences, not just generic best practice, is a strong signal you were paying attention to the brief they sent you.