Four questions show up in bootcamp grad loops that CS grad loops mostly skip: why the bootcamp, what have you built since it ended, explain a fundamental nobody formally taught you, and how do you learn something hard. The third one ends the most interviews, and it almost never arrives with the word "fundamental" in it. It arrives as "nice, what's the time complexity?" about the code still on the screen. Below: what each question is really sampling, the full complexity answer written out at the depth a CS-degree interviewer expects, and a spoken drill sized to five minutes a day.
Why these four exist at all
A transcript is a set of assumptions an interviewer gets to make for free. Three or four years of coursework is an unstated claim that this person sat an algorithms course, a systems course and an operating systems course, and was graded on each by somebody who was not being paid by them. Nobody extends that credit to a fourteen week program. So the loop reallocates its minutes. Same forty five, different distribution: less time on culture fit, more time on prove the floor.
That is not a judgement about bootcamps. It is an information problem with a deadline. The interviewer has a gap and one conversation to close it. Your advantage is that the gap is predictable, which means these four should be the easiest part of your loop rather than the ambush they usually are.
| The question | What it is actually sampling | The answer that fails |
|---|---|---|
| Why the bootcamp? | How you explain a decision, because your next career decision will be explained the same way | A grievance about the old job, or an apology for the new path |
| What have you built since? | Whether you write code when nobody assigns it | The capstone, which they have already seen from your cohort |
| Explain a fundamental nobody taught you | Whether the floor is real or memorised | "O of n, O of n space", four words, then silence |
| How do you learn something hard? | Whether you can onboard without a curriculum | "Tutorials, and then I build a project" |
Question one: why the bootcamp?
Answer it as a decision with rejected alternatives. Four sentences. One on what you did before and which part of it was already engineering adjacent, because there almost always is one: the spreadsheet you automated, the reports you scripted, the lab data you cleaned. One on the trigger, specific and dated. One naming the options you weighed and why you dropped them, part-time masters, self-teaching, staying and moving internally. One on what you would do differently, which is the sentence that proves you evaluated the choice afterwards instead of defending it.
Do not open with what you were tired of. The interviewer is not scoring your old employer, and a candidate who narrates a past job as a villain is forecasting how they will narrate this one. Say it once, past tense, then move to the decision.
Question two: what have you built since?
The trap is answering with the capstone. Capstones are a known quantity, and if the interviewer has hired from your program before, they have seen four of them with the same stack and the same seeded database. The interesting signal starts the day the curriculum stopped telling you what to build.
Bring one project with a real user who is not you, one thing that broke after it went live, and what you changed so it stopped breaking. Small honest numbers beat vague large ones: forty users, three thousand requests a day, one Postgres box, one incident where the free tier database went to sleep and you found out from a user rather than from an alert. That last detail is worth more than the feature list, because it is the only part of the story that could not have come from a tutorial. A merged open source pull request works too, especially if you can quote the review comment you got and what you changed because of it. Someone else's standards applied to your code is exactly the evidence this question is fishing for.
Question three: the complexity of the code you just wrote
This is the hard one, so here it is in full. It looks like a one line question and it is a five part question, and the CS grad answers all five parts unprompted because that is how their algorithms course graded them.
Take longest substring without repeating characters, solved with a sliding window and a map from character to last seen index. You have just typed it. The interviewer says: what is the complexity?
The bootcamp answer, which is not wrong, is "O(n) time, O(n) space." It is correct, and it scores about half the points on offer. Here is the same answer at the depth the question was asking for. Spoken, it runs about seventy seconds.
Two variables matter here, n for the length of the string and k for the size of the alphabet. The right pointer advances n times. The left pointer also advances at most n times, but across the whole run rather than once per iteration, so that inner loop is amortised, not nested. Every character enters the window once and leaves at most once, so total pointer movement is bounded by 2n and the time is linear, O(n). The map operations are expected constant time rather than guaranteed constant, because a hash map degrades under collisions, so strictly this is O(n) expected. Space is O(min(n, k)), since the map never holds more entries than there are distinct characters. If we assume ASCII input, that is bounded at 128 and constant in n. And O(n) is optimal here, because you have to look at every character to know whether it repeats, so there is no sublinear solution worth hunting for.
Five moves are doing the work in that paragraph, and they transfer to every problem you will ever be asked.
Name the variables before you name the bound
n is rarely the only one. Strings have an alphabet size, graphs have V and E, matrices have rows and columns, and a graph solution quoted as O(n) is marked wrong even when the code is right. This move alone separates two thirds of candidates.
Separate the dominant term from the amortised one
A while loop inside a for loop is not automatically quadratic. Say why: the left pointer is monotone, it never moves backwards, so its total travel across the entire run is bounded by n. That one sentence tells the interviewer you derived the bound rather than recalled it.
Say which case you are quoting
Worst, average, amortised or expected. Out loud, by name. Quoting a hash based solution as O(n) without the word expected is the most common half-point loss in the round, because it is the exact thing a data structures course drills.
Give space, including the call stack and the output
A recursive in-place traversal is not O(1) space. It costs O(h) for the stack, where h is the height, so O(log n) on a balanced tree and O(n) on a degenerate skewed one. Name the height, then name what makes it degenerate. If you allocate the answer, say whether you are counting the output.
State the lower bound
Finish with whether a better answer could exist. "You must read every character, so linear is optimal", or "comparison sorting cannot beat n log n, so this is as good as it gets without exploiting the value range." Almost nobody volunteers this, and it reads as coursework in the best way.
The four words people use interchangeably, and interviewers do not
This is the vocabulary gap in one table. Learn the fourth column as literal sentences.
| Term | What it averages over | Canonical example | The sentence that proves you know it |
|---|---|---|---|
Worst case | Nothing. No input does worse. | Quicksort with an adversarial pivot is O(n^2) | "This bound holds whatever input you hand me." |
Average case | A distribution over inputs | Quicksort on uniformly random input is O(n log n) | "That assumes an input distribution, and I am assuming random order." |
Amortised | A sequence of operations on one structure | Dynamic array append: amortised O(1), worst case O(n) on the resize | "Any single call can be slow, but n calls together still cost O(n)." |
Expected | Randomness inside your algorithm, not in the input | Randomised quicksort, or a map with a randomised hash seed | "The randomness is mine, so an adversary cannot pick a bad input." |
The same problem three ways, and what each line earns
| Approach | Time | Space | The line that earns the point |
|---|---|---|---|
| Every substring, rescan each one for duplicates | O(n^3) | O(min(n, k)) | "Three costs stacked: two for the substring bounds, one for the duplicate check." |
| Every substring, build a set incrementally | O(n^2) | O(min(n, k)) | "The set removes the inner scan, but both bounds still move independently." |
| Sliding window, map of last seen index | O(n) expected | O(min(n, k)) | "The left pointer is monotone, which is where the extra factor of n goes." |
Then come the probes, and they are predictable. If the alphabet were arbitrary Unicode rather than ASCII, k stops being a constant and the space really is O(n). If every key collided, map operations degrade, to O(n) per operation in a simple chained implementation, and to O(log n) per bucket in implementations that convert oversized buckets into a tree, which is why "expected" was the correct word. Yes, you can do it in O(1) space for a fixed alphabet using a 128 element array, and you should add that this is the same bound restated rather than a new result. If they ask why the array version benchmarks faster than the map version when both are linear, the answer is constant factors and cache locality, which complexity classes deliberately discard and profilers do not. To mark your own spoken walk against a reference, Code Copilot returns an optimal solution with the intuition, a dry run and the Big-O for a problem you screenshot, which is useful as an answer key while you drill.
Question four: how do you learn something hard?
"Tutorials, then I build a project" is a description of a bootcamp, which is the thing they are already worried about. The shape that works names one specific hard thing, your entry point into it (the docs, the source, a failing test you wrote purely to find out what happens), the exact place you got stuck, how you got unstuck, and how you knew you had it. That last part is the whole answer. The strongest version anyone gives is some form of "I knew I understood it when I could predict what the code would do before running it, and I was right." Prediction is the test. Say the test out loud, because it is the part that cannot be faked.
The five minute daily drill
Five minutes buys exactly one repetition of one thing, so the plan below is one thing a day and it is not solving. Solving is a separate hour. This is the spoken layer, which is the layer being graded in question three and the layer nobody practises, because saying an answer you already know feels like it does not count.
0:00 to 1:00, name the variables
Open a problem you already solved this week and re-derive nothing. Read your own solution once, then say aloud what every input variable is and what it measures. This is the minute where you find the second variable you had not noticed.
1:00 to 2:00, name the case
Say "worst", "average", "amortised" or "expected" out loud, and justify the pick in one sentence. If you cannot choose confidently, you have found today's gap and the drill has already paid for itself.
2:00 to 3:30, one unbroken take
Record the full five move answer on your phone in a single take. No restarts, no notes. One take matters because a live interview is one take, and the usual failure is not ignorance, it is starting the same sentence three times.
3:30 to 4:30, mark the missing move
Play it back and find the one move you skipped. It is almost always the lower bound or the call stack. Do not re-record. Just identify the omission.
4:30 to 5:00, write the missing sentence
One line in a note. Tomorrow, on a different problem, you say that sentence first. Five days of this and the missing move becomes a reflex instead of a checklist item.
Rotate the problem type across the week so you exercise the vocabulary instead of reciting one bound. Monday a sliding window or two pointer, for amortised. Tuesday something sort based, so you have to explain why the n log n swallows the linear pass. Wednesday a recursive tree traversal, for call stack space. Thursday anything hash based, for expected. Friday a graph traversal, where O(V + E) is the answer and O(n) is a wrong answer. Twenty five minutes for the week. It also happens to fit the free plan of OfferPilot AI, which is five minutes a day with no card required and meters only while audio is actually being received.
Where this stops working, honestly
A script does not close a real gap. If you have never written code that manages its own memory, no phrasing survives a question about what happens when a slice outgrows its capacity, and the interviewer will find that edge within two follow-ups. The drill above makes you fluent about what you already know. It does not manufacture knowledge. If question three keeps ending your loops even when you deliver all five moves, the fix is three weeks with an actual algorithms textbook chapter and a pencil, not three more weeks of polishing delivery.
Some interviewers ask question one in bad faith, having already decided what a bootcamp means. You cannot script your way through that one. Answer once, cleanly, and do not defend it a second time.
And a plain word on tooling, since this page is published by a vendor. OfferPilot AI runs on Windows 10 and 11 only, with no macOS, Linux, mobile or browser version. The overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams, Meet or a recording, but that does nothing about a webcam watching your face, a lockdown browser, an interviewer sitting across the table, or a phone camera pointed at your desk. More to the point for this page: question three is the wrong question to answer live. A complexity walk read off a screen sounds read, and the interviewer's "why?" lands within ten seconds, which is where the real question always was. Use it while you drill and while you build the answer. Do not plan to lean on it for the sentence that decides the round.
Four questions, and only one of them is hard. Write the decision for question one, find the post-curriculum project for question two, drill the five moves for question three, and name your prediction test for question four. That is a week of preparation covering the part of the loop that exists specifically because of your background.