How to crack a coding interview?

As one of many Data Science graduates I started my job search and interview process. I will walk you through a common technical interview questions and what steps to take during the interview.

1. Be calm

Technical interviews are nerve-wracking. Why do these kinds of interviews specifically make us so nervous? Because if you fail to correctly express the algorithm they’re looking for you can’t proceed to next round. Or maybe you know but can’t express the correct definition for something. You then probably don’t get the job.

That’s not a great outcome, but there are far worse things. You can always just go home, brush up on what you missed, and try to apply elsewhere. That is, the belief that there’s a chance you’ll be presented with a question or challenge that you have no idea to solve.

2. What to do when you don’t have any answer

With almost any technical challenge, if you have the right approach, you can figure out a way to solve a problem. But what if you really have no idea where to start?

After listening to the question for a few seconds, you stare at the interviewer, and your mind has nowhere to go.

Here’s two potential ways to address this:

1. Link it to something you’ve done
2. Emphasize how excited you are to learn and work on such things

The first response works because it still allows you to demonstrate your experience and you can continue the conversation with interviewer.

In this case, it may not be 100% what the interviewer wanted to hear, but you’ve shown some technical acumen. You were also able to include some discussion about past experience.

The Approach of Good Interviewees

The more practice you have with these topics, the easier it will be to retrieve them from memory come interview time.

A good starting point is, of course to go through coding websites.

With all that said, here’s the typical steps we recommend for solving whiteboard questions. We’ll spend plenty of time exploring each in depth.

1. Run through a few (1–3) example inputs to get a feel for the problem
2. Unpack the brute force solution quickly by asking how a human would do this
3. Tie the brute force solution back to a pattern, data structure, or Computer Science technique
4. Optimize and run through the same test cases from step 1 again
5. If you have time, call out edge cases and improvements to the problem

It’s not a secret that a big part of the interview is a test of your communication skills.

How do you demonstrate strong communication skills?

You must keep talking:

• If you’re stuck, let the interviewer know
• If you don’t understand the problem, ask more clarifying questions
• If you have no idea what’s going on, say you need more context
• If you need a hint, let them know!

Try your best to be friendly and vocal, if only for the few hours it takes to land the job.

A Tactical Data Structure Cheatsheet

Need access to an element in a collection really fast? An array already has the location in memory.

Have to insert data quickly? Add it to a hash table or linked list.

Need a maximum or minimum in O(1) time? Call in a heap.

Need to model connections? Get a graph in there.

A special note about hash tables:

Get to know these guys very well! They can be used in a surprising number of solutions. Many problems can be reduced to searching for elements in a large data collection, finding duplicates in said collection, or storing/retrieving items. Hash tables/hash maps do these things extremely well, so always have it top of mind.

If an additional data structure doesn't help, it may be time to try out an old-school (but reliable) technique.

Introduce a Computer Science Algorithm Technique

There are a few techniques that everyone should be aware of. Usually these are covered in Intro to Algorithms classes to categorize algorithms.

They are generally tools not just beneficial for interviews, but for software engineering work in general, so get to know them!

Divide and Conquer: try to divide the problem into sub-problems that are easier to think through or solve. This allows for the possibility of..

Recursion — see if you can leverage a function that calls on itself. Be especially wary of recursion for trees.

Memo-ization- Can the partial results you’ve generated in the brute force solution can be used for larger or different inputs? If so, leverage caching of some sort. What data can you store in memory (or create and store in memory) to help facilitate the algorithm?

Greedy — think about what the best move at each iteration or step is. Is there an obvious one at each step? This comes up a lot in graph traversal problems like Dijkstra's algorithm.

What to Do When None Of the Above Worked

So none of the above patterns, data structures, or techniques are shining any light on the problem. What to do?

You have two options.

Ask more questions.

OR

Say, I’m stuck. Can I please get a hint?

Keep communicating! Interviewers are usually more than happy to give a hint — in fact, that’s their job. Certain interview questions will unfortunately have one or two “key intuitions” that you must grok before you can get to a solution.

After You Have A Working Solution

Here’s a huge key that takes a while to click. After you’ve written pseudocode for an optimized solution, manually run through 1–3 example inputs, step by step, through your pseudocode to make sure it works. Warning: nerves will be there, and you may lose your place from time to time, but this is extremely important.

Good engineers test their code thoroughly and can step through logic. The space between having a pseudocode solution and writing code on the whiteboard is a good time to demonstrate this.

At that point, whatever happened is out of your control, so be forward looking and keep your mind in the present with the interviewer. You’ll come across as much more professional if you can maintain your composure, even if the interview didn’t go exactly how you wanted.

I hope you’ve found this guide helpful. Remember that any coding challenge can be solved with the right approach, and the right mentality. Best of luck!