Cracking the Coding Interview#
I have never been great at technical interviews. Not the kind where you discuss how to build software, but the sort where you have to read a problem and translate that to code in 45 to 60 minutes.
I’m terrible at it, because I haven’t practiced doing those ever. Everytime I’ve had to look for a job, I got lucky that my interviewer thought I deserved a pass at that round. I don’t think counting on that is a good thing. In fact, I am a staunch believer of `Spoelsky's 12 Questions <>`_ to tech companies, especially the question that asks if programmers write code during the interview process. Is that hypocritical of me? I’m not saying that I hate the coding process. In fact, I don’t. I acknowledge my lack of competitive programming prowess as a deficit in my own skillset. I don’t want that to hang over my head forever.
I want to master it, enough so that I can get over that trepidition that looms over me whenever I do these interviews. To that end, I’m charting myself a plan, a roadmap for interviews.
I’m posting that below, so that I stay on track. Oddly enough, I’ve always been good on building plans and calendars. I’m not certain I’ve been great following them, though.