Tries, dictionaries, and queues: Applying data structure knowledge on the job

I've held numerous software engineering mock interviews in the past two months, and a question I've gotten a lot from participants is: "I know I need data structure knowledge to pass most technical interviews, but how much am I going to need it for my day-to-day job?"


This is a companion discussion topic for the original entry at https://triplebyte.com/blog/3-times-i-used-my-knowledge-of-data-structures-on-the-job

Here’s the thing. I’ve used data structures and algorithms on the job. I used a Trie to create a Web Services layer for a company (still in use, open source at https://github.com/doncl/SeeSharp/tree/master/Sid).

And I’ve used linked lists in the 90s, in my C++ days, and in-memory B-trees, etc.

But in none of those real-world cases, was I asked to build the thing or solve the problem within 20 minutes on a whiteboard. SID took me a week to build - a day or two to get up and running, and the remainder of the week to make sure it was at parity with the platform it replaced, and was tested and hardened sufficiently to deploy.

My most recent interview session, with a FAANG company, involved 5 hours with 10 interview problems. Each 1 hour session had two engineers, and I got asked two questions in the hour, with the expectation I could produce code on CoderPad that solved the problem.

One of the questions was about finding a cycle in a graph. Another one was to detect disconnected graphs. I had JUST studied exactly these problems the weekend before (Dijkstra’s algorithm, adjacenty matrices and lists), etc.

But there’s no way, in the face of crippling stage fright, that I a strange code editor (CoderPad), that I could deliver a code solution in twenty minutes. If I practiced graphs day in, day out, I could probably get to where I could spit it out rotely. But there’s the entire broad world of computer science problems the interviewer can choose. I can’t cover all that.

To quote from https://web.archive.org/web/20130313143119/http://www.symform.com:80/blog/interviewing-software-engineers/

"
What is broken with the traditional interviewing process for engineers?

  • It selects candidates purely on their ability to think on their feet. While this is not a bad thing, it doesn’t encourage success for engineers who are deep thinkers, and who prefer to think and create in a quiet personal space without having someone breathing down their necks in an interview setting. These types were some of the best engineers I worked with."

I don’t understand why the industry continues to interview like this, other than general laziness and inertia. It creates both false negatives and false positives; if professional software engineering were like a programming contest (which it most emphatically is not), then maybe you could argue that it’s only false negatives, but…

In short, of course you will use data structure knowledge on the job. But not hourly, or even daily, or even weekly, and maybe not even monthly. But you definitely need to know this stuff, and know where to look for references and be able to build stuff, and use the background in your thinking and coding.

But you’ll never, on the job, have to solve one of these data structures problems, with no references and tools, in twenty minutes, in a scenario where you career path depends on the outcome.

The process selects for a certain kind of personality, that is a subset of the kind of people who can excel. It creates a feedback loop, where the employee base of engineers and interviewers become more and more monotone, and while I have absolutely no objective evidence, I believe it impedes diverse hiring (that last is my conjecture only, but I do believe it).

4 Likes