30 Days of Programming Interviews

I’m starting a new 30 days experiment! This time with my good friend from University of Maryland, Koffi Kpetigo. Each week we’re picking one chapter from this book on programming interview questions: Cracking the Coding Interview: 150 Programming Questions and Solutions

Each chapter is themed (Arrays & Strings, Object Oriented Design, etc) so each week will be a focus on one of our top four topics. If it goes great after 30 days, then we’ll keep going until every chapter is done. Each morning, I’m waking up at the same time as before (8:30am) and doing a one-hour interview as if someone were asking me questions from that chapter. Then I’ll attempt to document that effort here, for posterity. Then, once a week, we’ll call each other up and do phone screens on questions from the “Medium” and “Hard” chapters (which are miscellaneous unthemed chapters that seem to represent the kinds of questions I’ve actually been asked in interviews.) The weeks are going to be this ordering, with today being Day 1 of the first week:

Week 1 – Chap 7: OO Design
Week 2 – Chap 3: Stacks & Queues
Week 3 – Chap 4: Trees & Graphs
Week 4 – Chap 9: Sorting and Searching

I expect I’ll get two things out of it, with hopefully a few surprise leanings thrown in as we go:

  1. More confidence in a variety of interview questions. Right now I typically go in to an interview with the belief that I’ll be able to figure out most problems, and a solid (though not perfect) understanding of common data structures. But I’ve never studied interview questions themselves, so I always feel like there’s something I’m missing. I’m definitely not one of those people who remembers their sorting algorithms, and I don’t feel like I’m at the point where I can say something like “Ok, this question falls into <question grouping>, which usually depends on <data structure here>, and they’re really looking to see if I can <thought process here>.” Even though I’ve been on the other side of interviewing for years, I still don’t feel like I’ve “pulled back the curtain” 100%. This should change that, or at least start.
  2. A couple new interview questions to use myself. I’ve been using the same one or two interview questions for a couple years now, and I’d like to switch it up. I like my current favorite a lot: it starts with basic algorithms, expands requirements in the middle, and ends up in a larger systems design conversation. But two problems I have with it are: (1) if you’ve heard a similar question for the algorithm part before, you’ll get further, and it’s close enough to a more common interview question that that’s happened a few times. I can correct for this, but I’d like to not have to. (2) I’d like to ask a harder initial question in general, so I can make a more granular evaluation of the top candidates.

Here we go!