[ep103]

I'm not the parent post, but many, many of the interviews I've done, the candidate just says "I'd use a hashtable." Why? well, the honest answer was because the candidate had another interview, and the answer was a hashtable. Now he knows hashtables. Okay great, but I'm not interested in whether or not you know how to use a hash table. I'm asking if you know how to choose which data structures fit the question, ie, can you program. I expect its the same reason google asks (used to?) everyone about red/black and b trees. Same thing, just levelled up a level.

What's horrifying is there are now people (occasionally) on /r/learnprogramming where the person can wax on for ages about obscure data structures or algorithms, but you ask them something simple (What sorta unit tests would I write for this? What should I keep in mind before deploying this app?) and it falls apart, they don't know how to program, they've just been reading crack-the-interview type books. (though at least that shows a _lot_ of gumption, dedicate, intelligence)

[kafkaesq]

They've just been reading crack-the-interview type books.

Exactly as the standard modern interview culture incentives them to do.

[burger_moon]

Pretty much. This is where I am right now. I get off work and stop doing web development to practice data structures and algorithms because that's what intviewers want. They don't care about the actual web development experience and the questions I've been asked in all my recent interviews reflect this.

I can't wait to be done interviewing so I can go back to working on fun side projects after work.

[azraomega]

I find it's more of communication problem, because what you assume they know does not match the reality of the situation. Like you ask "can you program?" A mechanical engineer who did a little VBA could apply for that job... People who stay in school all their life rarely get opportunity to be current and relevant stuff used today. This is referring to new grads. They just celebrated a huge life achievement without actually knowing what they don't know with a :D face... some more resourceful ones would find these kind crack-the-interview stuff and maybe get a job - to know what you know for compensating what you don't know. I'm wondering what if tech hiring reach out to students in school and learn what hiring people don't know and work with school to teach what students should know would probably have saved a lot of time... Again, this refers to new grads. I've seen too many not getting jobs these days.

Well. Communication problem exists with professional hirings as well. I blame engineers' lack of empathy (both interviewer and interviewee).

[thr0waway1239]

If only you could have someone review your comment and tell you all the ways you show bias, presumptions, not-like-me prejudice and a general insiders vs outsiders tone.

[cheriot]

Describing an additional perspective is more constructive than pointing and claiming prejudice.

[thr0waway1239]

A very simple example of the complete divergence between "algorithmic" thinking and "software engineering" oriented thinking is explained in this blog post [1]. You cannot, for example, TDD your way to writing a sudoku solver without figuring out the basic math. The line below is an indication of not-like-me, there is no guarantee that doing the first part well (data structures) means you can do the second one well (unit testing), but vice versa too.

> where the person can wax on for ages about obscure data structures or algorithms, but you ask them something simple (What sorta unit tests would I write for this?

And

> I expect its the same reason google asks (used to?) everyone about red/black and b trees. Same thing, just levelled up a level.

This is quite presumptuous. After all, even the folks who actually invented these data structures went through many, many iterations of failed attempts at data structures before finding out that a red/black tree or a b-tree is the right "problem-data structure" fit. Does their previous failed attempts mean those people didn't know what they were doing? These data structures were iteratively and slowly refined into what they are today: does anyone believe they just "struck" the inventors as the right structure for the problem at hand?

Suppose the "right" data structure is more complex than a hashtable. How often are you running into this data structure in your code base? If it really is a lot, you PROBABLY know how harsh it is to judge a candidate by their inability to come up with the appropriate data structure for something more advanced than a hash-table. Don't believe me? Go and look at the many open source projects you use at work today. What is the most advanced data structure you see there? Now ask yourself how much value the programmer has provided you by creating that project? Would you reject that person if you found out their data structure knowledge maxed out at the hashtable? (Of course, if you are actually some company where the impact of the correct choice of data structure can be directly observed on your bottom line - you are already an outlier. What are you doing dispensing generally applicable advice?)

And lastly, based on what I see in the comment, suppose the data structure is more complex than a hashtable, say a tree. Would you ask whether they have used/maintained tree data structures in their code before? If they have not, will you chalk it down to lack of exposure, or lack of smarts? If you are keen on seeing if they can write recursive code, surely you have some simpler ways to test that?

Whatever ability you THINK you are gauging by choosing the candidate who can do a spontaneous problem-data structure match in an interview environment, it is more likely you are just optimizing for the time you can spend on a given candidate and then justifying your decisions based on their failure to answer "a simple thing such as X". There is an excellent chance the candidate could go out of the office, spend a few hours thinking about it deeply, and come up with a clever, maintainable solution to the problem using neither a hashtable nor the data structure you have in mind. They may have failed to meet your expectations, but there is a not very small percentage possibility that this says more about the interviewer's time constraints rather than the candidate's abilities.