Surviving the coding interview

How to turn this: into a job.

So, you're in an interview...

Things are going great!There's a good culture match!

It's an engaging work
environment!

They're working on interesting projects!
You want the job!

...and then, they ask you to step to the whiteboard...

Employers want to see...

...that you can think your way through a problem to arrive at a design

...that you can turn your design into code

...that you can adjust your design as you implement it

What an interviewer is looking for

How efficient was your algorithm?

How well did you understand the tradeoffs between different choices?

How well did you communicate those tradeoffs?

How long did it take you to develop your algorithm?

How clean / readable / maintainable was your code?

How well did you test your code? How buggy was it?

When you found bugs in it, how did you go about fixing them?

From: http://blog.geekli.st/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle

How to answer questions

Step 1. Ask questions

Step 2: Talk Out Loud

Step 3: Really think through your approach

Step 4: Code (slowly and methodically)

Step 5: Test and Fix (Carefully!)

Also from: http://blog.geekli.st/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle

Examples of coding questions

Given two nodes in a binary search tree, find the lowest common ancestor of the two nodes.

Describe how you would implement the tinyurl.com website.

Given a cube with sides length n, write code to print all possible paths from the center to the surface.

Design the data structures and algorithms to detect typos in a document and then provide suggestions to the user.

Yet again from: http://blog.geekli.st/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle

Examples from my recent interviews

Design a physical object

Perform a calculation

Step through a process

Designing an object

Design a toaster

Designing an object

List the states a thing can be in:
waiting, holding bread, cooking, warming

List the actions a thing can do or have done to it:
insert bread, start toasting, timer done, pop

List interfaces and alerts:
start lever, doneness settor, heating indicator light, manual popup, internal timer

Then describe the interactions between states, actions and interface. Try to think about them in terms of programming concepts (objects, methods, messages, timers, interupts, alerts and UI elements)

