Why Data Structures Are Irrelevant to Software Engineering Interviews(medium.com)
medium.com
Why Data Structures Are Irrelevant to Software Engineering Interviews
https://medium.com/@jacobgreenleaf/why-data-structures-are-irrelevant-to-software-engineering-interviews-and-what-can-be-done-about-it-bd9b7a9a0bb8#.ui02ekfiz
9 comments
An indexable skip list is a skip list annotated with, like you said, the number of elements in the sub list. I think you are discounting the setting of the interview. It's not an impossible question, just like it's not an impossible question for an electrical engineer to discuss PID control tuning, but it's something that is not very appropriate for an interview. There's a reason these style interviews are called "grilling". Interviews are stressful without the pop quiz style questions. One could easily misread the question as "calculate the median of a list of integers" and forget the sliding window aspect of the question, and spend 15 minutes explaining sorting a list, grabbing the middle element, then getting thrown off when they realize it's a data structure question instead. These are reasonable problems outside the interview context, but not appropriate within.
You can always screw up an interview, or maybe some interview process is suboptimal, or some people feel pressure. But the claim you made was that these are questions that you memorize the answers for, that they're trivia questions. I can tell you, I have not, in any interview, in the past 7 years, gotten a question that I already knew the answer for.
And I've asked questions that people didn't already know the answer for, and guess what they do? Many of them figure out the answer. After all, they're questions designed to be ones that you can figure out the answer to in 20-30 minutes.
And I've asked questions that people didn't already know the answer for, and guess what they do? Many of them figure out the answer. After all, they're questions designed to be ones that you can figure out the answer to in 20-30 minutes.
[deleted]
You can reduce a lot of specialized knowledge to "trivia" by noting how it can be easily looked up, nowadays. But asking candidates about data structures is hardly the same thing as asking them to spew out memorized responses. There's a big difference between "tell me the exact steps involved in the rebalancing algorithm for an AVL tree" and "here are some requirements for an application, what data structures would you consider using and why?" These sort of questions are designed to test for generalized background knowledge and experience working with data structures, not simply whether the candidate knows exactly what a skip list is. It also demonstrates a general ability to apply CS knowledge to real-world situations.
I believe there's an unconscious fear that most programming jobs are a far cry from computer science. Most developers are gluing modules to each other without any concern for how they're implemented.
The author used the word "trivia" and I couldn't agree more since your can google the answer. Trivia interview questions are a result of our industry not having the resources to teach beginners. I'd much rather hire people who are intellectually curious and can learn on the job.
The author used the word "trivia" and I couldn't agree more since your can google the answer. Trivia interview questions are a result of our industry not having the resources to teach beginners. I'd much rather hire people who are intellectually curious and can learn on the job.
For me, if a candidate doesn't know the solution right away, but can (in some reasonable time) come up with a solution on her own after some googling, it's a huge plus. Ability to improvise and apply known solutions to a completely new problem is a sign of a great engineer.
i don't get the hate. yes, the bulk of your work might not be designing or implementing search structures. there may be better ways of predicting whether or not someone is going to have a positive contribution..but
if you don't have some basic understanding of costs and complexity, and have a vague notion about how things are implemented "under the hood", then you probably aren't really that useful.
if you don't have some basic understanding of costs and complexity, and have a vague notion about how things are implemented "under the hood", then you probably aren't really that useful.
Sure. The problem is, these questions don't test that, they only test your ability to memorize the answers software engineering interview questions.
If they really cared about a "basic understanding of costs and complexity" they'd ask questions about the basics. These are highly specialized "gotcha" questions that do not correlate with actual job performance.
If they really cared about a "basic understanding of costs and complexity" they'd ask questions about the basics. These are highly specialized "gotcha" questions that do not correlate with actual job performance.
For example, instead of an "indexable skip list" (whatever that is) I'd have said a red-black tree (or whatever) where each node keeps track of how many elements are in its subtree. At least if a simple log(n) solution is tolerable. And you know, I've never seen this problem before. I didn't "memorize the answer." You have to put together general background knowledge and find a solution. Putting summary information on the nodes of a tree is a general-purpose data structures trick.
Also, take, for example, the cycle finding problem. I came across that question once in a low-pressure situation and invented Brent's algorithm. Today, that is a bad interview question because it's too famous. But generally speaking it's very easy to solve if you've never seen it before: maintain a hash table of the pointers you've seen. Does that take up too much space? You can adapt that solution to use less space.
Granted, there are developers that can get some kinds of useful stuff done that can't figure out math problems or algorithms problems on the spot, but it's wrong to conclude that other people are memorizing answers to these questions. After all, interviewers at some companies are trying to come up with questions and tasks people haven't heard before and keep their questions secret.