The document provides guidance on how to succeed in coding interviews. It explains that employers use coding interviews to assess applicants' problem solving, algorithm design, and coding skills. It advises applicants to ask questions, think out loud, take time to design an approach before coding, test code thoroughly, and be prepared to discuss code efficiency. Examples of common coding interview questions and how to approach them are also provided. The document aims to help applicants feel comfortable with problem types and perform well in coding interviews.

1. Surviving the coding interview
How to turn this: into a job.

2. 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!

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

4. 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

5. 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

6. 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

7. 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

8. Examples from my recent interviews
● Design a physical object
● Perform a calculation
● Step through a process

9. Designing an object
“Design a toaster”

10. 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)

11. A toaster object
● Instance variables/properties
– currentState
– doneness
– timer
● Methods
– startCooking
– stopCooking
– abort
– _startTimer

12. Perform a calculation
“Given a time, calculate the angle between
the hands on a clock”
● Think about the
basic arithmatic of
the problem
● Watch for any subtle
“gotchas”`

13. 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!

14. 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

15. 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

16. 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.

17. 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...

18. ...so, could you implement “split” for me?

19. 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.

20. 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
}

21. 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.

22. 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 n 2”, 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 log 2(n) as
an answer. There's a better than even chance it'll be correct, or close
enough.

23. 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/

24. 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.

25. 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-u
● Question lists:
http://projecteuler.net/
http://www.geekinterview.com/Interview-Questions/Programming

26. Comments? Stalk me!
Mike Begley
● michael.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