How to use this handbook
What you will learn: This handbook is a map for study and practice: identify your level, choose a starting point, and turn each concept into an explanation you can give aloud. The goal is not to memorize scripts. Connect an idea to a work situation, then explain its meaning, an example, and a decision or trade-off.
Before you start: You do not need experience in every topic. If interviews are new to you, begin with C#, and fundamentals in topics 02, 24 and 10, then return here to plan review. If you already work in software, choose topics from the role description and note the questions you need to revisit.
Select a term with a dotted underline for its meaning, then continue reading from the same place.
#A study plan for your level
Every question here is tagged with the level at which it's usually asked. The filter above each question list lets you focus on yours:
| Level | Typically asked about | Focus on |
|---|---|---|
| Junior | Fundamentals: , C# syntax, basics, , Git | Topics 02, 05, 07, 10, 22, 24, 28, 29 |
| Mid | How you work in production: async, , , testing, patterns | All C#, web and data topics, plus 15, 18, 21 |
| Senior | Decisions and trade-offs: architecture, distributed systems, consistency, security, system design, leadership | 12, 14, 17, 32, 33, and the Senior questions in every topic |
- Read the concepts first. Each one has a simple analogy, code, and a line-by-line explanation.
- Answer each question out loud, in English, before opening the answer. This is the most important exercise: interviews measure whether you can explain, not whether you understand silently.
- Compare with the model answer. Your wording can differ; the key points should match.
- Take the quiz at the end of each topic and revisit what you missed.
- Bookmark this site and revisit the questions you missed in short review sessions.
The interview itself
#Stages of a technical interview process
| Stage | What they assess | How to prepare |
|---|---|---|
| HR screening | Experience, expectations, salary, communication | A one-minute summary of yourself and a salary range (topic 33) |
| Technical Q&A | Fundamentals and depth | These topics, answered out loud |
| Live coding | How you think and write code | Topics 28 and 29; talk while you solve |
| Take-home task | Code quality, structure, tests | A clear README, tests and tidy commits |
| System design (mid/senior) | Design thinking and trade-offs | Topic 32 |
| Behavioral / culture | Teamwork, leadership, pressure | Three or four prepared stories |
#The golden rule for any technical answer
The strongest answers follow four steps; this is what separates memorizing from understanding:
- A one-sentence definition: "A is when the result depends on the timing of threads."
- Why it matters: the problem it solves.
- A small example or code, ideally from your real work.
- The trade-off or when not to use it. This is what lifts an answer to the next level.
❌ Weak: "Dependency injection is when we inject dependencies."
✅ Strong: " means a class receives its dependencies from outside instead of creating them. It decouples the class from concrete implementations, so I can swap a real payment gateway for a fake in tests. has a built-in container with three lifetimes… The trade-off is indirection: overusing interfaces for things that never change adds noise."
#Tell me about yourself
This opens almost every interview. Answer in 60–90 seconds using present, past, future:
- Present: who you are now and what you do: role, stack, main responsibility.
- Past: one or two achievements with numbers or clear impact.
- Future: why this role is the logical next step.
Template:
"I'm a .NET backend engineer with N years of experience building [type of systems]
with ASP.NET Core, EF Core and SQL Server. Currently at [company], I own [area],
for example [one concrete achievement with a number].
Before that, I [second achievement].
I'm looking for [what this role offers], which is why this position caught my attention."#The STAR method for behavioral questions
| Letter | Meaning | Share of time |
|---|---|---|
| Situation | The context in two sentences | ~15% |
| Task | What exactly you had to achieve | ~10% |
| Action | What you did ("I", not "we") and why | ~60% |
| Result | The measurable outcome and what you learned | ~15% |
Prepare four stories that cover most questions: a hard technical problem you solved, a disagreement with a colleague or manager, a mistake you learned from, and something you improved without being asked.
#When you're asked about something you don't know
It happens to everyone, seniors included. The only real mistake is bluffing.
- Admit it plainly and confidently: "I haven't used X in production."
- Connect it to what you know: "…but I understand it solves Y, similar to Z, which I've used."
- Reason out loud: "If I had to approach it, I'd start by…"
- Show you learn: "I'd check the docs for…, and I'm reading about it now."
#Pre-interview checklist
- Re-read the job description and pair every requirement with evidence from your work.
- Learn about the company: what it builds, its customers, its stack (from the posting, LinkedIn or its engineering blog).
- Prepare "tell me about yourself", four stories and three questions to ask (topic 33).
- Online: test camera, microphone and screen sharing, join ten minutes early, have backup internet and an open.
- The night before: light review of questions only, and sleep. Cramming new material the last night confuses more than it helps.
Interview questions
No results
Check your reasoning
Why does this choice fit? When would it fail? What changes under higher load or a dependency failure?
1.1Tell me about yourself.Junior
I'm a backend engineer with several years of experience building web with , and Server. In my current role I own the order and payment services, and recently I cut the main page's response time by two thirds by fixing queries and adding caching. Before that I built internal reporting tools used daily by the finance team. I'm looking for a team working on larger systems where I can grow in architecture, which is why this role interested me.
1.2Why do you want to leave your current job?Junior
I've learned a lot in my current role and I'm proud of what we built. Now I'm looking for a bigger engineering team and more complex systems, with more people to learn from. This role offers exactly that, so it feels like the natural next step.
1.3What are your strengths and weaknesses?Junior
My strengths are problem solving, ownership of what I ship, and making decisions based on measurements rather than opinions. A real weakness is that I haven't worked with a cloud provider in production yet; I've been closing that gap with a personal project deployed to Azure and the AZ-204 material. I also used to take on too much myself, so now I break work into reviewable pieces and earlier.
1.4Tell me about the most difficult technical problem you solved.Mid
Some customers were charged but their orders stayed pending. Using correlation ids in our logs, I found that for those orders both the payment provider's webhook and the browser redirect had failed, so we never learned the payment succeeded. I added a reconciliation job that queries the provider for pending payments every fifteen minutes and updates them idempotently, plus a metric and alert on how many it fixes. Stuck orders dropped to zero, and we now see immediately if the underlying failure rate rises.
1.5Walk me through the architecture of a system you worked on.Mid
I describe it from the outside in: what the business does and the main users; how it's deployed, for example containers behind a ; the internal structure, such as an with clean architecture layers; the data stores and caching; the integrations with payment providers or other systems and how they're made reliable; and finally the trade-offs we made and what I'd change today.
1.6Where do you see yourself in five years?Junior
I see myself as a senior engineer or technical lead, designing systems, making architectural decisions with the business, and helping other engineers grow. I'd like to get there by delivering well on the projects here and taking on more responsibility over time.
1.7How do you keep your skills up to date?Junior
I learn by building: I keep a small side project on the latest version to try new features. I follow the .NET blog and release notes, read engineering books such as Designing Data-Intensive Applications, and when something matters for work I build a small prototype before proposing it.
1.8Why should we hire you?Junior
Three reasons. My experience matches what you need: I've built and run with in production. I take ownership end to end, from design to on-call support. And I have strong fundamentals, so I pick up new tools quickly. I can contribute from the first weeks and grow with the team.
1.9What would you do if you don't know the answer to a technical question?Mid
I'd say honestly that I haven't used it, relate it to something similar I know, and reason through how I'd approach it. In real work I'd check the documentation, build a small proof of concept, and ask a colleague who knows the area.
1.10Do you have any questions for us?Junior
Yes: What would my first three months look like? How does the team handle code reviews and deployments? What's the biggest technical challenge you're facing this year? How do you measure success in this role?
Test yourself
Quiz answers and completed-topic marks are saved in this browser; they do not sync across devices.
You are asked about a technology you have never used. Best response?
In a STAR answer, most of the time should go to...
A good 'weakness' answer is...
Which structure fits 'Tell me about yourself'?