Search This Blog

How to ace a tech coding interview (top 5 small things that help)

There is no shortcut. You have to know your stuff cold. However, keep it manageable. You have a finite amount of time to prepare so find out what are your weaknesses and double down on those until you know the material cold. I mean, to ace the interview, you really need to feel comfortable and be able to knock out problems with confidence. There are some important steps to take to improve your chances, but they all revolve around making yourself comfortable and knowing the material. Here are a few ideas for small steps that could make your next interviewing experience better:

Get comfortable with the environment

You can't control much about the environment of the interview. Who knows, maybe you run into a particularly pathological scenario where the AC just happened to break down and the interviewer is unwilling to open the window despite sweltering summer heat. There is little you can do about that except dress with contingency plans. More practically, you need to get comfortable with writing on a whiteboard and keeping around your own notebook/notepad. You can't control the interviewing environment much, but there is a tiny piece of the whole that you can tilt in your favor: get your own fine-tipped whiteboard dry-erase markers like the ones I use in the practice sessions. They work way better than the typical dry erase markers found in whiteboards everywhere. One person characterized transitioning to fine-tipped markers for interviews as transitioning from a standard def to a hidef display. Another plus is that you can make sure you have your disposal the right combination of colors and working markers. This will help you avoid another pathological occurrence, where the interviewer is color blind and all the markers in the room just don't work for him or her. That's right, bring your own whiteboard markers to the interview. It's one small change in your favor. How cool is that, walking into an interview with your own fine-tipped markers! Anything to reduce the time wasted searching for a working whiteboard marker is a good thing for you.

To get comfortable with coding on a whiteboard, you need to practice doing exactly that. Find a whiteboard somewhere and write up some code. To start with, it doesn't even need to be a solution to some hard problem, just any code you feel comfortable with. Write a good amount of code up on the board and practice explaining yourself and managing the board so you don't run out of space. Also, practice testing, running through an execution of a program on the whiteboard. Try a few approaches to see what works best for you. I usually try to create a table with a column for the loop counter plus columns for each variable of interest that may be updated for each iteration or recursive call.

Bring a paper notepad/notebook and extra copies of your resume

During your interview, there will likely be a slew of 3 to 5 or more people who scurry into the room, hastily introduce themselves, and send you through the gauntlet. Unless you are terrific with names and memory, I suggest you take a notebook with you to take notes: who interviewed you and what role do they have. Also, bring copies of your resume. Sometimes the team might have forgotten to print copies of them out. Sometimes, the interview never got to review your resume at all. In any case, it is good to be prepared so the interviewer will always have something to skim over.

Be prepared with a spiel

For some those behavioral interview questions, you just have to come prepared with an answer. Don't waste time trying to come up with some fancy answer on the spot. No, you don't have time for that. Any time you sink into brainstorming for behavioral questions, you can't recover for tackling the coding questions.

Bring a change of clothes

This has happened to me. The company flies me out cross country and put me in a hotel overnight. By morning, I wake up nice and cheery and head off to the interview on foot in my nice interview clothes. A block away from the office, the local fauna takes a toll and I end up with a soiled coat minutes from my interview. It's good to pack some spare clothes. It doesn't have to be elaborate, just enough to salvage in case for any reason your clothes are ruined just before the interview.

Thank your interviewer

Always thank your interviewer. It is the right and professional thing to do.

Comments

Post a Comment

Popular posts from this blog

Shrunk and White of Programming
When you put down that you know a certain programming language or languages on your resume, you are setting certain expectations for the interviewer. I would strongly caution against putting down "expert" in a language unless you invented or are one of the language's maintainers. You are giving your interviewer the license to quiz you on programming language lore. There are a handful of concepts that are considered "standard" knowledge for each language which go broadly beyond syntax and general semantics. These concepts commonly involve major pitfalls in a given language and the idiomatic technique for negotiating these pitfalls and writing efficient and maintainable code. Note, although the concepts are considered idiomatic, you can seldom infer them from knowledge of syntax and semantics alone. The tricky part here is that most courses that teach a particular programming language do not cover these idiomatic techniques and eve…

This is part 1 of a two part series. Skip over to part 2 you'd like .
For coding interviews, we are interested in gauging the asymptotic efficiency of algorithms both in terms of running time and space. The formal study of analysis of algorithms is called complexity theory, a rich field with fascinating and complicated math. For interviews, we only need a few basic concepts. Asymptotic efficiency is concerned with how the running time or memory requirements of an algorithm grows with the input size, so it is intimately concerned with how well algorithms scale to larger inputs. This is important in Computer Science and in practice because whereas some algorithms work well enough for small inputs of say < 10 inputs, the running time and space grows far faster than the input size and thus large inputs of say 10s to millions of inputs becomes impractical (usually meaning taking hours or even years of execution time). Consider sorting. Say for the sake of argument that sorting alg…

It's a challenge to outperform all the other candidates in a competitive tech job only, but there is hope. You can improve your performance with practice and watching out for these gotchas:
Make absolutely sure you are solving the right problem: I ran into this the other day. It is entirely a communication issue. When doing an initial screen over the phone, this problem is compounded. For example, maybe an interviewee is hacking out a function that returns the k highest priced products when the interviewer is expecting the kth highest priced product. One can squander a lot of time due to these misunderstandings. A good interviewer will try to guide you back to the right path, but you can't expect this. Be sure to ask questions. Confirm that the input and output are exactly what you expect. Use examples.Don't ever give an interviewer the impression that you are avoiding writing real code. This is an impression thing. This is a coding interview so you should be expecting to…