[blablablame]

I just turned down an offer after a technical interview. Just after my tech call, I call the hiring manager and said I didn't want to move forward.

Technical interviews aren't the problem, is when interviewers already have an answer they want, and if anything strays from it, they just flat out refuse the answer. Sure datastructure X maybe better when getting to a million items, but for most use cases, Y is valid, and when Y is a problem, I can easily google an alternative, but nooooooo, it has to be X from the start because or A B or C.

I like being chalenged in a interview, talk about various topics, but if for every question you have, you have one and one answer only, and any other that may fit but isn't on your spreadsheet is wrong, then seriously, F U.

Fortunately also talked with other companies that were more sane, but this 'My way or the highway' from pseudo engineers is what is wrong with hiring in tech.

[dmansen]

Are you sure this is what happened?

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.

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

[kafkaesq]

Maybe they were seeing how you reacted to being pushed.

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

[hackinthebochs]

It's an interview, the point is to discover the extent and the limits of your knowledge. You should expect to be "pushed" on the solutions you offer.

[kafkaesq]

But you can also discover that (and much more) without pushing. Or at least not by "pushing for the sake pushing".

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.

[hackinthebochs]

Meh. Ultimately people advocate for interview styles they're good at. We all think that we're the type of dev Google wants if only they would interview properly. Give me objective information over "authentic" conversations any day.

[kafkaesq]

The point is, people think their interview styles are "objective" when they aren't.

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

[dmansen]

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

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

[corysama]

I've been giving a lot of interviews lately. It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". As a result, I spend the majority of the time talking through work they did in the past with the primary goal being to determine "what did the applicant actually do on this project?" As opposed to simply hanging around the team or flipping switches to enable pre-packaged features.

[ng12]

Here's the problem I have -- how do you avoid hiring professional bullshitters? Wouldn't the guy who put together the PowerPoint for upper management sell himself better than the guy that actually wrote the machine learning system? I've just known too many people who are better talkers than coders. at least with CtCI-type questions you can't really lie or stumble your way through it. I'd rather take a few bad rejects than a few bad hires.

[jakebasile]

What is the end game for this hypothetical professional bullshitter? Let's say you hire someone who can successfully bluff past your interview. They come in on the first day, do all the HR forms, get their computer and start setting it up. Eventually they will be assigned a task, or pairing, or whatever it is you do. At this point what happens? If they are able to do the job they did not bullshit you. If they are able to do the job but not as well as you wanted, then maybe it wasn't bullshit but slight exaggeration. If they completely cannot do the job, they were obviously bullshitting.

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.

[ng12]

This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. What I've seen happen is they hang around for a year or two, jump from failed project to failed project, until they either find a niche role where they can do no harm or run out of options and get fired -- but at that point they have a year or two on their resume and will find it that much easier to get the next gig.

[vonmoltke]

> This relies on being able to accurately identify poor performing engineers, which is very tough at a big company.

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

[ng12]

Fair enough -- but the bullshitters are generally pretty politically savvy :)

[jakebasile]

The difficulty of identifying poor hires scales with their impact. If they are hard to identify, they are minimally harmful. At a big company, poor hires are diluted by size and revenue. At a small company, it is easier to identify poor hires.

[FullMtlAlcoholc]

The successful bullshitter will prepare himself for the requirements of the job by using the two weeks as an opportunity to become familiar with the relevant tech and code base.

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.

[vonmoltke]

> Here's the problem I have -- how do you avoid hiring professional bullshitters?

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.

[serge2k]

> I'd rather take a few bad rejects than a few bad hires.

This is the root cause of interviewing being shitty.

[ng12]

And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.

[danieltillett]

Bad hires are not disastrous unless new people are put in charge of critical projects. I continue to take chances on people who might not workout - sure I fire a lot (never fun), but I have also found amazing people that are overlooked by everyone else.

[vonmoltke]

> Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming.

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

[ng12]

Aside from the monetary cost of hiring them, you're making the team less productive. Time is spent training, on-boarding, doing their code-reviews, and after all that it takes at least a few months of settling in to see how they actually perform. Tthere's also the opportunity cost -- whatever project you had hoped they could tackle is now months behind and at best all you have is some slapshod code you'll need to rewrite anyways.

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

