ChannelPulse
The anatomy of a loop
A loop is a data-collection process with a decision attached, and the two halves are run by different people for different reasons. This lesson covers the five interview formats you might actually meet, how the stages fit together, what an interviewer writes down in the ten minutes after you leave, and the single most important structural fact — that trajectory is scored, not just the final answer.
What you'll be able to do
- Recognise the five interview formats and what each one is filtering for
- Explain what an interviewer writes down and why timestamps appear in it
- Describe why a buggy solution can pass and a perfect one can fail
- Set a realistic preparation budget against the stage you are at
Most preparation treats an interview loop as a series of independent exams. It is not. It is a data-collection process followed by a decision, the two halves are performed by different people, and almost everything that surprises candidates about outcomes comes from not knowing which half they are in at any given moment.
This module covers the half you can see. The last module covers the half you cannot.
Watch the first ninety seconds and then jump to the end. The opening shows how a round is framed and how a candidate sets up their own background; the closing chapter is the interviewer giving feedback out loud, which is the closest you will get to hearing what normally gets written down after you leave the call. The middle of this video is cued in a later lesson, so leave it for now.
Jump to the part you need
The five formats
There are only five things a company can actually do to you, and knowing which one you are in tells you what is being filtered.
| Format | How often | What it is really for |
|---|---|---|
| Quiz | Occasional | A cheap first-pass filter. Questions have clear-cut answers — what is 4 & 5 in binary, what is the time complexity of bubble sort — precisely so that non-technical staff or an auto-grader can administer it |
| Online coding assessment | Occasional | Volume screening, usually on HackerRank or a similar platform |
| Take-home assignment | Rare | The only format that measures software design rather than algorithms. More common at startups, because it costs both sides real time |
| Phone screen | Common | A live coding conversation in CoderPad, CodePen or a shared document |
| Onsite | Almost always | Multiple rounds — coding, system design, behavioral — over a few hours |
Three practical notes that change how you prepare rather than what you know:
Online assessments use standard input and output. If all your practice is on LeetCode, where a function signature is handed to you, the first twenty minutes of a HackerRank assessment can go on parsing lines from stdin. Practise the harness, not just the algorithm.
In a phone screen you usually cannot run the code. Shared documents do not execute anything, and while CoderPad does, plenty of interviewers will not offer it. Verifying by running is therefore not a plan; tracing a small case by hand out loud is, and it doubles as a signal.
The take-home exists because the algorithm interview has known gaps. It rewards structure, naming, tests and a readable commit history — the things a whiteboard cannot see. Candidates who treat it as a timed algorithm puzzle produce working code that scores badly.
What actually gets written down
Immediately after a round, the interviewer fills out a form. At companies that train interviewers carefully, that form frequently contains a rough transcription of what you said, with timestamps — literally "0:05 candidate started coding" — because timestamps are how an interviewer benchmarks you against every other candidate they have seen on the same question.
Then come the basic facts. Did they get to a working solution? Was it optimal? Is there anything here that would break in production? These are close to binary, and they are what most candidates assume they are being evaluated on.
The judgment questions are where loops are actually decided:
- Would this person have made more progress with another ten minutes?
- Did they have a structured approach, or were they throwing darts?
- Did they course-correct when things went sideways?
Which produces the most important asymmetry in this entire track, stated plainly by an interviewer with over a thousand loops behind them: candidates with buggy code sometimes get a hire, because they showed they would have got there with more time or said out loud what they would do next before the clock ran out. And candidates with perfect solutions sometimes get a no-hire, because they could not explain their thinking and the interviewer concluded they had memorised the pieces.
Interviewers are trained to assess trajectory, not just the final answer. Everything else in this track follows from that sentence.
Behavioral rounds are scored against a rubric, not a story
The write-up for a behavioral round is not a summary of your anecdote. It has a shape, and the shape is signal, evidence, caveat, judgment. A real example, for a company whose rubric includes bias for action:
"Candidate is above our hiring bar. They proactively identified an important issue with the payment flow and shipped a fix within a week. Small caveat: their follow-up communication was messy, but this is coachable."
Three things are worth extracting from that. The evidence is specific and attributable to the candidate. The caveat is stated rather than suppressed. And the caveat is explicitly labelled coachable, which is the word that converts a weakness into an acceptable risk.
The same write-up usually carries a levelling assessment, which reads more like an argument than a score:
"This candidate seemed to be operating as an L6, but only for the last several months. I'd be weakly inclined for L6 but give an average confidence hire for L5."
Note what that sentence is doing. It is not deciding whether to hire you; it is deciding what you are. The behavioral track in this course is about the story; this track is about the fact that the story is being converted into two separate judgments and you can influence both.
The stages, and where the bar sits
The lengths are wildly unequal — thirty minutes, an hour, half a day, then days or weeks of waiting — and so are the bars. Hop two is deliberately easier than hop three: a screen is deciding whether an onsite is worth five engineers' time, not whether to hire you. Hop four is the one nobody prepares for, and it is where the story you told gets converted into a level.
| Stage | Typical length | Bar |
|---|---|---|
| Recruiter screen | 30–45 min | Fit and logistics, plus the compensation conversation covered next lesson |
| Technical or hiring-manager screen | 45–60 min | Deliberately lower than the onsite |
| Onsite | 3–5 hours, 4–6 rounds | The real bar |
| Debrief and decision | Days to weeks | Covered in module 3 |
Two facts about screens are worth more than they sound.
The screen bar is lower than the onsite bar, on purpose. A screen is asking whether an onsite is worth five engineers' time, not whether you should be hired.
Second screens are discouraged. Interviewer training at large companies actively steers away from running another screen when the first was inconclusive, because internal data shows the second one adds little signal. The instruction for a fence-sitter is closer to let's pass than to let's look again — which means an ambiguous screen is much closer to a rejection than candidates assume, and it is the cheapest place in the whole process to be crisp.
Your screen also sets your target level for the onsite. There is almost always leeway to up-level or down-level afterwards, but the level you screen at determines which rubric the onsite is run against, and being scored against a level above the one you are ready for is a harder failure to recover from than being down-levelled.
How much preparation is realistic
The most credible published estimate comes from an engineer who interviewed at eleven companies and received nine offers, including Facebook, Google, Airbnb, Dropbox and Lyft: about three months at eleven hours a week — two to three hours a day. That is the number to plan against if you have the runway.
Two adjacent pieces of advice from the same source are worth taking seriously because they contradict what candidates instinctively do:
Do not learn a new language for interviews. Becoming fluent enough to be comfortable under time pressure takes weeks at minimum. The commonly used interview languages are Python, Java, C++ and JavaScript; pick whichever of those you already know best.
The resume is a separate gate, and it is the first one. Before shortlisting, your past achievements are almost all that matters. After shortlisting, they matter markedly less than how you perform in the rounds. Effort spent polishing a resume you have already used to get an onsite is effort spent on the wrong gate.
What to carry into the next lesson
You now know that the loop collects evidence and that someone else decides. The next lesson is the first conversation in the process, and it is the one where an offhand sentence has the longest reach: the recruiter screen, and specifically what to do when they ask what you are looking for.