// in person training
Think about the problem correctly. The rest is practice.
Forty hours beside engineers who solve these problems for customers every week, on the problems that separate competent from excellent. You leave writing sharper code under pressure and reasoning about systems the way senior and principal work demands. The interview is the week's proving ground. What you keep is the engineering, and that is what sets you up for everything after it.
Who it is for
Beginner and intermediate engineers. You should be able to write code in C, C++ or Java. You do not need to be fast or fluent, and you need no security background. If you did a data-structures course at university and remember none of it, that is the normal case and the week is built for it.
Bring a laptop with a working toolchain for at least one of the three languages. Bring it working: a day lost to environment setup is a day of the week lost.
Two days on the coding half, two on data and system design, one on practicing both. The same structure is built twice: once where you own the memory, once where a library has already decided for you.
The five days
Day 1
Complexity, arrays, strings and hash maps
Stating the cost of your own code and defending it when pushed. The two array patterns that solve a large family of problems. Then a hash map built from nothing and broken on purpose, so you have seen the worst case rather than read it. The day closes on the method for a problem you do not recognise: work the smallest case by hand, state the invariant, solve it badly, then ask what the bad version wastes - because a pattern table only helps once you recognise the shape.
By Monday evening you can state and defend the complexity of your own code, recognize the two array patterns that solve a large family of problems, and reach for a hash map without being prompted.
Day 2
Trees, graphs and the six patterns
Trees are asked constantly and under-prepared; graphs are feared and are mostly two functions you will write five times. The day closes by assigning the take-home you do that evening, with an assistant, because that is how one is actually done. Three traversals until automatic, a search tree fed sorted data until it collapses into a list, and the problems that are secretly graphs. Ends with six patterns named, which is the recognition a coding round actually tests.
By Tuesday evening you can write all three tree traversals and both graph traversals from memory, and name which of six patterns a new problem belongs to.
Day 3
Data at scale: one server, then a million users
The morning reviews the take-home the way a reviewer does: you walk your own diff, name what you took from the assistant, and defend it as a choice. Then the hour on what happens when you type a URL, because it is asked in some form in most loops and it is where a candidate either walks the whole path or stops at step two: DNS, the TCP handshake you pay a round trip for, TLS, and what a status code commits you to. TCP against UDP as a trade. And idempotency, because a timeout plus a non-idempotent write is a duplicate. Then one drawing on one board. It starts as one server and one database, which works. Then traffic is added and it falls over six times, and each fix arrives because the drawing already failed: cache, replica, shard, queue, index. Plus estimation on paper, and reading an execution plan while a slow query gets fast.
By Wednesday evening you can take one server to a million users on a whiteboard and say what each step costs you.
Day 4
The design interview
Three designs under time pressure, using the same four steps every time: agree the scope, propose a high-level design and check, deep dive, wrap up. Then the hour on where an assistant helps a design and where it cannot: it names the right blocks and cannot say what they cost you, and it will never tell you a requirement is missing. Mundane briefs on purpose, one with the requirement changed halfway and one with a constraint that invalidates the obvious answer.
By Thursday evening you can take a one-sentence brief to a defensible design in 45 minutes, using the same four steps every time.
Day 5
Mock interviews, coding and design
Five rounds: two coding, one AI-assisted, two design, 45 minutes each, one candidate in front of the room. Thinking out loud, taking a hint without collapsing, and one interview you are deliberately walked into a dead end on. Plus the round that is not technical and is still scored, sometimes against a published list of values, which can decline a candidate who passed everything else. You leave with three habits to fix, taken from five rounds of feedback rather than self-assessment.
By Friday you have sat the round that decides your next job five times over, and you know which three habits to fix.
What you can do on Friday
The interview is the week's proving ground. What you keep is the engineering, and that is what sets you up for everything after it.
You will have sat five interview rounds, three coding and two design, and know which three habits to fix. That feedback comes from five rounds in front of the room rather than from your own assessment of yourself.
And you will have written and said the non-technical round out loud, which candidates under-prepare more than any other because it does not look like a test. Where a loop scores it against a published list of values, you leave knowing how many stories that takes and which ones you still owe.
Better judgement, which is the one that compounds. Every structure and every scaling block is taught with what it costs you, not just what it buys you: a cache buys the repeated read and costs staleness you have to design for; a shard buys more data than one disk and costs joins, transactions and counting. You leave able to say which trade you are making and why, and that is the difference between an engineer who proposes a cache and one who is trusted to choose.
You see the pattern instead of the puzzle. Most problems are one of a small number of shapes. By Friday you name which shape a new problem is inside the first minute, which is what stops you starting from nothing every time.
You write code that survives contact. Not just working code: the input nobody checked, the empty case, the single-character case, and the complexity you can state and defend when somebody pushes back on it.
You can scale a system and say what it costs. One server to a million users, where every fix arrives because the drawing already failed, and each one is written down with what it bought and what it took away. Plus estimating on paper whether a design needs one machine or fifty, before designing it.
You can walk a request end to end and be asked about any step of it. DNS to TCP to TLS to HTTP, what each round trip costs, which methods are safe to repeat, and why a retry without idempotency is a duplicate. Said out loud, in order, to someone watching - which is the form the question is actually asked in.
You have a method for a problem nobody has shown you. Six patterns cover what an interview asks; most real work matches none of them. Work the smallest case by hand, state the invariant, solve it badly on purpose, then ask what the bad version wastes - and the waste names the improvement. Knowing which situation you are in, method or table, is the judgement.
You can work with an assistant and own the result. Engineers use one daily now, and the skill is not prompting: it is reviewing output the way you would review a stranger's code, catching a complexity it stated fluently and wrongly, and defending every line as your own choice. You practise it on a problem you had already solved by hand, on a take-home overnight, in a design, and in a round with somebody watching.
And you can design under pressure rather than at leisure - a one-sentence brief to a defensible design in 45 minutes, using the same four steps every time, including when the requirement changes halfway through.
Speed comes from repetition, and you leave knowing exactly which problems to repeat. Five rounds of feedback tell you which three habits are costing you, so the practice afterwards is aimed rather than general.
What is deliberately not in the week
We said the week cuts material rather than depth. This is the cut, and the reason beside it.
Bit manipulation
Rare in a general coding round, and the topic most often studied instead of trees, which are asked constantly. Mentioned once, not practiced. It is not rare where the product is silicon, firmware or a codec, so tell us if that is your target.
Threads, locks and concurrency in depth
A week of its own. Day 3 covers why ordering and duplication happen in a distributed system; the primitives wait. Skippable for a coding round, and not skippable where the role is systems or C++ and the loop asks about memory models and locks directly.
Advanced dynamic programming
The pattern is taught and practiced on two problems, because an engineer who can spot overlapping subproblems beats one who memorized six recurrences. The harder catalog is not, and this is the cut that bites hardest at employers whose coding rounds are known for difficulty rather than breadth. If that is your target, two problems are a start and not a preparation.
Depth on linked lists, heaps and backtracking
An hour each rather than a half-day, and this is a real cost: if you are interviewing somewhere that drills these specifically, practice them alone afterwards.
Low-level and object design
The cut most likely to surprise you. Day 4 is distributed system design: services, data flow, scale. Some loops run a separate round on designing the objects and interfaces inside one service, and this week does not prepare for it. Named here rather than discovered on the day.
Union-find and tries
Two structures that do appear in harder coding rounds. The hours they would take come out of trees and graphs, which are asked more often. The cost is real: a problem that is secretly a disjoint-set problem will not be recognised.
Building a key-value store, a crawler or a feed from scratch
Too slow to teach live. Day 3 teaches the building blocks and Day 4 assembles them; the catalog is homework.
What each attendee takes home
What they can do, and the sheet in their own handwriting that proves it. Worksheets they filled in, not slides they were shown.
Day 1
You can state what your own code costs and defend it when pushed, and you have reviewed an assistant's version of the same problem against six human ones. Proof: your problem set, with the complexity you argued for beside each answer.
Day 2
You name which of six patterns a new problem is inside the first minute, and you have written every traversal from memory. Proof: the pattern sheet, and a search tree you fed sorted data until it collapsed into a list.
Day 3
You can take one server to a million users and say what each step costs you. Proof: the building-block card with the cost column filled in your own words before the instructor's.
Day 4
You take a one-sentence brief to a defensible design in 45 minutes, using the same four steps every time. Proof: three designs you drew under time pressure, including the one whose requirement changed halfway through.
Day 5
You have sat the round that decides your next job five times over. Proof: five rounds of written feedback and the three habits to fix, taken from people watching you rather than from your own assessment of yourself.
How it is taught
The reason it is in person, and what it costs us to teach this way.
- The wrong way first, until it hurts. You never get the good answer first. You search a list repeatedly and watch it crawl; you feed a search tree sorted data and watch it collapse into a list; you draw one server and add traffic until it falls over. The structure or the pattern then arrives as relief rather than as instruction.
- You write down what you think will happen, before it happens. A prediction on paper is remembered; a prediction in your head is not. Being wrong having committed is the thing that sticks, and we do not soften the result.
- The objection is answered before it is asked. Every unit has one question a sharp attendee raises, and every one of them is written into the material with its answer - including the ones where the honest answer is "you are right, and here is the trade".
- Said, drawn, then done. One idea reached three ways in the same hour beats three ideas reached once. When an hour is overfull we cut an idea rather than a channel.
- You leave with worksheets you filled in, not slides you were shown: the predictions you got wrong, the problems you solved, the designs you drew.
- And it has a cost we will state up front. It is slower per topic, so the week cuts material rather than depth and we can tell you exactly what was cut and why. It needs a room under about a dozen people. And parts of it are deliberately uncomfortable, which we do not rescue early.
How it runs
- Scoped before it is quoted. A short conversation about who is in the room, what they already do, and what you want them able to do afterwards. The engineer who would teach it is the one who scopes it.
- On real code. The week runs on real code and a real database. Where something real cannot be shared we say so and use something that can.
- In person, five consecutive days. We come to you, or your team comes to us. One room, one week, nothing spread across afternoons.
- Small groups. Scoped per group rather than sold per seat, so the material can be aimed at the people actually in the room.
- You keep everything. The material, the exercises and the work your people produced stay with you, with no license to renew.
- It is not a funnel. Training is sold on its own, and nothing in it obliges you to buy anything else afterwards.