[azraomega]

I'm curious. What would be a good reaction? Not reacting and accepting that's only truth from now on? Reacting respectfully saying why you think there are more than one answer, then continue getting pushed?

When I test people's reaction, it's generally not because I want to hire them. I just want to learn about people. If the purpose is hiring, overreacting but good coder will not take the job, under-reacting but good coder will not stay long because he/she will get angry eventually, over-reacting and taking the job seems desperate... I just don't see what can possibly get out this kind of test from a hiring perspective.

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

[dmansen]

[edit: Both the reactions you listed seem fine, depending on what you're looking for. But I wouldn't do this myself, anyway.]

I don't know the correct reaction, and don't do this when I'm interviewing. My point was that I could easily see a different side of this story, from the interviewer's perspective. Maybe the interviewer understood the OP's solution, and wanted them to explore a different angle.

We're lacking so much context here - what did the interviewer actually say? Was their tone gentle or aggressive? Were they flat-out ignoring the OP's answer, or acknowledging it while taking it through different use cases? We can't know, we weren't there.

I understand there are many places with poor interview practices, but I've seen enough devs come out of these types of interviews with wildly incorrect self-assessments that I no longer blindly trust these anecdotes. Unless they told you the exact reason you failed, you're speculating. And if you're an engineer that repeatedly gets turned down after these interviews at many different shops, you may not know what you don't know. Complaining about the interview process isn't a productive way to improve in those situations.

[note that my critique goes both ways: I have no way of knowing OP's skill, and their story could be completely accurate. however, I see this attitude a lot from overconfident junior devs, and that's to whom this rant applies.]