I failed my F**king 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 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 eats 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 then 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 actually 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:
Other Articles on shaneshown.com:
Scientific Computing Scientist in Mathematics-Statistics | Machine Learning | Causal Inference | Implementation and Development in Data Science
3 年This is (another) brave post. Although this writing is for fundamentally about developers'?coding interview part, the interesting part is that I've seen many posts on LinkedIn from expert developers, in say X, confessing "failing" their coding interview part in X, where X can be SQL or whatever. Because many of these interview questions are done with "coding in the air" style, i.e., out of actual platform, where you are expected to memorized, AUTISTICALLY, the X's syntaxis, I wonder why some interviewers are still expecting to get the code 100% right, even from experts who only works with X, all the time. The sad part is that this culture has, to certain extend, been adopted to many jobs nowadays that include some codding, far away from coding intensive roles as software developers. It is a joke and a kind of abuse of power. The fact that many are coding using internet as a guide and help today and people are seldom warned in advance that the interview has a coding part, whilst the interview is happening, makes thing "funnier" Shane Shown. Take home exams are more close to reality to the current coding culture, at least for not software developers.
Cybersecurity | Software Engineer | Artist | SAR
6 年Good article. Unfortunately, your right when the answer is to study for these interviews -- after explaining to us that some of these skills arent used in the position. I do want to point out that getting the answer correct wont necessarily land you the job. Writing the most optimized O(n) time complex solutions will.
Consummate Code Crafter
7 年Good read, thank you. When I was less experienced I used "Programming Interviews Exposed: Secrets to Landing Your Next Job" as my interview prep. I still dread the whiteboard or trick question interview. I've been around the block now and generally short circuit them and get them to pair with me and write some code in an IDE. I'm more frequently on the other side of the table, interviewing people. Being an XP developer who only works in an XP environment, I roll up my sleeves and write code with who Im interviewing. Most of the time it's TDDing Fizzbuzz, but sometimes it's writing production code. A vast majority of developers have never written code paired (at a pairing station), have done true TDD (following the Three Rules of TDD) or experienced them both using test ping pong. Those rare XP devs that I interview, never leave the building without an offer. Those that show aptitude for XP and want to learn, generally get an offer. Those that just don't get it, don't get it. I'm always upfront about what interviews with me will be like. "You will be writing code with me, on a simple non-tricky problem, doing TDD and paired." Ask the people. You are going to interview with, what type of interview you could expect.
Engineer, creating value for the shareholders
7 年The photo is exactly how Jarred Taylor and I were hoping to interview
Recruiter | Technology & Insurance
7 年Great read, thanks for sharing!