Interviewing for a tech job

When I interviewed for my current job, I didn’t pass the interviews on the first time that I tried.  When I applied again 1 year later, I passed, but I had changed my strategy in preparing for the 2nd time to correct all the mistakes I made during the 1st time.

There were other factors of my growth as a programmer beyond the whiteboard problem practice that helped equally as much, if not more so, in my success in the 2nd round of interviews.  But the whiteboard programming aspect is more immediate and usually more stressful.

To help others who may need the help in the way I did, the following is a summary of how I prepared the second time:

• Following this blog post
  • Bought the thin whiteboard markers (was more impt than I realized)
  • Re-read the basic chapters in CLRS
  • Bought and skimmed through the basic chapters of the algorithm design textbook
  • Disclaimer: I definitely don’t agree with all that Steve Yegge says, and I didn’t find the A* algorithm applicable for me, but everything else in that particular blog post seemed pretty useful
• Bought the Elements of Programming Interviews and studied from it mostly
  • Also bought Cracking the Code Interview and studied from it, but only to round out topics that EPI didn’t cover, ex: DBs.  Everyone seems to use CCI, but I liked EPI because it was harder and had more problems
  • Tried to do >= 1 problem a day
  • Practiced for a month before submitting any applications / sending resumes, kept studying while waiting for responses from recruiters
• Simulated as much pressure on myself as I could at home
  • Bought a whiteboard, put it up on the wall in my apt, did most of my problems there
    • As a backup option, also had a paper notebook to do problems when I could find a seat to sit down on BART while commuting
  • Timed myself to simulate the urgency & passing of time – wrote down the start & stop times, and turned on the stopwatch on my phone
  • Took a picture of every whiteboard problem I did – the point was to simulate feeling scrutinized (just like when the interviewer takes a picture of the board at the end during an interview)
• Developed a process for systematically approaching problems
  • Evolved organically as I went along through practice problems, started it out of frustration that each practice problem felt as nerve-racking as the next
  • Before writing out any code, I list out these categories in order and fill in whatever is appropriate to the problem:
    • GIVEN – problem statement
    • RETURN – problem statement
    • INPUT – code inputs & variable names
    • OUTPUT – code outputs & return types
    • GENERAL IDEAS – anything & everything you think is relevant; start with data structures; definitely include pictures, examples of corner cases & test cases.  make a “TODO” comment if you get stuck on a low-level detail
    • ASSUME – assumptions that you can / need to make with the confirmation of the interviewer
    • (recursion) BASE CASE(S) – sometimes recursion has 2 base cases, usually just 1
    • (recursion) RECURSIVE STEP – work to be recursive.  sometimes need to carry state in recursive step, in which case, need one recursive function and one function to kick it off with initial values
    • CLASSES – any classes / data structures to create.  Often, for the purposes of interviews, classes are glorified “structs”.  (Only if you need to create a Comparator do you try to mention implementing hashCode() and equals().)
    • VARS/FNS – any variable names / function names that need to be created, or that I want to create