Pages

Software Programming Interviews Part 1 - Technical Questions

I am in a unique relationship with interviewing currently. To illustrate my point, here is a breakdown of the most recent 5 months in my career:

month 1: Update resume and relevant career sites; search for jobs and apply
months 2 and 3: Interview with fervor
month 4: Negotiate multiple offers, accept one and resign from then current employment
month 5: Join my new team and interview candidates for rest of the reqs at the rate of 3 interviews a week

It is the 5th month of this journey that stands me apart. In almost a continuum, I moved from one side of the interview desk to the other and the perspectives this has endowed me with are priceless.

I am attempting to capture my thoughts and observations in a multi-part blog post starting with this one. I don't plan on posting interview problems to solve and which companies ask what sorts of questions. There are plenty other great places where that information is available.

These are my personal views and do not reflect my employer's. Point to note also is that some aspects are topical or even locational and much is subject to change with various factors that affect hiring and the economy.

I'll start with my pet peeve about technical interviews:
Why *are* the questions book-ish and academic? Why aren't they more relevant to what is applied? 

For example: Honest to goodness, I haven't had the need to use AVL trees in my entire career of 15 years of C programming. In the meanwhile, I have extensively used the Patricia Trie, the radix tree, the hash map and doubly linked list. Why then should I go back to the books to refresh on re-balancing of trees and convoluted algorithms for singly linked lists?

The most obvious reasoning is that the favored set of problems stems from foundational CS. So when you are able to convince the hiring team that you have nailed the foundations, there is greater confidence.

Then there are practicalities - the problems must be solvable in a short period of time and general enough to intersect a wide array of domains and expertise. They must be simple enough to help the review process, but complex enough to judge creativity. Makes sense?

I wasn't convinced entirely with these answers. While I plowed along with my interviews in months 2 and 3, a signal started to emerge from the noise. What I discovered may surprise you. Technical interviews - especially the face to face ones - have very little to do with 'coding kung-fu' and a lot to do with personality testing. Just as a body language expert looks for clues in behavior - those 'honest moments'  - that reveal uncertainty, truth or lie, the hiring team uses the opportunity to pick up on whether each is able to see a working partnership in the candidate.

The first take away therefore is, an interview is anything but an exam. The hiring process is more analogous to match-making; complex, non-linear and very very personal. All that (often annoying) groundwork with practice problems and textbook refreshers is necessary to start playing but whether you get an offer or not relies a lot more than you think on the person that you are.

And here's another thing: the responsibility of finding that perfect match lies equally on either side of the hiring.

This has huge implications and dictates how you prepare yourself, present yourself and process a hit or a miss. Introspect, get in the shoes of the hiring side, and pay close attention to the 'soft' or 'behavior' aspects. Preparing for behavior questions is a slam dunk one would think but often ignored by the techies. That's low hanging fruit. What will really set you apart is your preparation to present a certain conscious behavior pattern while solving technical problems. Did I mention: introspect!!!