From Seattle to Lahore, from Google office in Fremont to Microsoft campus in Shanghai, the candidates that end up getting offers look very similar. This post is about how to be that kind of a candidate.
Getting a job at a good software development company is like being a genius - it is 1% inspiration, and 99% perspiration. This means a lot of work, vast majority of which must happen before the event. The good news is that this work is portable - once done, it opens a lot of doors, and puts you in a position where you choose where you want to work, not the other way around.
So without much ado, let's delve into the gory details.
Prework - long term
All interviewers look for basically the same thing - candidates that are "smart and get things done". There is no good way to determine one's intelligence, so we use an approximation. We ask the interviewees to solve complex algorithmic problems on the whiteboard. Luckily, unlike intelligence, this ability can be trained.
Unfortunately, most software development jobs, with very rare exceptions, do not provide on-the-job training for algorithmic skills. A colleague of mine says that there are two types of developers - people who can call APIs, and people who can build APIs. Vast majority of the jobs in this industry are about calling APIs. The most highly paid jobs, however, are about building them. Most teams at Microsoft, Google, and the like are looking for people of the second kind.
If you are not already working in the team that builds APIs, you need to learn to love computer science as science. Get interested in algorithms design. Learn about computer architecture. Start paying attention to how the functions you're calling are implemented.
Do you know what's actually inside the HashMap class you've been using all the time? What algorithm does STL use for sorting? Why? When is heap sort faster than the merge sort? What does a modern computer really do when reading a byte out of memory?
If you live near a good university, take a class every few years to keep connection with the scientific side of the software development.
In an earlier article (http://1-800-magic.blogspot.com/2007/12/recipe-for-getting-employed-by-google.html) I claimed that reading and doing the exercises in three books will get you a job in any good company. I still believe this to be the case - but you do need to actually read these books, and do the exercises. Just buying and putting them on the shelf will not work!
The "getting things done" part during the interview is usually proxied by having the candidate to write a lot of code on the white board. The better the code looks - syntactically correct, concise, professional - the more likely that the candidate has written a lot of code in his or her career, and therefore, got more things done.
One can see the difference when doing something as simple as copying a string:
while(*d++ = *s++) // Good!
// Generates the same binary code,(This is where STL with its "string s1 = s2;" really gets you :-).)
// but too much text!
for(i = 0; s[i] != '\0'; ++i)
d[i] = s[i];
d[i] = s[i];
The only way to good code is to practice writing - a lot! Jump into the parts of your project that generates as much code as possible. If you're a developer, and you're not writing at least 20Kloc/year, your coding muscle does not get enough exercise. Get a coding project at home - write a piece of automation software for your light switches!
Prework - short term
The above suggestions are designed to get and keep you in shape as a software developer. They maintain the set of skills (AKA coding) that makes you employable. However, even great software engineers often do not get the job they want because there are other things that are required for a match.
I've been asking every person who I interviewed for various management positions at Microsoft what they are looking for when interviewing people. Every time the passion for technology was coming out very close to the top. What this means is that ideal candidate (1) wants to work in this general area, and (2) wants this job.
As an interviewee, you must have have plausible answers for both.
The best (and the only) proof that you want to work in this general area is to demonstrate that you invested time to research deeply the technologies/customers/competitive landscape/standards/other subcurrents that shape this part of the industry. Buzzwords are not enough - deep knowledge to an extent where one knows enough to form an educated opinion is required. I've seen many a qualified candidate being rejected because they gave standard, cookie-cutter answers to questions which an interviewer had considered too shallow.
SOAP is a great technology? Why? Because it uses XML? And why is that a plus?
The best (and the only) proof that you want this job is that you've spent time to learn about it. A lot of information is available publically. For example, if you're interviwing for a position of a program manager at Microsoft, it helps to know what this job really is.
Whenever I go on college recruiting trips for Microsoft, the most amusing thing is interviewing candidates for program management positions. A program manager's job does not actually involve management, nor it is any more senior compared to test and dev disciplines. Both of these aspects are described in detail at both the Microsoft recruiting web sites, as well as on the application for the college interviews. Yet 90% of the college candidates that I interviewed on campus assumed that (1) they will be managing people, and (2) right out of school they were entitled to do this.
If it's an internal transfer within the same company, more often than not most of the information about the project is available. I once had a case where a candidate knew more about the history of the project, the market, and the competition - without ever having worked on it - than I did. Needless to say, she got the job :-).
More often than not, recruiters and interviewers will go out of the way telling you directly what will be on the interview. An email that I've got from Google when I interviewed there listed all the areas where the interviews focused. Microsoft recruiters give out no less details. I am telling every candidate, before meeting them, about the areas where the interview will go. You have no idea how many people completely ignore the advice!
If, for example, it's written on the web site, in the recruiter email, and in the interview packet that THE INTERVIEW WILL INVOLVE WRITING CODE ON THE WHITE BOARD, and when you show up at the company and are asked to write code on the white board you say that your coding is "rusty", what outcome do you expect? It's a double-whammy: not only do you not match an explicit qualification for the position, you have wasted company's time and money by coming to the interview, because you apparently have not even bothered to read the description of the job!
Do prepare good, deep questions about things that you should want to know, but cannot. Avoid cliches - believe me, "Describe your typical day as a developer at X" does you no good. This question has been asked many times. Too many. The only reaction the interviewer has to a question like this - "Oh, here we go again..."
The day of the interview
Don't be late. It's unprofessional. Plus it cuts into the time that is available for you to solve the problem :-).
Don't use pseudocode, unless the problem requires it (many graph algorithms do). If you're a great coder, you should be writing in a real computer language with ease. Plus we warned you that (1) we're looking for great coders, and (2) you will be coding on a white board.
Avoid syntax errors when coding. Well-written, well-formatted code is classy and shows experience.
Do be VERY detail-oriented. Check and recheck what you're writing. Do not shrug off the "off-by-one" errors. If you're "always messing up some mundane detail" ((c) Office Space), you should not be in this trade. Messing up mundane details in the past had caused spaceships to miss their destination, to say nothing about expensive product recalls.
Do listen to what the interviewer says. This cannot be overemphasized! They are here to give you cues, to help you. Most of the time they genuinely want you to succeed. They know their problems. If an interviewer makes a suggestion, TAKE IT. (S)he knows!
Do test your code. After the code has been written, think about small, but exhaustive set of test inputs that would exercise all the code paths in your function, and elicit all the differences in behavior. For example if you're writing a binary search, test it on inputs with odd and even number of elements. An algorithm that takes an array should work well on inputs of size 0, 1, 2 and 3. Test the inputs that might cause overflows and out of bounds conditions.
Do step through the code as written, not as you think it should work. This is the most frequent error that I have been observing - a person would look at the data input and then reason through it with the algorithm (s)he had in mind - but not the one on the white board. Pretend you're a CPU instead. Write a sample on the board, create a column for every variable, and start iterating - mechanically.
Be humble. If you're saying "I am really good at X", this is a challenge to the interviewer. They will give you harder problems, give you less help, and treat the failure harsher because you behaved as an arrogant braggart. It's much better to underpromise and overdeliver than the other way around.
And last but not least, be enthusiastic. Ask questions. Offer suggestions. Demonstrate that YOU WANT THIS JOB.
Speaking of wanting the job.
It helps to set up multiple interviews when you're thinking about changing the job, and sequence them such that the more desireable jobs go last. Interviewing is a frame of mind, and it helps to put onself into the right state. But on the day you go to the interview - even if you aren't 100% sure this is the job you'll take in the end - on this day you have only one goal - to get this job. WANT IT!
By the way - we are hiring!