Interview Process and how to approach practice

What It’s Like To Interview For A Coding Job
First time interviewing for a tech job? Not sure what to expect? This article is for you.

Here are the usual steps:

  1. First, you’ll do a non-technical phone screen.
  2. Then, you’ll do one or a few technical phone interviews.
  3. Finally, the last step is an onsite interview.

Some companies also throw in a take-home code test—sometimes before the technical phone interviews, sometimes after.

Let’s walk through each of these steps.

The non-technical phone screen

This first step is a quick call with a recruiter—usually just 10–20 minutes. It’s very casual.

Don’t expect technical questions. The recruiter probably won’t be a programmer.

The main goal is to gather info about your job search. Stuff like:

  1. Your timeline. Do you need to sign an offer in the next week? Or are you trying to start your new job in three months?
  2. What’s most important to you in your next job. Great team? Flexible hours? Interesting technical challenges? Room to grow into a more senior role?
  3. What stuff you’re most interested in working on. Front end? Back end? Machine learning?

Be honest about all this stuff—that’ll make it easier for the recruiter to get you what you want.

One exception to that rule: If the recruiter asks you about your salary expectations on this call, best not to answer. Just say you’d rather talk about compensation after figuring out if you and the company are a good fit. That’ll put you in a better negotiating position later on.

The technical phone interview(s)

The next step is usually one or more hour-long technical phone interviews.

Your interviewer will call you on the phone or tell you to join them on Skype or Google Hangouts. Make sure you can take the interview in a quiet place with a great internet connection. Consider grabbing a set of headphones with a good microphone or a bluetooth earpiece. Always test your hardware beforehand!

The interviewer will want to watch your code in real-time. Usually, that means using a web-based code editor like Coderpad or collabedit. Run some practice problems in these tools ahead of time, to get used to them. Some companies will just ask you to share your screen through Google Hangouts or Skype.

Turn off notifications on your computer before you get started—especially if you’re sharing your screen!

Technical phone interviews usually have three parts:

  1. Beginning chitchat (5–10 minutes)
  2. Technical challenges (30–50 minutes)
  3. Your turn to ask questions (5–10 minutes)

The beginning chitchat is half just to help your relax, and half actually part of the interview. The interviewer might ask some open-ended questions like:

  1. Tell me about yourself.
  2. Tell me about something you’ve built that you’re particularly proud of.
  3. I see this project listed on your resume—tell me more about that.

You should be able to talk at length about the major projects listed on your resume. What went well? What didn’t? How would you do things differently now?

Then come the technical challenges—the real meat of the interview. You’ll spend most of the interview on this. You might get one long question, or several shorter ones.

What kind of questions can you expect? It depends.

Startups tend to ask questions aimed towards building or debugging code. (“Write a function that takes two rectangles and figures out if they overlap.”). They’ll care more about progress than perfection.

Larger companies will want to test your general know-how of data structures and algorithms (“Write a function that checks if a binary tree is ‘balanced’ in O(n)  time.”). They’ll care more about how you solve and optimize a problem.

With these types of questions, the most important thing is to be communicating with your interviewer throughout. You’ll want to “think out loud” as you work through the problem.

If the role requires specific languages or frameworks, some companies will ask trivia-like questions (“In Python, what’s the ‘global interpreter lock’?”).

After the technical questions, your interviewer will open the floor for you to ask them questions. Take some time before the interview to comb through the company’s website. Think of a few specific questions about the company or the role. This can really make you stand out.

When you’re done, they should give you a timeframe on when you’ll hear about next steps. If all went well, you’ll either get asked to do another phone interview, or you’ll be invited to their offices for an onsite.

The onsite interview

An onsite interview happens in person, at the company’s office. If you’re not local, it’s common for companies to pay for a flight and hotel room for you.

The onsite usually consists of 2–6 individual, one-on-one technical interviews (usually in a small conference room). Each interview will be about an hour and have the same basic form as a phone screen—technical questions, bookended by some chitchat at the beginning and a chance for you to ask questions at the end.

The major difference between onsite technical interviews and phone interviews though: you’ll be coding on a whiteboard.

This is awkward at first. No autocomplete, no debugging tools, no delete button…ugh. The good news is, after some practice you get used to it. Before your onsite, practice writing code on a whiteboard (in a pinch, a pencil and paper are fine). Some tips:

  1. Start in the top-most left corner of the whiteboard. This gives you the most room. You’ll need more space than you think.
  2. Leave a blank line between each line as you write your code. Makes it much easier to add things in later.
  3. Take an extra second to decide on your variable names. Don’t rush this part. It might seem like a waste of time, but using more descriptive variable names ultimately saves you time because it makes you less likely to get confused as you write the rest of your code.

