I failed my effing coding Interview!?

Coding interviews are a love/hate relationship with most software engineers. There are radical vantage points on what is the right way to interview on incoming software engineer for a specific or general position. These interviews can be high level conceptual conversations, screen-sharing interviews (i.e. Collabedit), white-boarding, paired-coding, or a variety of other styles. There is not a consistent pattern or style of interview among the tech industry. So, what does that mean? It means that engineers and developers DO NOT KNOW how to properly prepare for every single interview. These interviews vary be drastically different in topic and level of difficulty company to company.

Common among clients in the past, these interviews epicenter around writing code on a whiteboard while having the interviewee “think out loud” and explain themselves every step of the way. It’s an odd and somewhat dated process, but these interviews aren’t structured this way in order to optimize for modern implementation.

Why coding interviews are standard

If you ask an engineer about their experience in a coding interview, every engineer’s answer is going to be drastically different depending on their background. It is a very sensitive and controversial topic. You do NOT want me to repeat some of the comments and stories that I’ve heard over the years (You may end up with bloody ears or sore stomach from laughing). Most engineers believe that technical interviews are not relevant to the actual position, nor do they show the individual’s true technical competency.

And these people have a point — these interviews don’t represent real work. Developers never really have to write in-depth code on a whiteboard during the day-to-day job. In addition, the majority of topics covered in coding interviews are never seen outside of interviews. How often, for example, will a front-end developer specializing in React have to traverse a B-Tree in a specific, algorithmic way? Never, unless they’re doing something deeply wrong.

When a candidate does run into a interview that represents real-world problems that would need to be solved in the day-to-day of the actual position it’s MIND-BLOWING. I have had candidates leave an interview with a coding assignment that they were actually excited to complete, because they felt like they would understand the company’s problem and add real value.

Even more aggravating? Coding interviews are often entirely unfair. Even the creator of Brew — with tens of millions of installs — was invited to interview at Google and then rejected because he couldn’t solve a B-Tree problem.

Software engineers love to trick the interviewees and give extremely challenging questions. If you get the initial problem, it’s the common practice for an interviewer to throw a wrench in your solution, make the problem even harder, and create arguably unnecessary stress.

So why are they given?

For all their faults, coding interviews prove three things:

  • The candidate really wants the job, and has put in significant effort into preparation. If an interviewee hasn’t spent the time to get good at the process, it’s quite obvious. Companies want to hire people who put in the effort.
  • The software engineer can solve problems and actual code. Engineers who have to copy/paste scripts other people made, or who don’t have enough experience with a language, will often make big mistakes while problem-solving and coding up solutions.
  • The software engineer can effectively articulate their problem-solving. Engineers often will fail to solve the problem, only to find that they actually passed the interview. How? The interviewer decided their thought process was good enough.

How coding interviews vary across companies

How a company interviews people is a direct correlation with the quality of talent they attract. The best companies optimize their recruiting processes to “reduce false positives.” A bad hire that made it through the process will hurt the company much more than rejecting a potentially good hire. The best companies tend to have the hardest interviewing process.

Therefore, when you find that a hiring process especially easy, it’s likely the company has weaker engineering. This isn’t always true, of course, but it’s certainly something to keep in mind.

Since it’s extraordinarily tough to guess which topics will be covered in an interview, the keenest strategy to prepare is to literally prepare for everything. That is… if you really want a great job. Otherwise, ask the recruiters or hiring managers for something to study/prepare prior to the interview. If you need time to prepare, be direct and honest.

Preparation is everything! But how?

It takes time to be proficient at interviews. They are a completely new muscle in your body that needs exercise and need training. If you don’t continuously touch base with fundamental, you’ll eventually be the fat cat that can’t waddle its way to the bathroom anymore. You don’t want that! Don’t piss on yourself when you go to interview! When people begin the process of preparation, it feels like you’re running a mile again after 5 years of zero cardio.

You have to have faith in research, studying, and practice. Run some practice laps once in a while.

