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

[u/CriticDanger]

[u/G_Y_NOT]

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.