
Why Data Structures Are Irrelevant to Software Engineering Interviews - greenleafjacob
https://medium.com/@jacobgreenleaf/why-data-structures-are-irrelevant-to-software-engineering-interviews-and-what-can-be-done-about-it-bd9b7a9a0bb8#.ui02ekfiz
======
SamReidHughes
It's really annoying when somebody gives examples of difficult unsolvable
problems when in fact they're pretty damn solvable.

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.

~~~
greenleafjacob
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.

~~~
SamReidHughes
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.

------
charles-salvia
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.

------
TeffenEllis
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.

------
ivanhoe
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.

------
convolvatron
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.

~~~
ordinaryperson
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.

