So I figured I should write about some of the experiences I’ve had with software engineering/programming interviews in the past. I’ve been lucky enough to sample a number of different ‘flavours’ of interviews. Through my travels I quickly learned that interviewing in itself is just as much a skill as knowing C++ or riding a horse. I do scratch my head at some of the practices found in interviewing, I know it may seem fickle of me to question interview practices, but I’ll ramble on about some of them later nonetheless. Keep in mind there’s probably more to interviewing than what I’ve written, I’m simply drawing on past experiences. Also unlike senior or regular engineering positions, there’s not much text on junior-level interview topics, so I suppose this will add (hopefully in a good way) to that area. Let’s jump right in, shall we?
The Interview
Software companies like assurances when they hire new developers, they want to make sure you know (and I mean know) the innards of your code. And as I began preparing for my first ever interview long ago, this hit me pretty hard. Thing is, this interview was no small matter. It was a SDET position at Microsoft, and I was getting flown out from the UK to their HQ in Redmond, Seattle, so it was a pretty big deal. Microsoft are known to be notoriously difficult during their interview process, for the weeks leading up to the interview, scared is a very big understatement as to how I was feeling in my overly fancy Bellevue hotel room a handful of days prior.
In the meantime, I was preparing. Flicking through endless websites telling me to memorize this and understand that. It was all very daunting. And for about 2 and half weeks I burned through coding books and ploughed through old notes, refreshed syntax and theory were crammed and ready to be quizzed.
When it was time for my interview, however, I had no idea it’d be done by 5 different people individually. I was pretty freaked out by this, but I managed to keep my cool (on the surface). I later found out this is pretty much standard in software engineering interviews, helps give a clearer judgement of the candidates. So each person (who I should note were very experienced and held seemingly high positions, and were also very clever) asked me the regular interview questions, past experiences in programming, weakest areas, the usual. Then came what I had prepared for most.
The Technicalities
Ah, the technical questions. The most important part of the entire interview. It’s generally what makes or breaks the hire/no hire decision. I’ve seen it broken down into two sections thus far:
- Coding theory – Given some problem domain or requirement, write up some code that solves/fulfils the problem/requirement(s).
- Problem solving – Given a hypothetical situation (with some problem), explain what would you would do step-by-step (no matter how ridiculous or wacky the situation may be).
This can be done in a one on one or an exam (online or during the interview). The reasons behind asking such questions is obvious, demonstrating the candidates knowledge, coding ability, thought process, ect, ect. The questions seem to always canter around the same wave-length too. Common coding questions ask about iterative and recursive versions to writing an algorithm (nth factorial, Fibonacci sequence, ect.), linked list manipulation (super common), 3D vector maths (more for games-related positions), matrix manipulation (again, games) memory management/data structures (also common), the list goes on.
It’s pretty much common practice to ask such questions during interviews. They originate from the golden days of programming when it was pretty dependant on knowing things like pointer manipulation, and when compilers were far less optimized. And it’s also because Microsoft were super picky and wanted geniuses, so everyone else followed suit.
To give you an idea of the questions asked, how about a super quick coding problem?
Write an algorithm to compute the nth factorial using n as an input.
Answer :
You wouldn’t implement this function if you wanted n to be a large value (this is a good thing to mention during an interview FYI), but the main point is demonstrating your ability to convey these concepts in code.
However the practicality of these questions are arguable. Many of them would prove to be daily practice back when coders needed (or were a lot more dependant on) this knowledge, today however this isn’t the case. Nowadays coding is much more high-level; API’s are far more commonplace, and optimized libraries tend to our needs. Heck, Ruby on Rails gets you an online blog set up in three clicks. This often means two things for fresh graduates: a hazy understanding of low-level concepts, and the slow fading memories of your lecture in programming theory. As a result we get comfortable, too comfortable, and the knowledge of the building blocks for our code slowly becomes more and more unfamiliar. I’ve asked many recent graduates these same interview questions and most of the time I receive puzzled faces.
That’s not to say you shouldn’t know how to reverse characters in a string, or be able to write a function that can find a point within a rectangle/circle. A programmer should know understand these concepts inside out. It makes sense that an employer would want to hire someone who is nothing less than a master in their craft. After all, the more you know about code, the better the programmer you become, and frankly, this is pretty basic coding theory, just that its only natural to develop some rust in areas you don’t exercise regularly. Solution? Make sure you do.
Back to my interview. I did well answering the technical questions, managing 4 out of 5 with relative ease, however that’s not to say they weren’t difficult. A path finding question had me stumped during my 5th interview, I managed to work through it with some help from the interviewer but it had me bummed for the rest of the day.
In the back of my mind I kind of knew I wouldn’t do well in the first ever job I interviewed for, not because I didn’t understand enough code or wasn’t confident in my programming ability, but because for my first ever interview for a proper software engineering position there was no way I wouldn’t screw up in some way, and unsurprisingly, I didn’t get the job.
I was later told that my approach to problem solving was my main downfall, while I was able to eventually reach a solution, they felt I needed to improve upon my approach to actually getting there. Admittedly, I was annoyed at this feedback, as it was as vague as one could ask. Although, lets be frank, its not exactly Microsoft’s job to tell me where I should improve as a programmer.
Many years after, I’ve had couple of other interviews with some known companies and universities, and throughout each of them I use my gruelling Microsoft experience as self-driven motivation; “no way is this more difficult than that Microsoft interview.” I’ve found the coding questions to be within generally the same areas (though I can only imagine them getting more difficult as the positions climb up the senior ladder) and I guess if it wasn’t for my interview at Microsoft I probably wouldn’t be as knowledgeable as I am now, so I have to thank Microsoft in that regard. I honestly became a better programmer because of it, and I’d by lying if I said I didn’t touch on some new knowledge reading a few interview books (which have come in handy once in a while).
So to summarise my (hardly ground-breaking) findings, interviewing is a skill. The ability to sell yourself and know how to answer those tricky interview questions comes from experience. You get better as you go along, I certainly wasn’t able to answer some of those coding problems first-time, however I used that as an excuse to fill in the holes I had in my knowledge-base, and eventually found myself able to tackle coding problems far more efficiently.
I dug up some really good books I’d recommend reading that cover the questions I talked about and more. They certainly helped me when I was preparing and serve as a good place to start. I’ll list them at the bottom of this post.
That about sums up the first (real) post on this site, which is strange considering I’ve had it for over 2 years now serving as my trusty portfolio. Who knows, might be able to write more posts like this if I ever find the time (and more importantly the will).
The Books
I’d suggest looking at:
Programming Interviews Exposed
How Would You Move Mount Fuji?
And in case you hadn’t already, you need to read:
