How to answer a programming interview question

I spent a few hours on Friday doing mock interviews for CS undergrads.  The idea was to help them experience the interview process without the pressure of having a job on the line.  The session was interactive with lots of stopping for advice.  I found myself explaining the following to most of the candidates.  I hope you find some value in it.

1. Explain the algorithm that you will use to solve the problem.  Use visuals where you can.  This will accomplish two things.  First, it will make sure you understand what you are going to do before you start coding.  This in turn will reduce the number of corrections and backtracks you have to make while coding.  Second, it will give the interviewer a chance to help you correct course early.  This means getting onto the right track before you spend a lot of time coding a solution to the wrong problem.
2. Write the code.  Use a real programming language.  Tell the interviewer what language you are using and then write in it.  Don’t sweat the syntax.  Focus on the flow of the code.  Using a real language is important because it is too easy to gloss over the important things with pseudo-code.  Try to write the code in one pass.  You already have the algorithm figured out so you shouldn’t need to backtrack and change your code.
3. Walk through the code with real data.  Before you declare yourself “done”, take the time to walk through the code.  Take a real example and explain how each line of code operates on it.  This will a) give you a chance to find bugs and b)demonstrate to the interviewer that the code works.  Pay careful attention here.  I’ve seen a number of candidates with big bugs in their code explain how they want the code to work instead of how it really works.  If you don’t pay attention, you won’t find the bugs.
4. If you are interviewing for a test developer position, test your code.  You’ll be asked to do so anyway, you might as well get credit for taking the initiative.  Even if you aren’t interviewing as an SDET, it is a good idea to show that you are thinking through the failure cases.

Jack Tramiel, founder of Commodore, dies at age 83

Jack Tramiel was the founder of Commodore International which produced the Commodore 64 and the Amiga computers.  It was also the company that made the once ubiquitous 6502 processor which powered the Apple // and the Commodore 64.  The Commodore 64 was the best selling computer of all time and the Amiga (which came after his tenure, but from his company) was almost a decade ahead of its time.  I learned to program with Basic on the Commodore 128 and spent a lot of my formative years using the Amiga. 

Jack Tramiel was a ruthless business person who drove a very hard bargain.  His relentless push for prices drove the first major round of the home computer revolution.  He died on Monday at age 83.  He had a great legacy and will be missed.  A great book on Commodore and Jack Tramiel's role in it is Commodore: A Company on the Edge.

Behind the Scenes of Windows 8

Larry Osterman returns with another installment of his Behind the Scenes... series.  This time with Windows 8.  Larry is a developer for the team I work on.  If you haven't caught it yet, take the time to read how the team developing Windows Runtime experienced this release.

Successfully Interviewing for a Developer Job

Having recently completed another round of campus campus interviews, several things stand out as advice that could be useful to those of you aspiring to get jobs in the software industry as a Developer or Test Developer.

• Always describe what you are doing and thinking – If you are given a programming question and you interact only with the paper or the white board for the next 10 minutes, you did poorly even if you got the answer right.  You failed if you didn’t get the answer right.  The interviewer wants to know not only that you can get the answer but also how you think.  If you have the right thought processes, you might pass the interview even if you don’t get the answer.  Often times people get extra credit for explaining what their options are and why they are picking one or another.
• When asked about a project or job, describe what *you* did – Explaining that the team wrote a location-aware notification system for Android phones doesn’t win you any points if you only did the graphics.  If you wrote the notification database and not the location APIs, talk about the database.  The interviewer will likely probe the details of the project.  Emphasizing the exciting parts you didn’t have a part in only leads to your having so say “I don’t know.  I didn’t work on that.”
• Be able to speak to the details of every project on your resume – If you put it there, it is to demonstrate your knowledge of an area.  If you don’t actually have that knowledge any more, it doesn’t help you.  In fact, it makes you look less knowledgeable.  You don’t have to know every detail of the puzzle game you wrote in that AI class 3 years ago, but you should know enough to talk about the algorithm you used.  Spend the time reviewing and perhaps even practicing talking about each one before showing up.
• If you don’t know, don’t bluff – It is often okay to say “I don’t know…” as long you can also say “…and this is how I would find out.”  It is certainly better than bluffing.  The person interviewing you has probably done a lot of interviews and a lot of programming.  They will likely know that you don’t really know.  Getting caught bluffing almost certainly kills your chances of being hired.
• Think through your code before you start writing – Having to backtrack a lot and change your code is not a good thing.  It is better than being wrong, but it is less good than the next person who will answer the same question without having to backtrack.  Having to add a lot of extra variables or loops or having to change your algorithm substantially demonstrates that you didn’t really understand the problem to start with.  It also makes your code really hard to read because unlike in a text editor, everything doesn’t shift down when you insert a line.  Take the time to think through your algorithm before you start writing.  Even better, explain it to the interviewer.  That way they can correct you if you are on the wrong track.
• Time matters – Sometimes it is not enough to get the solution correct.  Taking a long time to get there, especially if you have to backtrack, shows you do not have sufficient mastery.  Some problems are easy and the interviewer expects you to get them right the first time and without a lot of delay.  Finding a value in a binary search tree or reversing a string fall into this category.
• Be friendly – Believe it or not, your interviewer is human.  He or she will be more inclined to give you the benefit of the doubt if they like you.  Being friendly, making eye contact, and being upbeat all help with this.  If you answer questions with short sentences that do not further the conversation, never make eye contact, and have a sullen attitude, you will fail a close interview.
• Ask clarifying questions – Don’t just jump in and start programming.  Think about what you are being asked to do.  Many times the question will be intentionally vague.  Ask questions about the constraints, the expected use, the interface, etc.  If the question was intentionally vague, not asking questions will be a negative.  Asking intelligent questions shows that you understand the question enough to notice the edges.  That will earn you points.