If a technical phone interview is a sprint, an onsite is a marathon. The day can get really long. Best to keep it open—don’t make other plans for the afternoon or evening.

When things go well, you’ll wrap-up by chatting with the CEO or some other director. This is half an interview, half the company trying to impress you. They may invite you to get drinks with the team after hours.

All told, a long day of onsite interviews could look something like this:

  • 10am-12pm: two back-to-back technical interviews, each about an hour.
  • 12pm-1pm: one or several engineers will take you to lunch, perhaps in the company’s fancy office cafeteria.
  • 1pm-4pm: three back-to-back technical interviews, each about an hour.
  • 4pm-5pm: interview with the CEO or some sort of director.
  • 5pm-8pm: drinks and dinner with the company

If they let you go after just a couple interviews, it’s usually a sign that they’re going to pass on you. That’s okay—it happens!

There are are a lot of easy things you can do the day before and morning of your interview to put yourself in the best possible mindset.

The take-home code test

Code tests aren’t ubiquitous, but they seem to be gaining in popularity. They’re far more common at startups, or places where your ability to deliver right away is more important than your ability to grow.

You’ll receive a description of an app or service, a rough time constraint for writing your code, and a deadline for when to turn it in. The deadline is usually negotiable.

Here’s an example problem:

Write a basic “To-Do” app. Unit test the core functionality. As a bonus, add a “reminders” feature. Try to spend no more than 8 hours on it, and send in what you have by Friday with a small write-up.

Take a crack at the “bonus” features if they include any. At the very least, write up how you would implement it.

If they’re hiring for people with knowledge of a particular framework, they might tell you what tech to use. Otherwise, it’ll be up to you. Use what you’re most comfortable with. You want this code to show you at your best.

Some places will offer to pay you for your time. It’s rare, but some places will even invite you to work with them in their office for a few days, as a “trial.”

Coding Interview Tips
How to get better at technical interviews without practicing Chitchat like a pro.

Before diving into code, most interviewers like to chitchat about your background. They’re looking for:

  • Metacognition about coding. Do you think about how to code well?
  • Ownership/leadership. Do you see your work through to completion? Do you fix things that aren’t quite right, even if you don’t have to?
  • Communication. Would chatting with you about a technical problem be useful or painful?

You should have at least one:

  • example of an interesting technical problem you solved
  • example of an interpersonal conflict you overcame
  • example of leadership or ownership
  • story about what you should have done differently in a past project
  • piece of trivia about your favorite language, and something you do and don’t like about said language
  • question about the company’s product/business
  • question about the company’s engineering strategy (testing, Scrum, etc)

Nerd out about stuff. Show you’re proud of what you’ve done, you’re amped about what they’re doing, and you have opinions about languages and workflows.

Communicate.

Once you get into the coding questions, communication is key. A candidate who needed some help along the way but communicated clearly can be even better than a candidate who breezed through the question.

Understand what kind of problem it is. There are two types of problems:

  1. Coding. The interviewer wants to see you write clean, efficient code for a problem.
  2. Chitchat. The interviewer just wants you to talk about something. These questions are often either (1) high-level system design (“How would you build a Twitter clone?”) or (2) trivia (“What is hoisting in Javascript?”). Sometimes the trivia is a lead-in for a “real” question e.g., “How quickly can we sort a list of integers? Good, now suppose instead of integers we had . . .”

If you start writing code and the interviewer just wanted a quick chitchat answer before moving on to the “real” question, they’ll get frustrated. Just ask, “Should we write code for this?”

Make it feel like you’re on a team. The interviewer wants to know what it feels like to work through a problem with you, so make the interview feel collaborative. Use “we” instead of “I,” as in, “If we did a breadth-first search we’d get an answer in O(n) time.” If you get to choose between coding on paper and coding on a whiteboard, always choose the whiteboard. That way you’ll be situated next to the interviewer, facing the problem (rather than across from her at a table).

Think out loud. Seriously. Say, “Let’s try doing it this way—not sure yet if it’ll work.” If you’re stuck, just say what you’re thinking. Say what might work. Say what you thought could work and why it doesn’t work. This also goes for trivial chitchat questions. When asked to explain Javascript closures, “It’s something to do with scope and putting stuff in a function” will probably get you 90% credit.

