So you want to change job. You clean up your CV, add some cool tech you’ve worked with recently. Then go on some job boards and put yourself as available. Recruiters start calling you, interviews get scheduled. So far so good, but how do you really prepare for them?

Truth is, there’s no general answer to that.

There’s few different interview styles around, which can also tell you a lot about who you’re interviewing with.

In the first bucket we have those Companies that want stuff done and they want it now. Usually interviewers here tend to ask simple questions on the lines of “do you know [insert framework name here]?” or “what’s the latest version of this [insert JS library here] you have used?”.

These places normally don’t have any interest for career progression. Which might be exactly what you want, if you’re in the consultancy business. There’s some decent money, a bit of pressure but very low responsibilities on the long run.

In the end it all boils down to what you’re looking for.

In another bucket instead we have those Companies (usually pretty small) who secretly believe to be a FAANG. They try to mimic as much as possible FAANG interviews, even though there’s absolutely no need for that complexity. It will never be part of the job.

So you might get absurd questions like “write a sorting algoritm in O(1)”. And the job then is to configure Wordpress websites.

Maybe here you can learn a thing or two. But usually people working here are egomaniac jerks, who find pleasure in showing off their (usually limited and extremely narrow) knowledge, without really being helpful.

I have been interviewing people for a while now. And I’m still doing it at Microsoft. Even though each team has its own processes and methodologies, our interviews tend to follow a general pattern: the candidate goes through 3-4 rounds of coding questions or system design and behavioral questions.

This is no mystery at all, there’s plenty of websites around explaining how Big Companies like Microsoft run interviews.

And it’s no secret that in most of the cases the coding questions are taken straight from websites like Leetcode or Hakerrank.

So normally what happens is that people will spend 3-6 months grinding through the various problems, maybe memorize few solutions and then test their luck. And sometimes they manage to land an offer.

Then after few months, maybe around the end of the probation period, or maybe after a year, they realize that it’s quite hard to keep the pace. They get stressed, in some case even burn out. So normally what they do is either change team (good luck with that) or start interviewing around with other Companies.

Why? Well, I’ll put it simple: they’re a fraud. You can’t just study for an interview. Unless you’re trying as an intern or a very junior role, there is no way you can keep up. Fake till you make it is not going to help, at least not on the long run.

My advice is condensed in a single word: study. But not just for the interview. Study algorithms, design patterns, system design. Then create prototypes, try new tech, go to events and congresses. This will help you building that muscle that is usually called experience.

It will also help you survive when the interviewer goes past the Leetcode problem and starts probing you with other additional questions. How would you test this code? Is it thread safe? If no, how can we make it so? How do we make this code scale horizontally?

That’s the moment you realize that these questions are the actual interview.

When you interview at a Big Company, the expectation is that you already know how to code. You’ll get tested on what’s after that. Monitoring, instrumentation. Scalability. Resiliency. Performance.

The coding challenge was just a bait to get you exactly there.

Did you like this post? Then