Practice doing this with things around your house (it's kind of fun)

A toaster object

Instance variables/propertiescurrentState

doneness

timer

MethodsstartCooking

stopCooking

abort

_startTimer

Perform a calculation

Given a time, calculate the angle between the hands on a clockThink about the
basic arithmatic of
the problem

Watch for any subtle
gotchas`

Solving the clock problem

First: Draw a clock on the whiteboard

Think about test cases these will reveal gotchas

Ask the interviewer how they want different cases handled

Think about what information you have and what need to compute:Compute the angle of the minute hand relative to 12:00
Compute the angle of the hour hand relative to 12:00
Subtract one from the other to get the angle between them
Done!

Then, write the shape of the algorithm (c-style notation is recommended)

int clockAngle(int hour, int minute)
{
int angle = 0;



return angle;
}

Ask the interviewer if this is what they're looking for!

Compute the hand angles

Think about the clock behavior:The minute hand sweeps 360 degrees in 60 minutes. 360/60 is 6, so the hand moves 6 degrees per minute. Multiply the number of minutes by 6 and you have your angle.
For example, for 6:17, the minute hand is at 17*6 degrees, or 102 degrees.Code:
int minuteAngle = minute * 6

The hour hand behaves similarly, except it moves not just based on the hour but the minute as well (Gotcha!)

To compute the hour hand, first figure out how much it moves for the hour. There are 12 hours on the clock, so it moves 360 degrees in 12 hours. That means it moves 30 degrees in an hour. Start with that:Code:
int hourAngle = hour * 30

Then adjust it for a the minute. If it moves 30 degrees in an hour, then it moves 0.5 degrees per minute. Adjust the code to compute the hour hand angle for this:Code:
int hourAngle = (hour * 30) + (minute * 0.5)

Now that you have the angles, you can subtract the smaller from larger to get an angle.
Protip: easy way to compute this without checking which is larger is to just use the absolute value function:Code:int angle = abs(hourAngle - minuteAngle)

Gotcha #2 force the interior angle: if difference > 180 then difference = 360 - difference

And now we have our code:

int clockAngle(int hour, int minute)
{
int minuteAngle = minute * 6
int hourAngle = (hour * 30) + int(minute * 0.5)
int angle = abs(hourAngle minuteAngle)
if (angle > 180)
{
angle = 360 - angle
}
return angle;
}

up here, handwave about boundary
and error checking and stuff like that

Working with strings

Theres a whole bunch of interview problems that involve manipulating strings of characters, so it's good to feel comfortable playing with them.

Review: A string is an ordered list of characters, usually shown enclosed in quotes, like this: Hello, world.

Examples of things you'll be expecteed to do with strings is search, sort, compare and insert.Protip: Strings can be empty. They can also be really, really long. Both of these facts can bite you hard if you're not thinking about them.

Problem: find the last element of a URL
e.g.: given http://example.com/foo/bar/baz.html, return baz.html

Think about the problem. What you want to do is walk the string and find the last / character, and return everything after that.

Write an empty function:
string urlTail(string sourceUrl)
{

return tail
}

First thought: I need to walk to the end of the line, take note of the index of the most recently found / character. But that's...you know...work.

Try to cheat by using standard functions.

In this case, I realized I could use the split function. sourceUrl.split('/') returns this array: [http:,,example.com,foo,bar,baz.html]

The last element contains the answer, so the whole function body could just be:
{
stringList = split(sourceUrl,'/');
return stringList.Last
}Done, right? Maybe.

But it's still pretty trivial, so expect to be called on at least one of your cheats...

...so, could you implement split for me?

Sure...I'd love to.

You've already done some good work by reducing the scope of work down to one little thing.So chip away at the problem. What does split need to do?walk the source string from one end to the other, inserting each character to the end of a string variable.

Every time you find a '/' character in the source string, toss the contents of the string variable into a list, set the string variable back to empty, and keep walking the string

When you reach the end of the source string, toss the contents on the list and return the list

The bolded part above? That's a subtle gotcha they're looking for.

Half the time, if you just describe the above algorithm to the interviewer, they won't even ask you to write the code.

But here's the pseudocode of what we just described, in case you asked

List split(string sourceString,char separator)
{
list elements = new list()
string currentElement =
foreach (char c in sourceString)
{
if (c == separator)
{
list.add(currentElement)
currentElement = ;
}
else
{
currentElement += c
}
}
if (currentElement.length>0)
{
list.add(currentElement)
}
return list
}

`

Other problem types to get some familiarity with:

Trees and graphs

Lists, stacks and queues

Array manipulation

Recursion

Searching

Sorting

Lots of others...
Getting comfortable with these problem types will make you a better, more valuable programmer anyway, so it's worth the effort.

Bonus slide: Algorithm Efficency

Sometimes you'll be asked about how efficient your algorithm is.

Things to think about is how often are you looking at the same thing two or more times.

Imagine some set comparison process that makes you inspect each element of set b while iterating across set a. If both strings are n characters long, then you have to make n2 inspections for the algorithm to complete. This may be fine for small data sets, but what if both sets are about a million elements in size? That means a 1,000,000x1,000,000 inspections, which takes a really long time.

In computer science terms, this algorithm is called Order n2, or O(n2). O(n2) is pretty bad, you want to find an algorithm that does fewer repeats.

The holy grail is O(n), which means it looked at each element only once.

If your algorithm looks at a smaller chunk of everything with each pass, like sorting or searching algorithms, then offer something like log2(n) as an answer. There's a better than even chance it'll be correct, or close enough.

Whiteboarding SUCKS for evaluating programming skill.

We're used to be able to edit, insert, and do basic text operations when writing code. You also expect to make mistakes as you tease your way through a problem, and correct them in the execute & fix process

On a whiteboard, you can't do any of this. It screws our whole process.

But a lot of companies still do whiteboard exercises, so it's worthwhile to have some practice with them.

Some companies are moving towards having you sit in a text editor, (or a google doc during phone screens), or even a full IDE. Others have you do homework assignments, or will ask you to submit a project that you can talk about.

More about why whiteboard interviews suck: http://ericleads.com/2012/10/how-to-conduct-a-better-coding-interview/

Final thoughts...

This is a skill that can be gained through practice. You can get good enough at it.

Consider getting comfortable with a more traditional language than Ruby. They will be more universal for algorithm design, and interviewers are more likely to know these languages. Plus, they're valuable skills to have. Good to have today: Java, Python, C#

Try to relate problems to the real world. That will help you conceptualize them.

Keep asking questions. When you're stumped, it may because you're missing some information the interviewer is hoping you'll ask.

Additional resources

Book:
Cracking the Coding Interview by Gayle Laakmann McDowell

Articles:http://www.ofb.net/~niniane/interview_howto.html
http://www.jperla.com/blog/post/don-t-write-on-the-whiteboard
http://seeknuance.com/2008/02/15/interview-whiteboard-coding-tests-are-usually-worthless/

Question lists:http://projecteuler.net/
http://www.geekinterview.com/Interview-Questions/Programming

Comments? Stalk me!

Mike Begleymichael.l.begley@gmail.com (when I'm trying to come across as professional)
spam@hell.org (the email address I actually use)

Facebook: www.facebook.com/mikebegley

Twitter: @per_capsulam

LinkedIn: mlbegley