Have other advice?  Please leave it in the comments.

If you ever wondered why Vim uses hjkl for arrow keys...

I tend to use Vim as my editor of choice.  Even when using Visual Studio, I do so with the ViEmu plugin.  I have always wondered why the directional keys were hjkl instead of jkl;.  The latter are the home keys for the right hand.  The former are not and overload the right index finger.  Thanks to Hacker News, I now know the answer.  The terminal which Bill Joy wrote the original Vi on was an ADM-3A and that had arrows drawn on the hjkl keys (see the link for a picture). 

How to Write Your First Developer Resume

I am returning from a recruiting trip to interview students on campus.  Because of this trip, I had a chance to read a good number of resumes.  Some were well done, many, however, were not.  They contained irrelevant information or were missing important items.  It’s very hard writing your resume for your first job.  You don’t have a corpus of work history that tells a potential employer that you will make a good employee.  It’s not immediately obvious what to write down and what to leave out.  What follows is advice.  It is only one person’s opinion, but I have been interviewing for jobs at Microsoft for about 14 years so it is an experienced opinion.  As with all opinions, others will have differing ones.  I encourage others to respond in the comments if they have supplementary or even contrary opinions.

It is important to understand the purpose of a resume before writing one.  If you understand what your resume will be used for, it is easier to craft the resume.  If you are applying for a technical position at a software company, your resume will serve two purposes.  First, it will be used to decide whether to interview you.  Second, it will be used to provide conversational hooks during the interview itself.

The resume will be read by someone from Human Resources or perhaps by a technical manager.  They will read it to determine if you are worth talking with further.  Each will be looking for slightly different things.  A person from HR will not understand most of the words and acronyms on your resume, but they will match them with the job requirements.  A “skills” section is often a good way to convey this information.  In it you would list the languages you know, the frameworks you understand, and the tools you have used.  While the HR person will likely only scan this list, know that anything you list here is fair game for an interviewer to ask you about later.  Don’t bluff. 

What sort of skills should you list?  Certainly list any programming languages you are comfortable with.  I have seen people rate their level of experience and find this to be a useful practice.  This allows you to list Perl which you used in one class even though you wouldn’t call yourself an expert in it.  List major frameworks that you have used.  This includes UI toolkits like WinForms, GTK, or Direct3D.  It includes Web frameworks like JQuery or ASP.Net MVC.  One rule of thumb to use here: if there are books written on the subject and you have experience, list it. 

Another important thing to list are the tools you have used.  You can list operating systems you are familiar with.  You probably won’t get benefit from listing obsolete systems.  Saying that you know Windows 98 won’t gain you points.  Mentioning a quirky, but respected OS might make you stand out.  If you used the Amiga or BeOS, saying so can be noticed.  The person reading your resume might have been a fan too.  You don’t need to list that you know Windows XP and Vista and 7.  Just say Windows.  List any major, relevant, software packages you have used.  Relevance is useful here.  Listing Microsoft Office won’t help unless you programmed for it.  It will be assumed that if you can program, you can use an office suite.  Certainly list difficult to master software like Matlab or Photoshop.  List relevant server technologies like Apache or Node.JS.  You might list the IDEs you are comfortable with.  I saw some people list the source control systems they had used.  I’m not convinced this helps.  It will be assumed that you can come to master Git or Subversion. 

The technical manager screening your resume will likely look past this list of technologies more quickly than the HR person.  He or she will be looking for your experience.  What have you done?  “Not much” you might be thinking, “I haven’t had a job in the tech industry yet.”  That may be true, but if you think you are skilled enough to land a job as a developer or test developer, you must think you have relevant skills and those skills were gained through experience.  There are three ways to expose these to your screener: classes, interesting projects, and relevant jobs.  It is fortunate that these are also the same things your interviewer will likely key off of in their perusal of your resume.