If you want to work at a top tech firm, like Google or Facebook, we recommend you practice for:

  • Experienced Engineer: 4–6 weeks, 2 hours a day
  • New Engineer: 6–8 weeks, 3 hours a day

For more mid-range companies, like Series A/B startups, you can usually get away with less preparation:

  • Experienced Engineer: 2–4 weeks, 2 hours a day
  • Bootcamp Graduate: 4–6 weeks, 2–3 hours a day

Yes, it is a lot of time, and you may be thinking “do I really need to prepare that much?”

And our answer is to look back up at that 10% number. You need to prepare this much if you actually want job offers. Even with this preparation, you should still expect to fail half of your interviews (Sorry, but not sorry if you didn’t prepare).

Some of the common topics:

  • Trees
  • Hash Tables
  • OOP, Systems
  • Big O
  • Recursion
  • Stacks/Queues
  • Arrays
  • Linked Lists
  • Algorithms: BFS, DFS, Binary Search, Merge Sort, Quick Sort
  • Bit Manipulation (few interviewers give these, but cover them anyways)

Expect questions relating to your experience as well: technologies, languages, frameworks, etc. SQL challenges and questions are very common.

Methods to prepare

Some online training systems are fantastic. There are both paid and free trainings on the internet.

Some of these sites include:

  • BitTiger — $99/Month — Coding interviews that teach you universal patterns in multiple fields: Big Data, Full Stack, AI, Data Science, UI/UX Design, and Business Intelligence.
  • GeeksforGeeks — Free — One stop shop for a high-level overview on most technical interviews, from Basic to Expert level assignments. In addition, a lot of the top name brands have their interview prep requirements posted here.
  • Triplebyte — Free — Take a quick online coding quiz instead of providing a resume. The company will start to automatch you with companies you meet basic coding requirements. Fast track interviews!
  • Pramp — Free — Tell them when and what you want to practice and they’ll pair you with an optimal peer. They provide interview questions (and answers) you will both use to interview each other. Coding interviews are live video sessions with a collaborative code editor. You and your peer interview one another for 30 minutes each. After the interview, you both rate the other’s performance. Learn from peers’ feedback, gain confidence and master the art of interviewing. Keep practicing until you interview like a rock star. Impress recruiters and land awesome job offers.
  • Interviewing.io — Free — Free, anonymous technical interview practice with engineers from Google, Facebook, and more. Get actionable feedback, get awesome at interviewing, get fast-tracked at top companies.
  • Codefights — Free — There is an arcade to solve problems and advance your skills in an interactive environement like a videogame, interview practices, head-to-head coding competitions with peers or strangers, tournaments, and company bots.
  • Research a topic and ensure you understand it holistically
  • Tackle ~3 easy practice problems on & review solutions until you understand them completely
  • Solve 2 hard practice problems & review solutions until you understand them completely

As you complete each topic, realize that you’ll want to re-visit it 2–3 times every week subsequently to keep it fresh in your mind! These things are easy to forget, and when you get a problem in an interview, you want the type of problem to be instantly recognizable.

As you train more and more, you will develop a level of intuition around new problems. The hardest part is getting started with preparation, so push through the difficulty!

How to know when you’re ready

You can’t know for sure. Even the most prepared people can freeze up and fail interviews, so at some point you have to call it a day and jump into the deep end.

Still… when do you jump?

If you can get a mock interview from someone at a top company, even if you have to pay for it, it’s worth it. They’ll both have a high bar and be able to give you specific feedback (as long as you’re outside of their company’s interview process). Maybe you have a buddy that will help you out!

Finally, it’s worth stating that you can also treat your first interviews as initial groundwork. Simply apply to companies you’re less interested in, and use the interviews as practice (I am sure some of the hiring managers reading this article are giving me the finger right now). People will often take interviews they don’t actually care about in order to get live practice in front of companies.

Happy Hunting and good luck!

Other sites:

Interviewbit.com

Themuse.com

VentureRadar