Motley says: “To prepare for an interview, just make sure you can code on a whiteboard (Part 2)”

Summary

[This entry is a follow-up to "To prepare for an interview, just make sure you can code on a whiteboard". A few of the important messages are repeated and clarifications are provided to make a complete package.]

 

	Motley: I thought I could rely on natural coding ability for my interview. I was wrong.
	Maven: YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

______________________________

[Context: Motley, er… Mary, has just had an interview with another company and did not receive a job offer. He is discussing strategies with Maven around what went wrong.]

 

Motley: <bumps into Maven in the hallway with no apology>

 

Maven: Hey! What's up, Mot? You don't seem to be your normal bright and cheery self.

 

Motley: Ah, nothing. I, err… I mean Mary, just got some bad news. She interviewed at another company and did not get an offer. She thought the interview went well, and she is obviously brilliant and has a lot to offer to the company. She is confused why an offer was not made.

 

Maven: Hmmm… "Mary". Let's cut to the chase. YOU interviewed somewhere else, didn't you?

 

Motley: Shhhh… keep your voice down. Fine. Guilty. Yes, it was me. I am not serious about taking another job, but a friend of mine wanted me to visit the company he works for, and I thought it would be good interview practice.  It was good practice, but it is a blow to the ego not to be successful since I know I am good. I guess I stink at being interviewed.

 

Maven: Well, if you have a few minutes, let's chat about the job search and interview process for a software developer.  Firstly, you did the right thing by leveraging your people network in finding a position. That approach improves your odds of success, and can lead you to open positions that are not widely advertised.

Motley: Yeah, in this particular case I knew another developer at the company. He put me in touch with their HR person, and they were willing to create a position if things worked out.

 

Maven: Excellent! That is a great way to find opportunities. Next, I recommend you do a fair amount of due diligence to find out if the company is a good match prior to committing to interview. Interview them as much as possible. No sense wasting time in an interview if you feel like it is not a good match. Additionally, do an informational interview with the hiring manager. This session is typically one hour in duration and gives you a chance to ask questions, and the manager a chance to find out more about you. You may determine after this hour that the position is not worthy of follow-up, which saves your time and theirs. After the informational, talk to a few other people in the company across various roles if they allow it. Will you effectively collaborate with these people? Do they share your values? If the answers are yes and they invite you for an interview, go for it.

 

Motley: Since I already knew someone in the company, I really did not do much more research, but it is a good point.

 

Maven: Did you prepare for the interview?

 

Motley: I read the couple of books you pointed me to previously, but that's about all. Some questions did take me by surprise, such as where I see myself 3 years from now.

 

Maven: It is extremely important to prepare for an interview. Although you do not know exactly what questions they will ask you, you can hypothesize at the types of questions you will receive. For example, it is common practice in a developer interview to ask about your previous experience, pose a design problem, ask open-ended questions about your views, present a couple of whiteboard coding questions, and learn more about your personality. You should be prepared to answer these types of questions.

 

Motley: I focused more on coding, and practicing some different types of problems.

 

Maven: That's great! You need to go further, however. Know your strengths and weaknesses. Know where you are going with your career. Know something about the problem domain of the company. Know about the company itself. Know the org structure. Play with the product if possible. Come up with ways to improve the product and/or team given limited knowledge. Know the characteristics of a good UI design, if you are applying for that kind of position.

 

Motley: That is a lot to do to prepare for an interview! I don't have that kind of time!

 

Maven: You have time when you make time. These things are important to successfully securing a position, so make it a priority. Plus, don't just waste the effort - make notes. I use OneNote to track all my potential interview answers and over time build up a collection that I continually review and refine.

 

Motley: Is that "all" for preparation? <sarcasm>

 

Maven: You can always do more. Ask the people around you for the types of questions they like to ask in an interview - that will give you an idea of the kinds of problems you may be asked. Another important piece of preparation is to ensure you have good questions prepared for the interviewers. You are interested in the position, so show it by finding out more. Interviewers love thoughtful questions. Write them down so you do not forget them in the heat of the moment. Ask about company and product direction, team culture, and current challenges.

 

Motley: Wow - interview preparation is going to be a big investment!

 

Maven: Do you want the job or don't you? No need to answer. One other thing I like to do load up my favorite Internet search engine and type in the names of the people interviewing me (if known). I do a bit of background checking on them, which does two things: (a) gives me a clue on the types of questions they may ask; and (b) gives me some topics for chit-chat at the beginning of the interview.

 

Motley: We talked previously about that, and no, I didn't do it. In this case I did know who the interviewers were ahead of time, so talking about background would have been a great conversation starter. I should have done that.

 

Maven: Now, the interview itself. How did you handle it?

 

Motley: In a nutshell, I walked in, sat down, waited for them to start asking questions, jumped up to the whiteboard to solve the programming problems, and left.

 

