I ask because we interview lots of candidates who always jump straight to their favorite data structure. Given any algorithmic question, they'll immediately create an instance of their pet data structure (usually it's a HashMap), without specifying the types of keys or values. They can't explain why they're choosing this, and continually try to shoehorn the problem into it even when it makes no sense.

This interview doesn't sound nearly that bad to me. It sounds like you were discussing the advantages / tradeoffs for your choices, given various performance considerations. How do you know they considered you "wrong"? Maybe they were seeing how you reacted to being 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.

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)

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

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

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

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

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

So -- do people "push" each other around a lot, in your environment? Just to, you know, see how they react?

By like, you know, having a normal conversation. "I'm curious about this project this little repo of yours. Is there some particular reason you chose to use to use / not-use X", for example, where you're asking because you're genuinely curious, as if they actually had something to teach you, perhaps.

If they're legit you'll get a solid answer right away. And if they're not legit... you'll find that out just as fast. But the whole idea is to maintain flow and authenticity. And keep it framed as if you're learning from them, not sitting back and grading everything they say and do on some unseen scale.

And if you're not learning anything? If there's no flow, authenticity? That's when you know it's not going to work out.

Especially people in favor of endless whiteboarding and zombie-like quiz-show sessions.

This kind of question is exactly what I had in mind when I said "pushing to see how you react." I think we agree :)

At this point, what happens? If they can actually do the work, then you are fine. If they can actually do the work but not as well as you want, maybe they can be trained. If they are completely incapable of doing the work, every state is At Will, and though I know from personal experience firing someone is no fun, that is the risk you take.

I believe the threat of someone talking a good game but being unable to produce is vastly overstated. It absolutely happens, but the harm is minimal.

"Very tough"? The only big company I ever worked at was a more traditional engineering company, but identifying the poor performers was easy. The problem was the politically-savvy poor performers who used their savvy to shield themselves.

The first 90 days on the job usually don't require much code output. This is more than enough time to either learn what is required for the job. If it's too much, you still can find someone on Fiverr that you can outsource your work to.

You poke at their bullshit until the stench is overwhelming. I personally find a variation of "Five Whys" questioning very useful. Bullshitters can only go a level or two deep and so trip up fairly quickly.

This is the root cause of interviewing being shitty.

Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.

Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.

It does? I find incompetent people are generally easy to spot. As in, almost instantaneously (or at most, within a few hours). It's almost as if they want to show you how incompetent they are.

But the "long-term" bad kind? Generally that's not incompetence, per se, but personality issues ("I only wanna do it this way", "I don't want to learn / won't work with people who use X or even don't look down on it like I do", "I just don't give a fuck this company or any of youse", etc). Which by nature are of course much more difficult to spot.

And which are a completely different (orthogonal) set of issues than those addressed... "this idiot didn't immediately see the dynamic programming approach which I knew about already because, of course, I picked the problem. Even when I stared at him impatiently and distracted him with hints" style of filtering which seems to be the goal of the modern hiring process.

Issue with interviewers is that they invariably think themselves smarter than they are. For instance, just because something has a linear programming solution doesn't mean it doesn't just have a closed form solution too (most software engineers that have interviewed me would say "closed what ?", I feel). I've found, often, on interviews that you have to lower yourself to the interviewers' level to pass. Even when the problem is not so much that the interviewer doesn't know the stuff at all, the problem may be that they don't know it well enough to have a thorough understanding of the problem without preparation (and they never prepare), so they simply can't deal with other approaches. Or they provide a "warmup" question that is ridiculously hard or easy, and don't deal well with the fact that you approach it very different from what they expect for the real question.

Very few engineers, even at companies that claim to be different like Google or Microsoft, truly have a mathematical background in algorithms. This does not seem to stop them from often smugly pointing out the "right" solution from a blogpost that happens to be flat-out wrong, ill-specified and handwavy, to a Math PhD. Putting any math on the whiteboard in such situations is a bad idea. Even just pointing out the flaws in their assumptions ... Constructing a proof that it's equivalent to a well-known problem with lower complexity than their optimal solution does not often end well, as they neither can nor want to understand actual algorithm theory. They don't know the assumptions they use, and never once have I known one to question if the assumptions apply to the posed problem.

