In my last post, I explained why we changed our junior interview process and mentioned that a longer explanation was on the way. Here it is. First, just to be clear: this isn’t a study guide.
You can’t prepare for this by cramming, and that’s intentional. If you’re still a student or recently graduated, think of this as a list of skills worth spending real time on, even if you never interview with us.
Our old interview really boiled down to one thing: could you remember the solution and type it out? That worked when experience matched recall, but it doesn’t anymore. Now, someone can learn a language in a couple of days and still write clean, idiomatic code. So, code alone doesn’t tell us much about the person who wrote it. What matters now is everything around the code: what you were asked to do, what you kept, what you left out, and how you decided any of it was correct.
Five things carry the weight for us.
Can you tell whether the answer is actually right?
This is the one that matters most, and it’s not close.
It’s more of a reflex than a skill: that little voice that asks how do I know this is true? before you act on anything, whether it’s an AI’s answer, a Stack Overflow post from 2019, a tutorial, or even your own assumption from a few minutes ago. In practice, it isn’t glamorous. You run the code. You test it with an unusual input. You check the official documentation instead of just reading a summary. You say, “hang on, let me confirm that”, even if nobody asks you to.
The tell shows up in how people talk about their own work. “It used a method I’d never seen, so I checked the docs before I trusted it” is a different person from “it usually just works, so I paste it in”. One has a boundary. The other doesn’t have one yet.
Here’s why this matters most. If you have weak fundamentals but a strong habit of checking your work, you’ll become a solid engineer in a few months because you’ll keep finding and fixing your gaps. On the other hand, someone with strong fundamentals but no habit of verifying their work can end up shipping confident bugs for years. The key thing to remember early on is this: it ran is not the same as it’s right. A program can run perfectly and still give you a completely wrong answer.
Something to try this week: next time you get an answer from anywhere, before you use it, write one line about how you’d find out if it were wrong. Then do that. It costs a minute and it rewires how you read everything.
Can you turn a vague ask into something checkable?
Real work doesn’t show up specified. It shows up as “make the export faster” or “users are complaining about the search”. Faster than what? Measured how? Complaining about what, exactly?
People who do well here start by restating the problem in their own words before they start coding. They also ask about what happens if things go wrong before they focus on making things work. Their prompts are specific, like “a function that takes this shape, returns that shape, handles the empty case”, instead of vague requests like “build me the feature”. If you give a good model a clear problem, it does great work. If you give it a vague problem, you’ll just get vague results back, and often more quickly and confidently than you’d expect.
Worth noticing: half of decomposition is realizing the requirement itself is undefined, and going to ask instead of guessing. Nobody can verify a solution against a spec that doesn’t exist yet.
Do you understand why things behave the way they do?
Not syntax. Not which framework is winning this year. The stuff underneath: where state lives, how data moves, what things cost, what happens at a network boundary, who’s allowed to touch what.
Here’s a quick example of the difference. “A hash map is O(1)” is just a memorized fact. “A hash map is fast because it turns the key into an address, so it doesn’t have to check the other entries” is a model you can actually reason with. Models like this are the only way to spot answers that seem right but aren’t. You can’t catch a bad answer if you don’t have your own understanding. This is especially important now, since you’ll read much more code than you write, and most of it will already look polished and confident.
Good sign you have one: you can predict what breaks when the input gets a hundred times bigger, before running it.
How fast do you go from zero to correct?
We don’t screen for whether you’ve used our stack. Ramping onto a new tool takes days now, and filtering on it just penalizes people for an accident of what their university happened to teach.
Instead, we pay attention to your approach. Do you take a moment to get your bearings before you start, like skimming the structure, finding the entry point, or checking for tests? Do you form a hypothesis and test it in a simple way, or do you change several things at once and then can’t tell what made the difference? Can you clearly explain what “ready” means to you, beyond just finishing a tutorial? The best answer I’ve heard is: I’m ready when I can explain what happens if it fails halfway through, and I’ve broken it on purpose and recovered.
For someone joining us for a few months, the slope matters more than the starting point. A second-year who taught themselves three things nobody assigned usually beats a final-year who did exactly the syllabus.
Do you say what you actually know?
“I’ve read about this” and “I’ve used this” are different sentences. People who mix them up cost their teams a lot.
In a workflow that relies heavily on AI, how confident you are in your work is the main way others know what to trust. If you point out the lines you’re unsure about, reviewers know where to focus and your pull request improves quickly. If you act equally confident about everything, your work becomes hard to review, not because it’s bad, but because nobody knows what to check. Admitting “I don’t know” right away, and saying “I was wrong” without making a big deal out of it, is more valuable than it seems.
It’s also the hardest of the five to teach, which is exactly why we watch for it.
The hands-on part is deliberately bigger than the time
There’s a practical session, and you’re not going to finish it. We tell candidates that upfront so nobody panics.
The task is intentionally larger than what you can finish, because we’re not judging you on completion. We’re looking at how you prioritize. What did you tackle first? What did you leave out, and did you explain why? Saying, “I’m dropping the extra feature to make sure these numbers are actually correct”, is a strong answer. Quietly skipping it and hoping nobody notices is not as strong.
Tools are allowed and encouraged, since banning them would just be testing a workflow nobody uses after week one. What we’re looking at is how you use them: whether you look at the real data before writing code against it, whether you read what came back before running it, whether you can explain every line you decided to keep.
If you deliver half the work, but all of it is checked and you can clearly explain your choices about the rest, that stands out to us more than someone who finishes everything but doesn’t check any of it. This isn’t a consolation prize, it’s how we actually rank candidates.
What we stopped caring about
Since a lot of interview prep still points here, it’s worth naming what we dropped:
- Closed-book syntax recall. Testing memory under artificial deprivation mostly measured test anxiety.
- Puzzle-site grinding. Solvable in seconds by any assistant, and a weak predictor of judgment anyway.
- Trivia and API lists. Pure lookup, version-specific, gone in eighteen months.
- Having used our exact stack. Costs days to fix, not months.
- GPA and which university. Weak signal about engineering, strong signal about background.
- Policing AI use. Unenforceable, and it selects for people willing to hide how they work.
That last one deserves saying plainly: we’d rather see you use the tools and tell us which part of the output you didn’t trust.
You don’t need a job, a mentor, or anyone’s permission to work on these five skills. You can develop all of them on a project you start yourself, with no one grading you. That’s exactly why it’s the best way to practice. Try verifying one answer today. Ask what the requirement really means. Dig a little deeper into something that works and find out why.