It amazes me how few students list their classes on their resume.  It helps to know if you’ve taken data structures or databases so I know what kind of knowledge you are likely to have.  These may also help you be considered for jobs you otherwise would not.  If you have taken an AI class, you are more likely to be considered for a job with a search relevancy team.

No resume of a college student or recent graduate should be lacking a list of interesting projects.  Yet probably a quarter do not have one.  Especially if this is your first technology job or internship, the projects section is the only place you can talk about what relevant experience you have.  Many if not most CS classes have a final project.  Pick several and talk about them.  List not only the name of the project but describe a) your role on it, b) what it accomplished, and c) what technologies (languages/frameworks) it used.  Don’t stop at school projects.  Even more impressive is the work that you did on your own because that demonstrates true interest.  Did you contribute to an open source project?  List it.  Did you program a game or a phone app with your buddies over Christmas?  List it.  Do you help maintain a MUD or create objects for Second Life?  List them.  Don’t be shy here.  Just because you weren’t paid or graded on your work doesn’t mean it isn’t interesting to us.

Finally, list relevant jobs.  It is important to know why you are listing jobs here.  Unlike when you are applying to be a Target Team Member, you don’t need to prove that you will show up on time and work hard.  Those things are assumed at this stage.  The fact that you have a college degree is proof enough.  That means you don’t need to list every jobs you’ve ever had.  The most important jobs to list are ones that are somewhat relevant.  This can be direct relevance like if you have an internship at Cisco testing router firmware, but it can also be tangentially relevant work like doing tech support for your dad’s small business or even running the light and sound for a school theater.  Working at Best Buy shows that you have an interest in technology.  If you have nothing relevant, feel free to list at least a few jobs even if they were burger flipping.  This will show that you have some employment history and aren’t a total slacker.

When listing a job, it is important to know why you are listing it.  If it is because of relevance, explain what you did at the job.  List the projects you were on, what your role was, and what languages/technologies you used.  Give enough information that we will know what you learned.  If you are listing the job merely to demonstrate employment, just list that you had the job and for how long.  Telling me that you “created a safe pool environment” while working at the YMCA doesn’t help your cause.  The fact that you “Provided excellent customer service” at McDonalds doesn’t make me more likely to interview you over the next guy.  The same is true of extra-curricular activities.  While you may be proud of the multicultural banquet you organized last month, it won’t gain you a lot of points.  Don’t spend much space describing it. 

These things will all make you more likely to get through the screening process.  Once you have passed the initial screen, your resume serves a secondary purpose.  Keep this in mind when writing it.  The people interviewing you—either for an initial phone screen or an in person interview—want to know what you know so they can ask you about it.  Toward this end they will ask you technical questions.  They might have you reverse a string or find the 4th element from the end of a linked list.  Perhaps just as important, though, they will want to gauge your passion and understanding.  This will be done by asking about your experience.  They will want to know about the research project you did or the Windows Phone app you wrote last summer.  For this to happen, they need to know what you have done.  Luckily, this is the same information you already provided to the technical manager.  What did you do at your jobs?  What projects have you participated in recently?

Sometimes the interviewer will want to get to know you as a person.  Listing a few activities or interests can help here.  Most of the time this section will be ignored, but if you happen to enjoy something in common with your interviewer, it can provide an opportunity to build a relationship.  Feel free to list that you enjoy sea kayaking or playing chess or that you were part of a Romeo and Juliet production at the Shakespeare festival last summer.

<soapbox>Please consider whether your objective statement actually helps you.  Most of the time, it does not and you shouldn’t have one.  I know that the helpful person at your career center told you to put one on your resume.  They are wrong.  Most of the time an objective statement boils down to “I want a job.”  Yep.  That’s why I have your resume in my hands right now.  Unless your objective statement can somehow help differentiate you from your competition, leave it off.  Everyone whose resume I have in front of me wants a job.  They even all want a software job.  Telling me that doesn’t help.  It just wastes space and makes it less likely that I’ll read something which does make you stand out.  In my experience, the objective statement provides value only when used for the purpose of *limiting* the scope of what you will consider.  If you really only want a job programming microcontrollers, put that in your objective statement.  We’ll pass you by for the kernel programming job.  If, on the other hand, you—like most people in school—just want a job in the field of computers, leave it off. 

Here is an example of the kind of objective statement that is all too common:  “Objective:  Seeking to expand my experience and technical knowledge and gain experience in a corporate environment.”  Thanks.  That differentiates you from every other resume I’ve seen.</soapbox>