I want to write down my memories of this year because I might forget them otherwise. I debated whether to publish this because, for the world, 2017 has been an awful year, worse than any other in my short memory. Yet it was a year of huge personal growth and professional success for me, and I still want to celebrate that, in a way that acknowledges my own privilege. I’m not sure what else I should say on this note other than that I recognize that I am fortunate, and I am grateful for what I have.
Continue reading →
Today, I told someone that when it comes to interviews, I am a robot with a checklist. I thought it would be useful to write it down for others! Here’s what I do:
- Listen to the problem. Ask questions and give example inputs/outputs to make sure I understand the rules. Try to think of edge cases if possible – consider the empty input case, single (1) case, maximum case, and nonsensical input case.
- Think of a solution. If nothing comes to mind, I ask myself if any of these tools are relevant to this problem: hashing and hash maps, sorting, classic data structures, classic algorithms / techniques, and bit logic. Classic data structures include: arrays, hashes, sets, trees, linked lists, stacks, and queues. Classic algorithms include brute forcing, breadth- and depth-first search (remember to explain when you would use one over the other), memoization / dynamic programming, recursive backtracking, and exhaustive recursion. Bit logic rarely comes up, but it’s worth mentioning in case your interviewer is an asshole.
- Explain my plan. Once I have thought of a solution, I explain it to the interviewer verbally or with pseudocode. I usually clarify that my intent is to make sure we’re on the same page and that I’m making sure my solution works. After I explain it, I ask if the interviewer would like me to code it up or if there’s anything I should clarify or fix. This is a cheat code because sometimes an interviewer will say that I explained it in enough detail that we can move on without coding it! Or they might ask, how would you make this solution faster?, in which case I didn’t spend too much time coding something and can go straight to the optimizations.
- Code. Once I’m coding, I refer back to my pseudocode pretty often because I lose track of my thoughts easily. I like having a plan to read from so that my nerves don’t stop me. I try to write the pseudocode in a way that there’s enough detail that the code isn’t a challenge. As an interviewer, I appreciate seeing the candidate’s plan because it makes it easier for me to follow what they’re doing if they’re silent.
- Test and debug. If I’m on a laptop, I run the code with some test cases. If I’m on a whiteboard, I ask the interviewer if they mind if I step through my code with an example or two. I mark up the board with what I expect each variable’s value to be as I go through and make sure things work as I imagine.
- Runtime and optimizations. Once I’m satisfied with my solution, I talk about Big-O runtime and potential optimizations, assuming the interviewer cares. Optimizations usually include some algorithm bullshit with sorting or hashing or some gotcha, or maybe adding threading.
Each of these steps take a lot of practice to become good at. Not only do you have to be good at coding, you have to be good at communicating, collaborating with your interviewer, paying attention to details, and talking about improvements. With this list, you can practice each step and get comfortable with it. Eventually, you’ll be able to systematically answer interview questions without hesitation!