More stories from the early days. Evaluating someone’s programming ability is hard, especially someone fresh out of college. A student’s grades is in no way indicative of how well he can program after all. So most nontrivial programming jobs have some sort of complicated application process involved.
I remember going in and taking an exam. Most application processes will have some sort of written exam to filter out people who look good on paper, but can’t actually do anything. People graduate college all the time without being able to do anything so it’s a fairly good idea
I was expecting the written exam to be programming questions, but to my surprise it wasn’t. The questions were puzzle/problem solving type questions. I think there were 10 questions in all. I don’t remember all of them, but for sure one of them was the pirates puzzle described here: http://www.mathsisfun.com/puzzles/5-pirates-solution.html. I never did find out how many I got correct, although I felt pretty good about my answers for all of them
After passing the written exam, I also had to take a second technical exam. It consisted of a few parts, the first part was they gave me some sort of string-manipulation problem and I had to write a program on a whiteboard and explain and defend it. Nowadays if you asked someone to write a program on paper or on a whiteboard during an interview, it would kind of look ridiculous since it doesn’t reflect a realistic scenario of how programmers work these days (i.e. with the internet and IDEs and autocompletes and whatnot), but that was how things were done back in the day
I hadn’t done much programming outside of using C, so that’s the language I used to provide my solution, but in theory I could have just used some sort of pseudocode since they don’t require you to use specific languages. As a programmer applying for a job, I would recommend prioritizing opportunities that don’t require you to know a specific language or set of languages. You’ll learn and grow a lot more as a programmer
After leaving me in the room for thirty minutes, the interviewer came back and I had to explain the program I had written on the whiteboard. It was a typical string-manipulation problem designed to see how well coders think through the process. I don’t remember the details too much, but I remember getting into a debate with the interviewer about the expected behavior for the C function strcpy(). I didn’t want to appear too argumentative, so even though I believed I was right (and I confirmed it afterwards!) I just let it be after insisting a couple of times
After the programming question, I got asked an “impossible question”. This is another type of interview question that has mostly fallen out of favor these days. The idea of an impossible question is basically the interviewee tries to approximate an answer to a question that would generally take a lot of research to answer. The interviewee has to explain his reasoning of how he would estimate the answer, and from there the interviewer can make a judgment of how well thought out the interviewee’s processes are. I didn’t know about this style of question ahead of time of course, this interview was the first time I’ve encountered it. I actually still remember the impossible question asked of me: I was asked how many people ride the Metrorail (MRT3) in Metro Manila on a daily basis. This was in 2002, so the MRT3 had only been out for around 3 years and wasn’t quite as congested as it was now, so I could make some reasonable assumptions like each train arrives at each station every 5 minutes, each car usually houses 300 people on average, etc, and I think I gave a pretty reasonable answer
This style of recruitment process was popular at the time, more than ten years ago. Companies like Microsoft were well-known for it. In fact many potential programming job applicants would be advised on internet forums to google “Microsoft interview questions”, and many of them became so well-known MS was forced to revamp its processes as well
With the problem solving, the code walk-through and the impossible question, the focus was finding not necessarily people who were very good at coding per se, but rather people who exhibited a strong analytical approach to problem solving
These days the recruitment process is very, very different. In most, if not all companies, the written exam will focus on technical, coding questions. You’ll be given sample code and need to try to identify the problems with the code. A friend even had to answer questions over the phone about details of Java syntax (pretty useless questions if you ask me)
And instead of a technical interview where you have to write code manually, most likely you’ll be given a workstation with an IDE and computer access and asked to implement so-and-so program. Some of the more progressive ones will do a pairing exam where you have to do pair programming with one of their existing developers; such pairing exams give insight on two fronts: your technical skill and how well you can work well with someone already on the team you’re applying for
I kind of prefer the old style of recruitment processes because they give a better chance for people like me who had minimal formal programming education but can learn easily and quickly
See Also