And about preparation -- it's not so much that they ask pretentiously hard questions sometimes. It's that their own level of preparation, correctness of execution and general forethought will only very seldom even roughly match what they expect the candidate to deliver. As in, they screw up all the time -- everything from picking the problem to stating the problem to stating true expectations (these are basically almost never stated) -- to simply listening to another person's perspective on it... to just watching the clock and their body language and tact in general. Yet candidates are almost always expected to deliver near-flawlessly.

As to big companies: I've found the solid majority to be quite considerate about others as human beings, generally (abstract questions about their company's impact on society or the environment aside). But as a general rule, the larger the company, the more the "not giving a fuck about this company" measure approaches 1 - uniformly and geometrically.

I would sooner invest in training somebody from the ground up, even straight out of college, if I knew that they had the humility to listen and apply their learnings to their job. It'll cost me team resources and it'll take time to get them to where I need them, but as long as I can find junior level work for them to cut their teeth on, I will take them over someone who doesn't learn any day.

The problem is that training is expensive, so I need to filter for people who will give me good ROI on training. I'm not afraid they'll leave. People who feel that they are learning a lot generally won't leave their job unless you're doing something shitty to them.

Which brings us to the common debate about how big the talent pool really is. On one extreme, you have the argument that competence is really rare and the applicant pool mostly sucks. On another extreme the applicant pool would be huge if companies would be willing to train employees. In my experience it's somewhere in the middle: there are a lot of okay people who can do certain jobs to a certain level, but most of them have an immediately visible growth ceiling because they are not as adaptable or reliable as they need to be, and as a manager it's very hard to give such a person more challenging projects to grow into.

Some of this is a managerial problem. Some managers are better at developing talent than others. Some managers are better fits for certain employees.

However, there are also employees that are just not reliable, or culturally toxic, or unable to deliver the level of results you expect for how much you're paying them. You pay the cost for such employees in taxes on team morale, project cohesion, and predictability of execution, all of them leading to projects weirdly taking far longer than they should and ending up far more complex than they needed to be.

So making a bad hire costs you much more than just the money you paid him/her. However, it's not clear that you have more to lose on a bad hire than you have to gain on a good one. That's how I ended up on the "fire fast" approach, but that had its own pros and cons.

The rhetoric is that a bad hire is pretty much the worst thing ever, and it's used to justify absurd interview practices.

Several citations in there, but it seems like a common sense thing to me. Why interview at all if you're so willing to take on the risk of a bad hire? Just take them out for lunch and ask them how they like coding.

It's also bad for recruiting purposes. If I have an easy interview I'll be reasonably assured that my future coworkers went through that same process -- what metric do I have to assume they're going to be good engineers to work with?

That happened at multiple companies I worked at, both small and large, and it just makes me terrified to hire wrong.

If you're in an environment where you hire fast, but punt fast, you can give more people chances to prove themselves. Honestly, it would help with diversity, too. If people are as good as they claim, they don't have to worry about a thing.

That's a completely self-imposed cost. A company with a process like that has no business whining about the cost of bad hires.

Most companies I've worked for had people who thought firing someone was immoral unless they did something criminal. Essentially, its the company's fault for messing up in the hire process, and the employee should not have to suffer the consequences. So the employee stays in anything but the most extreme case.

Freagin sucks.

But, as with most negatives in this discussion, overblown.

> Most companies I've worked for had people who thought firing someone was immoral unless they did something criminal. Essentially, its the company's fault for messing up in the hire process, and the employee should not have to suffer the consequences. So the employee stays in anything but the most extreme case.

That is a ridiculous position, IMO. While those people would probably consider me a sociopath, I don't see any moral imperative to maintain a business relationship beyond what was explicitly and honestly agreed to in assuming the relationship. The company has no paternalistic responsibility to its employees.

That's the consequence of deep pockets, unfortunately. If you're a young startup without much in the way of assets you certain can hire quickly and fire quickly. You don't have any asserts to sue for.