Maven: I am obviously missing some details on what happened, but I'll try to build on your experience. First, grab yourself a cup of room temperature water for the interview (room temperature water is better for the vocal chords), as you will do lots of talking. Be on time or early. When greeted, use a firm hand shake, look the interviewer in the eye, and introduce yourself. Then I like to take a look around the office for items of interest (e.g. a picture of the family) or leverage some of my background info and start with some small talk.

 

Motley: Is there really any point to the idle chit-chat? Seems like a waste of time.

 

Maven: On the contrary. Some small talk sets the tone for the interview and can get both the interviewer and you smiling and in positive spirits. Remember that you never get a second chance to make a first impression. Use it wisely. It also helps you drive the beginning of the interview and ensure positivity is flowing.

 

Motley: Fine. So I get past the chit-chat and into the core questions. Any advice, Dr. Phil?

 

Maven: Oh, please don't call me that! Let's take a common scenario in an interview - you are asked a technical question. First thing that I like to do is practice active listening - repeat the problem back to the interviewer. This practice accomplishes a couple of things: (a) you ensure you understand the problem; and (b) it gives your brain more time to process your approach. Follow this with thinking of clarifying questions, and start writing your assumptions on the whiteboard. Whatever you do, always think out loud. The probability is very high that the interviewer does not necessarily care that you come up with a concrete correct answer. Instead, they generally want to see  your thought process. Do you ask the right questions? Do you make the right assumptions? Do you stick with the first solution that comes to mind? Additionally, don't ramble - get to the point.

 

Motley: Repeat the problem, ask clarifying questions, write down assumptions, and think out loud. I cannot say I did all of those things in my interview, so something to work on.

 

Maven: Right. When solving the problem, there are a few strategies to help you think creatively:

• Can you break assumptions on the input? For example, would preprocessing and having a sorted input make the solution easier?
• Look at the problem in reverse. Does starting at the result and moving backwards help? Does processing the input in reverse order help?

• Know your data structures. For example, perhaps a less-used data structure like a trie is the best suited to your problem.

• Understand "Big O" notation. Many interviewers like to ask about the performance of your algorithm, and "Big O" notation is a standard descriptor.
• If asked about a well known algorithm, state that you would look it up and refer to the write-up to code it. You may not get away with this, but give it is worth a shot.

• If you get stuck, do not be afraid to ask for your help. You would do that on the job, wouldn't you?

 

Motley: Decent tips. Anything special about coding problems?

 

Maven: There are a few things special tips when doing coding problems. Important tips are to design the solution and drive the solution with tests:

• Continue to think out loud - don't go dark. Remember, the interview wants to see how you think.

• Avoid jumping into coding - think through the problem and do a design if necessary.
• Solve the easy problem first. Do not prematurely optimize. Do not forget boundary conditions.

• Start with an API signature for your function and clarify with the interviewer that it looks reasonable.

• My personal preference is to drive the solution with tests, and take a Test-Driven Development approach. Start with the most basic inputs and generate the right output. Then create more tests and continue to refine.
• Talk about your best coding practices, but do not necessarily do them on the whiteboard. For example, state that you would assert at a particular point, or that you would add a comment header to the function, or that you would normally catch a particular error condition (like out-of-memory).

 

Motley: Wow, there is a lot to it. I usually just jump right into coding and come up with an answer.

 

Maven: You can do that, but you miss the opportunity to prove your value in other ways. Interviewers want you to put thought into a problem, just as you would on the job. Other small tips include maintain eye contact as much as possible to show confidence, and avoid getting flustered - take deep breaths and think through the problem. Remember: you are not going to write your best code on the whiteboard - it is about how you think.

 

Motley: Okay, I've solved the problem and now I am done, right?

 

Maven: Uh, no. You need to finish up by concluding and following-up. Ask those questions you prepared in advance. Then thank the interviewer, and ask what the next step is. Also, after you leave I recommend immediately sending an e-mail to those on your interview loop thanking them for their time and stating that you enjoyed meeting everyone. They made a big investment our of their day in interviewing you - the least you could do is thank them. Be as polite as possible . If they turn you down for one position they may call you back later with another opportunity if they like you. And as a friend of mine, I.M. Wright says, "Don't be a jerk." Being nice can pay dividends later.

 

Motley: Wow, that is a lot of information for one basic interview. Now I have to try and leverage it.

 

Maven: You like math, right? Here is the formula for for interview success:

 

YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

 

You have to factor in natural talent and ability, but let us assume you have that covered.

 

Motley: Do you always have to put such a geeky spin on things? It gets old.

______________________________

 

James' Pointer:  Having just gone through a set of interviews at Microsoft, I sat down and thought about some of the things that helped make me be successful at the interview loops. The formula above is what I came up with. Different things work for different people, but these are some techniques that I have tried and seem to have worked. I would be interested in hearing your formula, and best practices for being successful at interviews.

 

BTW, I am transitioning over to a new development role on the Xbox team, and am very excited with the new opportunity!

 

Maven's Resources: 

• None this time.