I’ve talked about interviews in previous posts. However some recent experiences helping others with interview prep has given me some more insight. Here’s a couple tips on how to prep and handle an interview.
Practice The Real Deal
A lot of people recommend practicing Leetcode for technical interviewing. I’ve already talked about how I’m not a huge fan. My main argument is that Leetcode doesn’t practice the most important part: communicating your problem with your interviewer. For that, you need to practice with someone.
I recently read Do The Real Thing, a wonderful blog post. It argues that people spend a lot of time not doing the actual activity, instead opting to do fake alternatives.
With interviewing, this is definitely true. You should be practicing interviews in as close to a real environment as possible. Leetcode can be useful, but it’s not the same as an interview. You should have a friend play the role of an interviewer. They should not joke around with you, at least not as much as normally. They should ask you both the technical and interpersonal questions that you get in a standard interview. Ideally this friend should have actual experience interviewing. That way they can accurately mimick a technical interview.
The interview should follow a standard format. The interviewer looks at your resume; they ask you about various entries in your resume; you respond. Ideally these entries should be in areas the interviewer doesn’t already know about. If there’s a project I’ve collaborated on, I won’t ask about it. This part should take at least 5-10 minutes.
Next up is the technical question. The best technical question is one that the interviewer has been asked themselves. They know it’s a valid question and they can assess solutions. Oh yeah, interviewers should always know the answer to the question themselves.
The question should be done on either a CoderPad, a Google Doc, or a whiteboard. No IDEs allowed. I prefer Google Doc because it’s inconvenient and very common.
There should be a reasonable time limit to the interview, say 45 minutes. If you can’t solve the problem within that time limit, tough luck.
Mental Game
I used to fence competitively. I was never amazing, but I did learn how to handle competition stress. Well, somewhat.
Interviews are similar. They’re an event with a high risk/reward and lots of pressure to perform. Almost everybody I know gets nervous with interviews. You get nervous, I get nervous, we all get nervous. You need a proper mental game to work through the nervousness and succeed.
Everybody has a different mental game. Some people listen to music to hype them up. Others prefer silence or even nature noises. Maybe you should warm up with a practice question. Maybe you take a break from programming for the day before the interview.
Physical wellbeing also matters. You can’t perform if you’re sleepy or feeling bad. Try to get as much sleep as possible. If you drink coffee, make sure to have one before the interview (but not so much that you’re antsy). Consider stretching or getting exercise before the interview. I care a lot about diet too. I don’t like eating anything too meat or carb heavy before an interview. I also avoid anything gluten or dairy based. That’s just my quirks.
If you have trouble sleeping, go do something physically strenuous the day before. A good hike or bike ride will help you sleep like a baby.
Self talk is a great technique as well. Telling yourself that you can do it works remarkable wonders. Sometimes we forget that programming is a psychological task as much as a technical one. If you believe that you can solve the problem, you’re more likely to get a solution. Sometimes when I’m nervous, I acknowledge that I’m nervous and tell myself it’ll be alright. There’s always another company, another open position.
Meditation is a wonderful way to calm oneself down. If you find yourself nervous, focusing on your breathing can calm you down and center you.
When you’re at the interview, try to act confident, even if you aren’t. Smile a lot, speak up, and if you’re in a magical time or place where you can have physical contact, shake their hand firmly. You can fool yourself into being more relaxed than you actually are.
Do Your Homework
Before the interview, do your homework. Read about the company. Figure out their history, their culture, their potential future. You should have a good argument for why you want to join this company and why you’re a good fit. For instance if you’re applying to a company whose motto is “move fast and break things”, then maybe you should emphasize your ability to learn new tech and ship stuff quickly. If you’re applying to a company that is known for S C A L A B I L I T Y, maybe talk about your interest in performance and building scalable systems. Of course this should be based in at least a kernel of truth, so if you truly have no interest in scalability, then don’t talk about it. If you can’t back it up with your resume or with some discussion point, then don’t mention it.
If you know your interviewer ahead of time, research them. Are they young? Are they older? What’s their area of interest? This can determine how you talk to them. If I’m talking to someone who’s been experimenting with new technologies and likes Rust, well cool! I like Rust and can talk about that. If I’m talking with someone who’s been in the industry for 20 years, is an expert in C# and doesn’t appear to be that into newer tech, then maybe I won’t talk about Rust. Maybe I’ll talk about learning software design patterns and developing my OOP knowledge.
Clarify The Question
Alright, you’ve gotten past the personal talk and you’ve moved on to the technical question. The interviewer will drop into the CoderPad/whatever and give the question.
At this point, you should start thinking of as many clarifications as possible. What are valid inputs? What happens with this edgecase? How should you handle errors?
It’s definitely okay to propose an input and ask what the corresponding output should be.
I like to enumerate possible tricky points, just to see if the interviewer contradicts me. Maybe something like “Oh well I’ll have to handle the case where these integers are negative”. Often times the interviewer will chime in that I actually don’t, which is great since it makes my life easier.
Not only will this help you get the best possible chance at this problem, it demonstrates that you understand the question and are willing to gather requirements. A profoundly important step in programming is accurately assessing and clarifying the problem. You’d be amazed at the amount of programmers who start coding without this step.
Start Writing!
Then, once you’ve gathered enough info to produce the simplest, stupidest possible solution, start writing code! Don’t try to explain your solution to the interviewer. Just get to work.
Write in a language that you’re comfortable. This can depend on the problem. If the interviewer asks me to choose a language before they give the question, I usually politely respond that I’d prefer to choose after I see the problem. They always let me.
I’ve used some unconventional languages before, like Haskell or Rust. I’ve done it when the language has been on my mind, i.e. I’ve been using it recently, and when the problem is suited to the language. I won’t do a complicated data structures program in Rust cause lifetimes will bite me, but I might do a simple array problem in it.
Don’t try to do anything too crazy in the first solution. It should just get the problem done.
If you can’t figure out a solution, start talking about why you’re having trouble. Your interviewer is there to help you and they can’t help you if you’re silent.
Hints & Help
Your interviewer will probably drop some hints or help during the interview. Listen to these carefully. Often times they’re to prevent you from barking up the wrong tree, or to help fix a glaring issue. They’re not trying to trick you.
If you don’t understand the hint, you can ask them to clarify.
Debugging
Once you produce a solution, you’ll have to debug it. If you can write bug free code without a compiler in a Google Doc, then congrats, you deserve the job. For the rest of us mortals, there be bugs.
This can be tricky since you often can’t execute code. Pick simple tests and manually trace through them. Try to account for the edgecases like empty strings, null or empty arrays.
Take your time with this. It’s definitely okay to stare at the board for a bit here.
Complexity && Improvements
At this point your interviewer will ask for you to estimate the space and time complexity of your solution. They’ll ask for it in big-O notation (although tbh big theta is more what they want). This estimation doesn’t have to be rigorous. Often it’s just counting loops/how many times you visit an element.
Your interviewer will then ask you for some improvements, either in space or time complexity. This is where you’ll need to get creative.
If you need to speed up time complexity, consider adding a hash table. Often times if you’re doing a search inside a loop, that’s an O(n) operation inside another O(n) operation, aka an O(n^2) operation in total. If you can loop through and add to a hash table, your search becomes O(1) making your total complexity O(n).
Likewise if you need to reduce space, you can sort an array and use a binary search instead of dumping into a hash table. That’ll be O(n log n).
Can you cache with other data structures? I had a question where the solution involved bitmaps as sets.
Can you do the operation in place? If you’re rotating a matrix, you can rotate by creating a new matrix and copying entry by entry, or you can rotate rings.
Remember that you’re always optimizing for the worst case and the slowest algorithm. It doesn’t matter if your code runs faster for optimal inputs. It doesn’t matter if you turned your O(n log n) algorithm into O(n) if it’s immediately followed by an O(n^2) algorithm.
Of course, this part depends on your data structures and algorithms knowledge. If you haven’t taken a course on this yet, I’d recommend learning on your own.
Keep It Simple
It’s quite rare that you’ll need to use anything fancy. The fanciest data structure I’ve had to use was a heap or a bitmap. Most likely you won’t go beyond arrays, linked lists, graphs or binary trees.
Don’t even bother with something like a red/black tree. Your interviewer will most likely not know how to verify a red/black tree.
Any Questions?
Often times the interview will have a portion where you can ask questions. If you’ve done your homework, you should have some questions. That being said, it’s totally okay if you don’t. Especially if you’ve already done multiple interviews, it’s quite likely your questions have already been answered by a previous interviewer. Also sometimes my brain is just too fried to come up with questions.
After The Interview
If you have multiple interviews, like with an on-site, you’ll need to keep yourself in the right mindset in between interviews. Try to relax, let your mind recover from the interview. I tend to drink a lot of water and maybe a coffee. You can do some breathing techniques or repeat some mental mantras if that helps. Multiple interviews are hard. I’ve been totally fried after three in a row.
If you think that you did badly on one interview, try to not let it affect your attitude going into your next one. You can do it!
Once you’re done, go relax! Often I treat myself to a nice meal. Interviewing is tough and just getting through it is an accomplishment.
As for results, try to have zero expectations. I’ve gotten jobs when I thought I did badly and I’ve gotten rejected when I thought I did well. If you can keep your head up and keep applying, you’ll get better at interviewing and definitely get some offers.