[ThrustVectoring]

It's a mixed bag. Not hiring good engineers will, ceteris paribus, give bad engineers more chances to luck through your interview process.

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.

[eschutte2]

I disagree with this. You can get rid of bad hires easily. A single great engineer can transform your entire business.

[ktRolster]

I've heard that at one company, the interviewer sits down with you and you program together for an hour. That is the extent of the interview.

[kafkaesq]

Here's the problem I have -- how do you avoid hiring professional bullshitters?

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

[InclinedPlane]

There are two kinds of questions worth asking in a coding interview, in my opinion. Very straightforward questions that should be solved by anyone with familiarity with the relevant techniques (basic programming, bit-wise operations, multi-threading, depending on the level you want to hit) basically as fast as they can write. And open ended questions which require a lot of back and forth dialogue and design and give you a chance to gauge the experience and overall maturity of the candidate. These are depth / basic competence versus breadth questions. You simply can't expect to get a much better read than that in an hour, even working side by side with someone for a year you won't necessarily have a good sense of how good a dev they really are, you're not going to find that out in an hour or a day for sure. The best you can hope for is to gauge basic competence and make a guess at sophistication and maturity then hope for the best.

[DashRattlesnake]

> It has been really difficult to come up with questions that don't end up turning into "guess my magic answer".

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.

[beamatronic]

Earlier in my career I would give white board coding questions. I would get excited when someone did come up with the same solution as me, but often get even more excited when they came up with a better solution, or made me think about changing how I posed the question. That's a good way to know if you want to work with someone - if you or they or both, get excited.

[zippergz]

Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted. First, you're getting a single data point. And second, how the person operates in interviews quite likely has nothing to do with how he or she is to work with on projects.

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.

[blablablame]

If the only look into a company is that tech interview, and he or she will be someone you will have to work with on a day to day basis, and s/he is someone that just flat out refuses to accept that maybe his answer isn't the right one, would you want to work with someone like this 8 hours a day?

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.

[dragonwriter]

> Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted.

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.

[wolfgke]

> Given that, I would expect employers to pay particular attention to putting their best foot forward in interviews

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

[wtracy]

If the interviewer is just another rank-and-file engineer rather than a manager, he/she may not be motivated to see someone get hired.

[dblohm7]

Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted.

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

[Scarblac]

On the other hand, that's what the interview process is for, right? What other information do you have except what you see in the interview?

[FLUX-YOU]

>Y is valid, and when Y is a problem

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.

[rawnlq]

I think might have been Google who said this, but you should design for 100x of your expected load and when you get within 10x you redesign and rewrite it.

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.

[collyw]

For me its the fact they expect you to take the time out to do this crap before even getting to speak to anyone technical about the job.

[ProAm]

> but this 'My way or the highway' from pseudo engineers

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.

[blablablame]

Not really. Im open to discuss any solution to a problem, from the most performant one to the most simple one (code wise) that does the job.

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.

[swillis16]

You may have dodged a bullet because if someone has a "only one answer approach to interviewing" then the inability to see other possible solutions may carry over into their daily work as well.

[sngz]

I had an interview with amazon before that went exactly like that. The question was asking for a search algorithm the answer I gave was O(n log n) if you ran it the first time and O(1) every time after that. But the answer he wanted was O(n) every single time, wouldn't accept my explanation / answer.

[strictnein]

Had a weird experience where the guy interviewing me would shake his head "no" when he didn't like the answer I was giving. Not that it was wrong, it just didn't conform to what he was expecting. It was really weird to describe a proper technical solution to someone who was doing that.

[viewtransform]

If the guy was from India(especially southern states and West Bengal) be aware that shaking the head side to side means that he was agreeing with you or indicating that he was following you.

[ktRolster]

A lot of interviewers want to hire someone who mostly gets the question right, but needs help in a few details.

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

[cjcenizal]

"Wow this is great. I think you may know more about this situation than I do! Could you tell me more about X?"

[ktRolster]

The worst is when the interviewer gets a question of stack-overflow, then modifies it slightly. The slight modifications mean that a completely different data structure should be used, but the interviewer doesn't realize that.

[oceanstone]

Let's say your approach was ideal. Is it possible the interviewer wanted to see how you'd solve the problem, if your first solution was off the table?