Your comparison also comes off a bit disingenuous. They're talking about interview accommodations like "providing questions in advance" and "extended interview time".
Your comparison also comes off a bit disingenuous. They're talking about interview accommodations like "providing questions in advance" and "extended interview time".
Accommodations just provide optionality, and let’s people choose the approach that suites them best. Rather than assuming that you can fairly apply some rigid standardised test on people, and expect it to accurately measure individuals. There’s plenty of data, and some pretty basic stats, which show this doesn’t work.
Proving extra time provides almost no advantage to anyone. Either you can answer the questions well, or you can’t. The amount of time it takes to do isn’t very relevant, so taking more time isn’t an advantage.
Providing questions in advance also isn’t an advantage. Again you can either answer them well or not. If you’re worried about people cheating by passing the questions around, then only provide them an hour or two in advanced, or only once they’re onsite.
If you’re interview process can be fooled by giving people more time, or advanced notice, then quite frankly it’s not a very good interview process.
... and? A office that's accessable only by ladder has a lot of leg pressure, and providing wheelchair ramps would help many employees considerably too, regardless of whether they're wheelchair-bound.
Time pressure is directly tied to performance.
Sometimes, stuff breaks and wouldn't it be great if it got fixed in half an hour instead of four hours?
Projects sometimes have deadlines.
You are not talking about an accommodation made for something unrelated to the job, here. This is some gold-level mental gymnastics.
Which means tight interview deadlines artificially constrain your applicant pool, forcing you to pay higher wages. Beyond legal requirements, that’s why it’s a good idea to only care about what matters for the actual job.
Why do you assume that all interviews are structured that way? They aren't. I have interviewed with Google and that was not how most of my interview process was conducted.
The core argument is really simple. Ideal teams don’t consist of 10 identical clones of the ideal worker allowing the team to work 10x as fast. They consist of multiple different skills that allow teams to finish complex tasks more than 10x as efficiently as any one person on the team could. https://en.wikipedia.org/wiki/Comparative_advantage
If that's happening constantly, you should find a new job. That's a major red flag. Incidents should be rare at any well run org.
Sure sometimes incidents happen and someone has to deal with them. At most companies that is a pretty rare occurance (unless you're on some incident team). When it does happen, different team members have different skills dealing with them - and that's ok for a rare part of the job. Additionally, for longer incidents, often the person with a slow ramp up but better understanding is more useful than the person who jumps right in without understanding. A sure way to make things worse is to panic and try to fix things without understanding what happened well enough.
(Speaking as someone who has been involved in incident response in various jobs)
Giving more time doesn't give you an advantage, because the correct answer isn't what gets you points.
I fail to see how creating artificial time pressure makes your interview process better at finding good candidates. It results in an environment that isn't even vaguely like actual work conditions.
Whether the time pressure is explicitly mentioned, it is clear (to me) that there is an implicit expectation that the faster you answer the question, the better, all other things being equal.
I don't want to give the impression that I think the current standard of software engineering interviews are perfect, so if you think it can be improved, please tell me how.
How about you judge them on the quality of their answers? Is giving a long more detailed and nuanced answer a bad thing?
Nobody is asking an interviewee to have a full product prototype ready for demo inside an hour. What they do is present some problem to you and ask you to reason through it.
Being able to work out pitfalls in a design early, rather than several weeks in, saves a lot of time and money.
So in short, yes. It is that simple.
And a sandpile is made up of a bunch of grains of sand. [0] It's identically disingenuous to suggest that such a difference in quantity does not manifest a difference in quality.
I don't think your point is necessarily a bad one, but you're leaving a lot of opportunity for people to dismis it.
> It's identically disingenuous to suggest that such a difference in quantity does not manifest a difference in quality.
Huh? I specifically addressed that when I stated that "Nobody is asking an interviewee to have a full product prototype ready for demo inside an hour."
Are we assuming that the interviewer is an idiot who has no concept of time? That the interviewee only has some small amount of time to work through the problem they have posed, or answer questions?
If your interview process is an hour, then you're comparing a bunch of candidates who all had an hour. It's demonstrative of what knowledge you are bringing to the table and how you can work through problems. It's all extrapolation.
No, it isn't perfect. But if you find me a system that is, I've got a billion dollars for you in my pocket.
> you're leaving a lot of opportunity for people to dismis it.
Frankly, I don't care if people dismiss it. The people who dismiss are not here to engage in thoughtful conversation and aren't my target audience, anyway.
Maybe in a widget factory. Programmers have various skill levels. I'd prefer to hire somebody who takes twice as long to complete a task, if they're taking that time to ensure that it won't cause problems downstream or in edge cases. Fast & sloppy programmers who maximize a commits per hour metric are the worst.
That's a strawman. You metric of "job done" is "ensuring that it won't cause problems downstream or in edge case". Fast & sloppy programmers are not fast, as they didn't achieve your metric of job done. Thus you actually prefer fast programmers to slower ones.
Just because someone can have high productivity for a short burst doesn't mean they can sustain it, or that they can even sustain moderate productivity over a long period of time.
It's a bit like concluding that a drag car is clearly the best car because it can cover 1km the quickest, and ignoring the fact that it would take hours for it cover 3km because its engine needs to be rebuilt every 1km.
I think the worry is candidates can quickly look up answers and build up a conversation around it right before the interview. Even if they couldn't get to the complete answer ahead of time, enough grok'ing on the specific problem statement and possible solutioning could show an interview enough signal to give them a pass.
Yes, this will largely be abused by people who don't need it. Just look at how many students malinger for Adderall scripts or extra time on exams -- it's practically endemic at ivy leagues now.
Disability parking permits are another one that have shocked me at how common abuse of them is in large cities like Toronto. Essentially anytime resources are constrained and an environment is high pressure, these services inevitably see widespread misuse.
High priority low income housing is another area that genuinely shocked me. I had so many clients desperate for housing that they would falsely claim to be high-priority (victims of abuse or terminally ill) it was terrible to see.
The unpopular truth is that these systems are vulnerable to fraud and it absolutely harms people who need them most. HOWEVER, what is the alternative?
Would you suggest we medically validate and police applications?
I've seen that approach taken and it's also a hot mess. It presents barriers not just for people defrauding the system, but the disabled that struggle to navigate the system as well.
I don't know the solution to these issues and it's one of the reasons I got the fuck out of social work as soon as I could.
One example could be that an interviewee inappropriately stares at a woman or makes an inappropriate remark while on-campus. You wouldn't see that if the entire interview were conducted only via Google Docs.
How many interviews pass or fail because of that situation vs failing because of running out of time? 0
Males and females will apply. Holding back women because you fear men will look the wrong way seems unfair and needless.
I assume most of those types of people are probably able to be on best behaviour for a day. I imagine most of them can pass an interview and then be creepy later.