[drugstorecowboy]

But.. why? Does that reflect anything close to the job they would be doing? Is handicapping someone in every way (You will google it for them), putting them on the spot in an already tense situation and expecting them to code while you watch the way that literally any software job works?

This is the insanity to me, "Here, do this contrived task that doesn't represent anything you will be doing... to prove that you can do the job"

I once had a whiteboard interview for a senior engineer position where they demanded that I write it in syntactically correct python, indentions and all, on the whiteboard. I'm trying to talk about code at a high level with them meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method. It turned me off to the company as a whole and the entire interview went downhill from there.

[krisoft]

> But.. why? Does that reflect anything close to the job they would be doing?

Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour.

> putting them on the spot in an already tense situation and expecting them to code while you watch

There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything.

> meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method

That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there.

By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate.

I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens.

[drugstorecowboy]

I can certainly understand that there are unqualified people who apply, what I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance. It sounds like your goal is just to filter out the absolute worst of the worst, and I'm sure its effective at that, but I believe you might be filtering out more of the top end than you realize.

[krisoft]

> It sounds like your goal is just to filter out the absolute worst of the worst,

Yes.

> I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance.

You are projecting something here. You are saying, without any supporting evidence, that the problems are contrived. They are not. They are really the core of what me and my coworkers do day in and day out.

You are also saying that the conditions are unrealistic. What makes you think that?

[drugstorecowboy]

If you and your coworkers are solving the problem you posted "day in and day out" just hire me and you can get rid of them :)

You are right though I have no evidence they are contrived other than your example problem. The unrealistic working conditions though is indisputable, do you typically relay your google search's for syntax through your boss? Do you often work under extreme time pressure on problems you have never seen before? Perhaps you do, but I can tell you with certainty that it's not the norm in the industry to work in that way.

[MrCalico]

Not the guy you responded too, but is there a good way to avoid a time pressure? A limit has to be set as to the time spent per candidate from the company's pov.

[sokoloff]

> It sounds like your goal is just to filter out the absolute worst of the worst

Indeed, this is a holy grail of the applicant funnel. If a tech-for-interviewing company comes up with a better way to remove the worst 50-ish% of applicants efficiently, they’ll have no worries about their future. (The overall applicant pool is significantly adversely skilled as compared to the have been or will be quickly hired pool.)

[jackblemming]

There is a class of engineer who have little performance anxiety by nature. They simply don’t care and are normally blunt types who love algorithms.

And they are, frankly, pretty bad at writing code because they have little empathy for the reader and greatly inflated sense of self worth. They’re the kind to use complicated C++ features or algorithms for little reason. Essentially, smart idiots.

They also believe in silly things like LC being a fair and rational way to evaluate candidates and don’t see the bias at all. “Eugh she’s an ugly woman, I think I’ll give her the LC hard and little help.”

There is another class who realizes how stupid LC is, but are happy to play the game to quickly accumulate power and prestige. They usually have psychopathic tendencies and aren’t great coworkers.

LC is great at hiring these types. Feel free to stick to it if you enjoy having them as coworkers.