Say you don’t know. If you’re touching on a fact (e.g., language-specific trivia, a hairy bit of runtime analysis), don’t try to appear to know something you don’t. Instead, say “I’m not sure, but I’d guess $thing, because…“. The because can involve ruling out other options by showing they have nonsensical implications, or pulling examples from other languages or other problems.

Slow the eff down. Don’t confidently blurt out an answer right away. If it’s right you’ll still have to explain it, and if it’s wrong you’ll seem reckless. You don’t win anything for speed and you’re more likely to annoy your interviewer by cutting her off or appearing to jump to conclusions.

Get unstuck.

Sometimes you’ll get stuck. Relax. It doesn’t mean you’ve failed. Keep in mind that the interviewer usually cares more about your ability to cleverly poke the problem from a few different angles than your ability to stumble into the correct answer. When hope seems lost, keep poking.

Draw pictures. Don’t waste time trying to think in your head—think on the board. Draw a couple different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code.

Solve a simpler version of the problem. Not sure how to find the 4th largest item in the set? Think about how to find the 1st largest item and see if you can adapt that approach.

Write a naive, inefficient solution and optimize it later. Use brute force. Do whatever it takes to get some kind of answer.

Think out loud more. Say what you know. Say what you thought might work and why it won’t work. You might realize it actually does work, or a modified version does. Or you might get a hint.

Wait for a hint. Don’t stare at your interviewer expectantly, but do take a brief second to “think”—your interviewer might have already decided to give you a hint and is just waiting to avoid interrupting.

Think about the bounds on space and runtime. If you’re not sure if you can optimize your solution, think about it out loud. For example:

  • “I have to at least look at all of the items, so I can’t do better than O(n).”
  • “The brute force approach is to test all possibilities, which is O(n^2).”
  • “The answer will contain n^2 items, so I must at least spend that amount of time.”
Get your thoughts down.

It’s easy to trip over yourself. Focus on getting your thoughts down first and worry about the details at the end.

Call a helper function and keep moving. If you can’t immediately think of how to implement some part of your algorithm, big or small, just skip over it. Write a call to a reasonably-named helper function, say “this will do X” and keep going. If the helper function is trivial, you might even get away with never implementing it.

Don’t worry about syntax. Just breeze through it. Revert to English if you have to. Just say you’ll get back to it.

Leave yourself plenty of room. You may need to add code or notes in between lines later. Start at the top of the board and leave a blank line between each line.

Save off-by-one checking for the end. Don’t worry about whether your for loop should have “<” or “<=.” Write a checkmark to remind yourself to check it at the end. Just get the general algorithm down.

Use descriptive variable names. This will take time, but it will prevent you from losing track of what your code is doing. Use names_to_phone_numbers instead of nums. Imply the type in the name. Functions returning booleans should start with “is_*“. Vars that hold a list should end with “s.” Choose standards that make sense to you and stick with them.

Clean up when you’re done.

Walk through your solution by hand, out loud, with an example input. Actually write down what values the variables hold as the program is running—you don’t win any brownie points for doing it in your head. This’ll help you find bugs and clear up confusion your interviewer might have about what you’re doing.

Look for off-by-one errors. Should your for loop use a “<=” instead of a “<“?

Test edge cases. These might include empty sets, single-item sets, or negative numbers. Bonus: mention unit tests!

Don’t be boring. Some interviewers won’t care about these cleanup steps. If you’re unsure, say something like, “Then I’d usually check the code against some edge cases—should we do that next?”

Practice.

In the end, there’s no substitute for running practice questions.

Don’t look at the answers. Working through the problems is the best way to improve your problem solving ability.  You aren’t trying to memorize solutions.  You are trying to learn how to code on the spot (get yourself unstuck, test your code for bugs, write clean code…), so just looking at someone’s solution robs you of the experience that you gain by finding the answer yourself.

Actually write code with pen and paper. Be honest with yourself. It’ll probably feel awkward at first. Good. You want to get over that awkwardness now so you’re not fumbling when it’s time for the real interview.  Only type your code into your code editor when your completely done working through the problem.  Compiling and running the code can point out typos and errors you may have missed.  These are good to write down so you can start to look for errors you commonly make.

Test and review your code.  Once you think you have the answer, double check your work.  Try running through a few example values to see that it behaves as it should.  Test for the general case, boundary cases and cases where it should throw an error.  Look for ways to refactor your code to make it easier to read or maintain.  You will probably find something you made a mistake on and now you can edit your solution for your potential interviewer.

Tricks For Getting Unstuck During a Coding Interview

