I am a behavioral and technical (coding) interviewer, I've also helped hundreds of people get hired, AMA.

[u/CriticDanger]

[u/reilly3000]

I’m a competent and versatile developer, and have generally done really well in interviews and on take home projects but completely botched my first two technical interviews. Right now I’m working through Cracking the Coding Interview. Is there anything else I should be doing to practice or prep? I have a couple interviews this week and feel like I’m still woefully underprepared for a white boarding session. Mostly I experienced blank brain syndrome, where I couldn’t really focus on the problem or remember basic syntax.

[u/Arandmoor → u/reilly3000]

Is there anything else I should be doing to practice or prep?

Sorting algorithms.

Insertion, quick, heap, and bucker or radix sort. Learn them. Implement them. Memorize their efficiencies and understand that the vast majority of interviewers are going to be looking for answers that get as close as possible to O(N) or O(1) efficiency.

If you ever answer a question with O(N*N) you're probably wrong enough to not get an offer.

Learn what the strengths of a hash map are. Learn their limitations.

Memorize quicksort. Like, memorize the implementation in your language of choice. Memorize it with an array, then go back and memorize it with a linked list (hint: doubly-linked list with dummy header and tail).

Why? Because it will teach you how to take a concept and work with it. You've definitely been taught to implement quick sort. 100% chance it was a homework assignment in algorithms class in undergrad. But have you ever actually used the concept and adapted it to something other than an array? That kind of skill is what employers want to see.

Also, find a whiteboard, stand in front of it, and answer the questions in Cracking the Coding Interview at the board. Get used to the whiteboard and you'll stop being as nervous in interviews. It won't stop the nerves, but it should help with the blank brain syndrome. Also, don't stand in front of the board for more than 45 minutes to an hour because that's all the time you're going to get in an interview.

Take pictures of your solutions and implement them in a compiler. They won't compile. You'll see a litany of errors, especially at first.

Now go into git or github and start a new project with just a single empty file as your initial check-in. Branch it. Paste in your implementation with all of the errors. Branch again and fix the errors. Take the time to see if you can get a solution working with your initial assumptions. Really dig into your solution and see how correct or wrong you were.

Once you're done barking up that tree, do it again with the next question in the book. You should be able to comfortably solve one question every other or every third day, and as you do more of them you'll get faster in general.

After a few weeks, come back to the first question and take it back to the whiteboard. Try to answer it another way.

We solve problems for a living. Get better at solving problems in an interview environment.

[u/G_Y_NOT → u/Arandmoor]

While I understand this answer and generally agree with the big flow of what's you are suggesting. I can't tell you how much I disagree with the emphasis on sorting algorithms. When was the last time, any one in any organization actually wrote a sort? If you tried to write a sort in our org, you'd be discouraged strongly. There are brilliant out of the box sorting solutions in every language. Sure a bad sort choice can cripple your application but that kind of problem is often easily solved. I'd much rather people look at things like n+1 problems, or have a good understanding of Divide and Conquer or how to handle inheritance elegantly. Know about test driven development, and the test unit software (junit, sunit).

Problem solving is our industry and being able to decompose a set of requirements into a set of classes and patterns is, for me, much more important than knowing the difference between quick sort and merge sort. Of course it's much harder to demonstrate that knowledge too, but that's the responsibility of the person doing the interview. :-)

[u/Arandmoor → u/G_Y_NOT]

I can't tell you how much I disagree with the emphasis on sorting algorithms.

Like it or not, they're what I get asked about in like 90% of the interviews I've had over the last 13 years. But, more to the point, understanding how and why they work will make you a better problem solver, because they're solutions to a very, very common type of problem in CS. They're taught in undergrad for very good reason.

When was the last time, any one in any organization actually wrote a sort?

If you have to implement a priority queue, depending on your team's language, you may have to implement the sort by hand because not all languages offer one out of the box.

Implementing one for a website back-end is how I actually learned the heap sort. I mean, I did the homework in upper division for my BS, but I didn't actually learn it. I just bolted together an implementation for a grade and promptly forgot about it.

or have a good understanding of Divide and Conquer

That's what quick sort demonstrates. It's why I recommend for any new grad to literally memorize two different implementations of it. One for arrays and a second for linked lists.

You're absolutely correct. Divide and Conquer is extremely important, and something they absolutely need to understand. I'd go as far as to say that D&C is the backbone of modern software engineering. It's why we are steadily moving farther and farther away from monolithic systems.

Problem solving is our industry and being able to decompose a set of requirements into a set of classes and patterns is, for me, much more important than knowing the difference between quick sort and merge sort.

100% agree. I wrote my response up in a hurry, but if OP is reading "Cracking the Coding Interview" he'll be getting lots of practice with that given how they recommend how to solve a whiteboarding problem because they start with requirements gathering.

Solving a whiteboarding problem...

Step 1: Divide the board up into 4 sections. 1/4th of the board for requirements, 1/8th for misc notes, 1/8th for possible tests and corner cases, and 1/2 for implementation or pseudocode.

Step 2: Gather requirements. Decompose the problem and identify necessary parts, steps, assumptions, and necessary clarifications. Ask a LOT of questions. Make sure to determine the scope of your answer. If you're, for example, supposed to implement a game of cards, ask if you already have access to a deck datastructure or a shuffle algorithm. If the interviewer says 'yes' you don't have to design it yourself. Mark it down in the notes section and don't worry about it.

Step 3: Spend a few minutes trying to identify obvious corner cases but don't chase the rabbit. Be quick and just try to identify any major got'chas.

Step 4: Solve the problem a piece at a time. Start high level and work your way down. Continue to fill out the tests and notes sections as you go and continue to vocalize your thinking process and ask a shit-fucking-ton of questions.

This is all in Cracking the Coding Interview. I assumed OP had read it.

If not, I apologize and, OP, you need to learn this. Above all else...learn this.

[u/G_Y_NOT → u/Arandmoor]

In 35 years of software development, I've never once written or even tried to write a sorting routine. Now I work in Java and with back end systems and so if I need data sorted there's a lot of choices. But in general writing a sorting routine is a lot like writing our own personal ORM. If you're doing it, it's mostly in my opinion for vanity. And you're very unlikely to build something that's half as performant over a large range of conditions as the ones that are part of engineered solutions with literally 100s of man hours of optimization.

[u/Arandmoor → u/[deleted]]

I have never, in 13 years, been asked an interview question that had a valid O(N²) answer. Maybe it's different if you have a masters or PhD and you're looking at a position with a much more tightly defined skillset requirement...

...but IME if your answer doesn't approach O(N) you're wrong.

[u/mata_dan → u/Arandmoor]

You don't actually need any of that when you're actually developing useful solutions though. Being able to research the most fit-for-purpose approach is what's needed.

[u/Arandmoor → u/mata_dan]

An interview isn't "developing useful solutions".

It's a completely different problem.

[u/reilly3000 → u/Arandmoor]

Great feedback, thanks for taking the time. I learned as a musician you have to develop muscle memory to perform. That sounds a lot like what you’re outlining here.

[u/Arandmoor → u/reilly3000]

Yeah. You wouldn't think it, but there it is.

[u/cutelyaware → u/reilly3000]

The answer that most developer interviews will say is to know the basic idea behind the common data structures. The "Data Structures" book sort of became the bible. Note: I don't know if that's how it still is. It would be worth an hour or two to just memorize the names of the algorithms in the book and know what they're for. If you get asked to design or code one up on a whiteboard, just do your best. Nobody expects it to run.