— First, pick the language you are most comfortable with. Ive seen many candidates go into an interview and decide on the spot they wanted to use Scala instead of Ruby. Or C instead of Java. Mistake. Pick one language and stick with it for all your time studying & interviewing. Know the ins and outs of the language so that you can write code
45-60 minute interview sessions in a room with a whiteboard. The whiteboard may be replaced with a laptop in some cases, but this is less common.
Ive seen that the first 4 algorithms in the list apply to a disproportionate amount of interview questions (~1/3).
— If youre already getting InMail requests on LinkedIn,
In summary, the real hack to the coding interview is that if I have a big pipeline of companies all using this interview technique then if I screen at Company A on Tuesday and bomb out on a question, I may well get the same question on Thursday from Company B. Company A evaluates me to be low skill and Company B evaluates me to be high skill. Sooner or later, someone will ask me questions I know and Ill be evaluated as high skill.
Trees & Graphs, Recursion & Dynamic Programming, Arrays & Strings, Sorting & Search, Stacks & Queues, OO Design,Linked Lists, Bit Manipulation,
— Update LinkedIn profile as soon as possible to highlight your latest work. Also start reaching out to all friends you have to see if their company is hiring. Get co-workers to write recommendations for you; the more the better.
to prepare for the interview, nothing lined up, and about 2 hours a day to spend, every day, during evenings and weekends. Well also assume youre working at a job during this time. Lets be clear, your success will be directly correlated to how much time can be spent studying & on LinkedIn. Remind yourself how badly you want this.
Train the interviewers brain to be a coding problem pattern recognizer to improve coding interview skill
From here on out lets assume you have
So youve been training hard for a couple of weeks and your lead generation pays off. You land an onsite interview and you want to do well. Youll always be nervous beforehand, but the trick is to A) let your training kick in and B) apply a deep understanding of human relations.
3 to 6 interviewers. Mostly developers, usually includes a hiring manager and sometimes product manager(s). Sometimes you will have 2 interviewers at a time; this usually means a junior interviewer is shadowing a more senior one.
Generating leadsIf youre buying a house, youd be silly to put an offer for the first one you see. Likewise, with interviewing, you should look at as many options as possible. Lead generation is the idea of advertising yourself in such a way that you generate maximum possible interview interest. How can we do this?
Out goal is to optimize for offer quality. More offers = more choice = more negotiation leverage = higher pay/better position.
— Bring a notepad with you and write the names of each of the interviewers you talk to during the day. Writing their name down at the beginning of the interview looks professional and will help you remember their name during the interview. Once the interview is done, write what question they asked you and how you think you did for each question. Be self-critical and drill into areas you think you were weak in future studies.
—Understand Big-O notationandhow to applyit to any algorithm you write. Time and space complexity analysis is always asked as part of the coding interview. For every coding problem you solve, you should learn to subconsciously apply this when evaluating the optimal approach.
offer quality (position & compensation)= ( of offers) x (Experience in CV)
— For companies that you wouldnt want to work at, but would be easy to interview at, add these to a B-list. Well want to interview at these places first to use them as practice runs.
— In cracking the coding interview, questions are divided between different categories which require specific approaches well want to master. The most important types of problems to master are(in order):
— From here on out we will only be coding on paper since this mirrors the interview environment best. Being near a computer helps to look up syntax/algorithms, but write everything out by hand. This will help greatly building muscle memory for algorithms.
— The following algorithms are useful to know in an interview, but you might not use day-to-day: Breadth-first search, Depth-first search, Dynamic Programming, Binary tree traversal, Merge Sort(asked a lot for some reason), Djikstras algorithm, Tail recursion, Threading & concurrency patterns.
— If youre lucky enough to have an offer from another company before going in to interview, you will do amazing. There will be no fear to hold you back, your self confidence will be sky high and youll simply do your best without worry. If your lead generation is able to yield enough interviews, this might happen, and youll be golden.
Assuming we cant increase the interviewers raw intelligence or experience in a short time span, we will focus on the following:
. Remember, time is limited in interviews, and you dont want to waste it fumbling. Consider picking a language with good library support. Using the provided HashMap in Java beats writing your own from scratch in C.
Over the last 7 years Ive given and received enough interviews to see a couple of patterns emerge. I think its rather unfortunate, but proper preparation and foreknowledge of the process can make as much difference as simply being the right person for the job. As a result, Ive also seen a lot of false positives & negatives occur. Im really interested in getting to the bottom of this sincethe most important decision a company makes is who to hire. One rock-star engineer you can trust to get the job done is worth five mediocre ones. Hiring the wrong people can have disastrous consequences on effectiveness, morale and culture.
— So youre interviewing at Google and lunch time comes around. Food is free so you eat way too much, especially carbs. Your post-lunch interview is a disaster since you have trouble focusing due to lethargy. True story.
— Not, like, the whole field 🙂 But readHow to win friends and influence peopleby Dale Carnegie. Many points brought up in this book are directly applicable to the soft side of the interview process. Seriously, consider this mandatory reading.
— When interviewers propose a problem, you can ask a clarifying question that steers the problem in an easier direction by calling out simplifying assumptions. The opportunity to do this comes up more often than youd think and is easier the more you study. Ex: Instead of coding a sort method from scratch, assume you can use the inbuilt sort method. Boom, you saved 20 minutes.
The idea is that after a couple of weeks you should have a couple of B-list phone screens & on-sites done. If any A-list interview opportunities come up, push them out so that you can have enough B-list preparation. You might even have a couple of offers by the time you start A-listing.
Build a solid lead generation pipeline to increase of companies interviewed
In parallel with lead generation, we need to train your brain to think in terms of coding interviews. This is where you will spend the majority of your time every day. This way of thinking is extremely different from how you approach writing software on your own with an IDE & internet connection. So different, that this is the number one reason for false negatives in interviews.
— Youre asked to solve a problem, and you pull a complete blank. You force yourself to solve the problem in a way youre not sure will work. After 20 minutes, you coding in circles. This is a very common pattern and results in a poor interview. In order to recover, communicate as much as possible you thought pattern. Spell out all assumptions youve made up until this point and question them in a conversational way with the interviewer. In the end, interviewers will usually give hints if they see that youre too stuck.
Some companies are moving away form the last point and doing things like pair programming and live code debugging. I think this move is very interesting, but I havent seen this applied in a scalable way at larger companies.
— Your progress will be very slow at first. Painfully so. You wont remember basic algorithms from CS 101 and youll feel stupid and scared about the interview. Youll be very nervous until you start doing some of the B-list interviews. And then, all of a sudden, things will start to click and youll start seeing patterns. A scary looking graph question is a simple matter of applying BFS (which you can write up blindfolded now), linked list questions will be a joke, you will be a master of recursion… etc.
(even those that youre not interested in). Many requests come from come from headhunters who can connect you with companies you might care about interested in.
These are the typical steps in the interview process from first contact to offer letter:
Hacking the coding interviewwas published onSeptember 03, 2013.
— Dont try to solve problems that arent asked. Its very easy to start solving a problem, and suggest going down a very complex route. Make sure youre only solving whats being asked, otherwise you can hurt yourself. Sometimes interviewers will let you go down a winding path if they havent prepared for the interview. Which leads to my next point …
Pasta enthusiast & restless programmer.
— In order to buy time for yourself, youll need to stop doing any overtime at your current job\school. Do the minimum possible to meet your commitments, but no more. Your priority now is your job hunt.
Theres a good bit of variety in how on-site interview panels are set up, but at the end of the day this is what will be used to judge whether you get a job or not:
— ABC. Always be communicating. Candidates that get a problem and write code for 45 minutes without saying a word will not get hired. Communication abilities are as important as coding abilities in a software development environment. Ask questions. If you get stuck, spell out your exact thought process and what youre trying to do next. Even if you dont solve a problem, being able to explain whats going on in your head counts for a lot.
Ill probably add to this over the coming days if I can think of more. Id like to get feedback and dissect some of whats going on here. A lot of what Im suggesting to do is pretty extreme. A lot of the skills here are not something you learn by doing a standard software engineering job (or get coming out of college). Its especially hard for more senior engineers to do technical interviews since most have limited time due to familial obligations and havent taken CS 101 for quite some time.
— Every day, you should aim to get 4-5 interview questions completed. You will do this until the last day you accept an offer. If you have 15 minutes to spare, do an interview question. This is your new hobby, which you will eat, sleep and breathe.
— You will probably get soft questions and these should be part of your training regimen. You should have well thought out, convincing, canned answers for some of the following: [Describe the current project youre working on, Describe a time you had a disagreement with a colleague and how you handled it, Whats your biggest weakness, Why do you want to work here]. Some of these questions are valid (always know why you want to work at a place youre interviewing). Some are bullshit since if youre caught off guard, you can give a terrible answer that ends up inadvertently hurting your chances.
We should presupposethis happens, and focus on building pattern recognition before even entering the first interview. The faster the interviewee gets to peak pattern (a level that varies by individual) the more offers and leverage they have.
—Never argue with the interviewer, even if theyre wrong. You should politely point out if you think things are obviously incorrect, but if they insist theyre right, dont press the issue. The interviewers pride is not to be trifled with, and doing so will always backfire. Agree that youre wrong and move on; the interviewer usually realizes things on their own after.
of offers= (coding interview skill) x (raw intelligence/skill) x ( companies interviewed)
I propose the following model as predictor of offer quality:
Math & Prob, Scalability & Memory, Testing, Databases, Threads & Locks
— Your ability to verbally communicate your thought process during the interview will be a huge asset. Practice talking to yourself while coding (maybe using the inside voice if youre shy).
— Track your progress as you go through problems every day. Do all your work in a notebook where you write down each problem on a separate page; this will be useful as you start to see patterns between problems. Keeping a sheet that records all the problems you go through helps build confidence and a sense of accomplishment. Here is an example:
What Id like to do is spend the remainder of this post being a hacker whos goal is to get the best offer at a company possible (compensation, position). We will employ all means at our disposal, save for anything dishonest. Think of this asattacker-centric threat modeling. Once we gain an understanding of how one can optimize & exploit the existing process, we can look at flaws and propose a fix.
The fact that I can write this, and its true, is the saddening fact Im trying to change.
Defining a model for interviews success
At any point, the process can dead end — for a variety of reasons. Theres a lot to say for each step, but Id like to focus on the on-site interview for now.
— Never, ever jump straight into a question. Think of exactly what clarifying questions you would want to ask had this been an in person interview. Many candidates get dinged for jumping into a question they dont really understand. For each interview question you study, clearly define an interface for the algorithm. If you can think of multiple solutions, learn to pick the best one(see next point 10). Explicitly call out edge cases as youre coding. Once you finish writing code, youre not actually done; verbally go through the code you wrote and confirm it does what it should. Catching bugs in your code without being told is a plus.
— Identify the companies on your A-list, places youd really love to work. If you have any contacts at these companies, reach out to them expressing interest early on. Referrals can work on the inside to get you an interview. Their past experience with you is usually seen as huge plus that can override poor interview feedback in some cases. If you are applying cold to companies on your A-list, go to the careers\job section of their website (these always exist) and apply directly.
— If someone likes you, they are more likely to give a hire. This doesnt happen all the time and interviewers might not realize that it happens, but it does play a role. Two things to try in every interview are 1) try to get the interviewer to laugh and 2) try to get them to tell you something personal about themselves. Doing this at the beginning of the interview is best, and it only works if it feels natural (as with all things).
The technical interview process used to hire software engineers/developers hasnt changed much over the years. A couple of coding problems to solve on a whiteboard for roughly an hour a piece over the course of a day. Intersperse lunch & bathroom breaks for fluid I/O needs. Leave feeling exhausted, perhaps regretting how silly you were to forget the algorithm for merge sort on that 3rd interview.
—Write neat code. This sounds silly, but you will get dinged if your code is illegible and hard to understand.
— Next, get a good set of sample interview questions with solutions. Were going to use multiple sources for this. Our mainstay will beCracking the coding interviewwhich neatly divides problems between discrete domains (get a physical copy off amazon). Well also be looking at theBerkely cs riddles as backups.
— If youre scheduled for 6 interviews and you do 3, this usually means you got cut short. That is, your performance was so bad, someone felt it was a waste to have 3 more people interview you. This sometimes happens for the wrong reasons, so dont feel too bad. Keep calm, keep training.
—are pure BS in my opinion, and generally acknowledged to not be a very good indicator of job performance, but you will see them. The key to these is being very methodical, asking smart questions and hoping the problem doesnt have an impossible trick. I wouldnt spend too much time studying these, but you should look at a couple.