Fannie Mitchell Expert in Residence, YJ Yang '15 presented on Coding Interview Strategies on campus in January 2016. These are notes from his presentation.

1. Career Center
Fannie Mitchell Expert in Residence: Coding Interview Strategies for Success
Adapted from YJ Yang, ’15 Campus Presentation January 27, 2016
What does a technical interview look like?
• An actual engineer will interview you, not
necessarily from the team you’re interviewing for
• The following schedule applies for both phone and
on-site:
-Introduction
Interviewer introduces self/team,
interviewee introduce self,
“What made you apply to this company/
position?”
-1 or 2 coding challenges
-“Any questions about us?”
Advice: Introducing yourself
• Before you start, offer them a hard copy of your
resume, if on-site
• Keep it short, get straight to the point
-If you have a specific area of expertise, discuss
how you’ve come to choose that area
-If not, focus on the variety of engineering
you’ve had experience with
• http://stackshare.io
Use this site to see what types of stacks
(technology platforms/software, etc.)
a company uses so you can talk about your
own skills in relation to what they use
Advice: Ask for Feedback
At the end of every interview session (both phone and
on-site), ask these three questions:
• Do you have any feedback for me? Is there
anything I could have done better?
-This is particularly important at a company
like Microsoft, where interviewers talk to one
another before each session of your on-site
interviews, so you can continue to improve
throughout the day
• What are the next steps?
• Can I have your email address? (send a thank-you
note immediately after your interview)
Three categories of coding challenges
Data Structures and Algorithms
Unless you’re interviewing for a position that
is really intensive on data structures and
algorithm analysis, you can likely expect only a
very small subset of what you learned in CS201
Data Structures
-Linked lists
The most popular interview question
Prepare for problems where you have to
use two cursors
• Hash sets/maps
-Know at least one naive implementation
-Worst-case Big-O can get tricky - it is not O(1)
• Trees
-Know how to traverse a BST and why it is
ideally O(log N)
-It’s unlikely that you will be asked how
to efficiently remove a node or about how a red-
black tree works
• Graphs: Know DFS vs BFS
• Heaps: unlikely that you’ll encounter questions
about this
• Stacks, queues: unlikely that you’ll encounter
questions about this
Algorithms
• You should be ready to do Big-O (both time and
space) on your algo
• Usually comes down to three types:
-Brute force: O(N)
-Divide and conquer: O(log N) or O(N log N)
-Dynamic programming: O(M*N) or something
like that
DP is a surprisingly popular topic. But
always keep in mind that DP is nothing
more than just memoizing
Duke Career Center • studentaffairs.duke.edu/career • 919-660-1050 •
Bay 5, Smith Warehouse, 2nd Floor • 114 S. Buchanan Blvd., Box 90950, Durham, NC 27708

2. Algorithms, cont.
• Sorting/searching algorithms you have to know
-Binary search, quicksort, mergesort, bucket/
radix sort
-You have to know how bucket/radix sort relates
to the RAM
-It’s unlikely you’ll encounter other algorithms
• http://www.bigocheatsheet.com
Platform-specific
• e.g. What will the result of this JavaScript code be?
• If you applied to a very specific position, you
should expect these, for a general position at a
large tech company, you won’t really be asked
these
• The best way to learn these is through experience
• Advice: having an expertise in a specific platform
as an undergrad will really broaden your options
-Pick a field (if you’re not sure, iOS is in high
demand), buy the bible-status book in that field
and master it, then try a few projects and
publish them on GitHub
GitHub is a great way to show your skill
and code that you’ve written
-Read https://news.ycombinator.com every
single day to catch up on recent developments
inside/outside your field
Design
• For software engineering positions, these
questions have you sketch the big picture of how
to implement an actually functioning software
whole
• Know roughly how to design the following:
-Hangman solver
-Minesweeper
-Google AutoComplete
-Raft consensus
Three caveats of coding challenges
• Whiteboard coding
-In an on-site interview, you’ll most likely be
writing actual computer code on a whiteboard
with a marker
-In a phone interview, you’ll be using a shared
document like Google Docs
-Typically, pseudocode is fine, language is your
choice, and the code doesn’t have to be
completely functional (except for with Google)
-Try to completely silence your inner voice and
speak everything out loud
-If you find this difficult, one tip is to try
breathing only through the mouth, not through
the nose
• Assumptions
-Interviewers will intentionally give you
problems with incomplete preconditions
-e.g. Write a function that finds a phone number
in a given string
A question like this already has a number of
traps. Be sure to ask questions like:
What is a phone number? (e.g. Does it include
dashes? How many numbers?)
What is the given string encoded in? UTF-8?
ASCII?
-Whenever you are asked about something with
strings, question them- there are often a lot of
hidden traps in a question like this
-Keep refining your preconditions until the
interviewer asks you to move on
• Testing
-You should always offer to describe how you’d
test your solution on a holistic level
-Pro tip: the “60% unit / 30% integration / 10%
user-agent” rule of thumb
-Other types of testing: load, monkey, etc.
-https://github.com/minimaxir/big-list-of-
naughty-strings
Duke Career Center • studentaffairs.duke.edu/career • 919-660-1050 • Bay 5, Smith Warehouse, 2nd Floor •
114 S. Buchanan Blvd., Box 90950, Durham, NC 27708