However, if you're a Google or Facebook, suddenly the stakes rise. They can always find a way to make the firing seem unjustified if they're fired on short notice, from ethnicity, gender, "culture fit" (I didn't want to go out for drinks with them), or age.

And it only has to work once for the disgruntled employee, and then they don't have to work for a while. And you better believe that a lawyer will take the chance to sue a large tech company on a contingency basis.

That's why there are so many frivolous lawsuits in the US. If you can make a halfway reasonable claim that you're not being malicious in filing the suit, and your lawyer is working on a contingency basis, you really have no downside, whereas the guy you're suing has a huge downside.

It's about differing incentives.

There are several variables involved here.

First, what's the possible payout. If the lawyer had a 10% chance to make 10 million, that would be fairly profitable. If he only had a 1% chance to make 10k, not so much.

Second, what else is the lawyer doing? There's a glut of lawyers in the United States right now. If he has his own practice and there's not much business, he might as well take the case. He wasn't getting paid for sure anyways, he might as well take a long shot.

Finally, and the part the makes the US a hotbed for frivolous lawsuits, is the question of whether or not large judgements will be enough of a deterrent for the defendant to settle, regardless of the merits of the case. Look at patent trolls suing amazon, and getting settlements of millions of dollars because they patented an online shopping cart.

Same thing like that, especially if you're a smaller business. The settlements are likely to be lower and the reward less, but they're more likely to pony up 5k to just make the problem go away without the courts getting involved.

IMO, the key thing is that interviews are designed to give political cover for the interviewers to make the hire. If and when bad hires happen, the interviewer can say that their process was technically challenging, even if it did end up rejecting someone like Brendan Eich and passing someone who put 200 hours into Cracking the Coding Interview.

I don't know, specifically. But not asking bullshit questions would seem to be a good place to start.

Yeah, that's a really hard thing to do. I try to think of many solutions to the problem I'm giving ahead of time, but that takes a lot of time and I know I'm not going get each one.

Obviously it's your prerogative to decide where to work. But walking away because you didn't like a single interview is a little bit petty.

To be fair, I might have been that guy 10 years ago, and I was probably quite an annoying know it all co-worker then, but now, after close to 20 years in the industry, having worked in software that is used by millions, being a referenced author, honestly, no, I refuse outright to deal with bullshit like this. I don't expect everyone to think what I say is right (because it isn't) but to just dismiss it since it isn't THEIR answer, is a RED flag for me and I would prefer not to work there, no matter the offer.

I keep hearing about a shortage of quality talent in the industry. Given that, I would expect employers to pay particular attention to putting their best foot forward in interviews -- since interviews work in both directions.

One that fails to do so -- or whose best foot is off-putting -- is revealing that their attitude toward potential hires and/or their ability to offer a good working environment is poor.

People talk about how a bad hire is a significant cost for employers, but taking a bad job can be a much bigger cost for the employee than a single bad hire is for an employer, and quite worth avoiding.

"Best" (in doing interviews) is not a criterion that lies on an ordinal scale, but is a multicriterial property.

One could swap "a company" and "one engineer there" and still have a perfectly valid argument.

Here is my issue with this reasoning: Y could turn into a problem in production and cause real impact of the business before you know it's a problem. You're writing hundreds of Y's over the course of months as the project goes on so some amount of first-guessing is good to have. You don't want to play wait-and-see with all of them. If it is a product where demand can spike very rapidly then it is more important to take the time to find a best solution first. One day, you thought Y would never reach this magnitude but it just did because something went viral and the internet is essentially DDOSing you (happens all the time with sites posted here going down). And some companies may take to this approach on the first step and don't want to wait until things fail to realize they used the wrong data structure for this demand. Because often, it only takes a single thing to break a product or produce the wrong output or fail gracefully.

Now naturally if your interviewer wraps this problem up in vagueness, confusion, and gotchas then you aren't going to do well. A sane interview should be more than willing to answer questions about magnitude and that tells you that Y is now a problem and you need to think of a better solution than your first one even though it is fine for most use cases.

If it seems like they were trying to confuse you or just throw their ego around, just write this business off. They are only interested in playing slots. They pull the lever until eventually someone walks in and just happens to know the answer and also wants to work there.

It will make sure you don't try to design for a billion users when you have a thousand but still gives you decent room to handle spikes and more time to write a more lasting architecture.

Aren't you saying the same thing to them when you decline to move forward? Looks like your both have the same message just relative to your position in the discussion.

When someone says: Maybe you could use a binary tree. and the reply is: No, that is wrong, what you need is X, is a different thing.

Beste inverviews I had were always a give an take. I talked algorithms, data structures, etc but never with the interviewer having a one solution answer. Best interview questions are like:

Ok, we have this domain problem, what can you do about it? and then spend a couple hours on a whiteboard on a back and forth discussion about it, maybe you get it right, maybe you dont but have another idea, etc.

When you know more than the interviewer, it's actually tough to handle that situation. I'm honestly not sure how to handle it.