Getting stuck during a coding interview is rough.

If you weren’t in an interview, you might take a break or ask Google for help. But the clock is ticking, and you don’t have Google.

You just have an empty whiteboard, a smelly marker, and an interviewer who’s looking at you expectantly. And all you can think about is how stuck you are.

You need a lifeline for these moments—like a little box that says “In Case of Emergency, Break Glass.”

Inside that glass box? A list of tricks for getting unstuck. Here’s that list of tricks.

When you’re stuck on getting started

1) Write a sample input on the whiteboard and turn it into the correct output “by hand.” Notice the process you use. Look for patterns, and think about how to implement your process in code.

Trying to reverse a string? Write “hello” on the board. Reverse it “by hand”—draw arrows from each character’s current position to its desired position.

Notice the pattern: it looks like we’re swapping pairs of characters, starting from the outside and moving in. Now we’re halfway to an algorithm.

2) Solve a simpler version of the problem. Remove or simplify one of the requirements of the problem. Once you have a solution, see if you can adapt that approach for the original question.

Trying to find the k-largest element in a set? Walk through finding the largest element, then the second largest, then the third largest. Generalizing from there to find the k-largest isn’t so bad.

3) Start with an inefficient solution. Even if it feels stupidly inefficient, it’s often helpful to start with something that’ll return the right answer. From there, you just have to optimize your solution. Explain to your interviewer that this is only your first idea, and that you suspect there are faster solutions.

Suppose you were given two lists of sorted numbers and asked to find the median of both lists combined. It’s messy, but you could simply:

  1. Concatenate the arrays together into a new array.
  2. Sort the new array.
  3. Return the value at the middle index.

Notice that you could’ve also arrived at this algorithm by using trick (2): Solve a simpler version of the problem. “How would I find the median of one sorted list of numbers? Just grab the item at the middle index. Now, can I adapt that approach for getting the median of two sorted lists?”

When you’re stuck on finding optimizations

1) Look for repeat work. If your current solution goes through the same data multiple times, you’re doing unnecessary repeat work. See if you can save time by looking through the data just once.

Say that inside one of your loops, there’s a brute-force operation to find an element in an array. You’re repeatedly looking through items that you don’t have to. Instead, you could convert the array to a lookup table to dramatically improve your runtime.

2) Look for hints in the specifics of the problem. Is the input array sorted? Is the binary tree balanced? Details like this can carry huge hints about the solution. If it didn’t matter, your interviewer wouldn’t have brought it up. It’s a strong sign that the best solution to the problem exploits it.

Suppose you’re asked to find the first occurrence of a number in a sorted array. The fact that the array is sorted is a strong hint—take advantage of that fact by using a binary search.

Sometimes interviewers leave the question deliberately vague because they want you to ask questions to unearth these important tidbits of context. So ask some questions at the beginning of the problem.

3) Throw some data structures at the problem. Can you save time by using the fast lookups of a hash table? Can you express the relationships between data points as a graph? Look at the requirements of the problem and ask yourself if there’s a data structure that has those properties.

4) Establish bounds on space and runtime. Think out loud about the parameters of the problem. Try to get a sense for how fast your algorithm could possibly be:

  • “I have to at least look at all the items, so I can’t do better than O(n)  time”.
  • “The brute force approach is to test all possibilities, which is
    O(n^2) time. So the question is whether or not I can beat that time.”
  • “The answer will contain n^2 items, so I must at least spend that amount of time.”
When All Else Fails

1) Make it clear where you are. State what you know, what you’re trying to do, and highlight the gap between the two. The clearer you are in expressing exactly where you’re stuck, the easier it is for your interviewer to help you.

2) Pay attention to your interviewer. If she asks a question about something you just said, there’s probably a hint buried in there. Don’t worry about losing your train of thought—drop what you’re doing and dig into her question.

Relax. You’re supposed to get stuck.

Interviewers choose hard problems on purpose. They want to see how you poke at a problem you don’t immediately know how to solve.

Seriously. If you don’t get stuck and just breeze through the problem, your interviewer’s evaluation might just say “Didn’t get a good read on candidate’s problem-solving process—maybe she’d already seen this interview question before?”  In fact, it might be a good idea to let the interviewer know when you know a question.  The honesty helps you look like a better candidate and pretending like you are struggling through it or simply skipping to the solution won’t look good to the interviewer.

On the other hand, if you do get stuck, use one of these tricks to get unstuck, and communicate clearly with your interviewer throughout…that’s how you get an evaluation like, “Great problem-solving skills. Hire.”