Comment by avianlyric | Hacker News Reader

Comment by avianlyric | Hacker News Reader

Parent Full thread

Your making the assumption that the accommodations are meant to provide some sort of “advantage” to compensate for some other “disadvantage”. Like dealing with disabilities is some sort of arithmetic problem.

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.

Do you have an example of a question or interview process that you think fits your description? I think a standard tech-company interview has a lot of time pressure, and providing more time would help many candidates considerably.

> I think a standard tech-company interview has a lot of time pressure, and providing more time would help many candidates considerably.

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

That's a ridiculous comparison.

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.

Well, internal deadlines can be adjusted and accommodations can be requested for external deadlines, right? It would be kinda unfair if one's own workplace had to absorb any negative externalities of one's accommodations. That doesn't make sense. Customers aren't immune to the ADA.

Deadlines across hours or days are very different than deadlines across minutes. Many strategies like going for a walk can help you solve difficult problems, but that’s not an option on a 1 minute per question interview.

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.

> that’s not an option on a 1 minute per question interview.

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.

It doesn’t matter the percentage of time devoted to short term problem solving. If it’s a requirement for applicants to go through that process successfully then it’s a requirement to get the job.

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

> Sometimes, stuff breaks and wouldn't it be great if it got fixed in half an hour instead of four hours?

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)

There is time pressure, but you are also not expected to come up with a perfect, flawless solution. That is often not even interesting. The point of a good interview question is to see how a candidate works through a problem, not to see if they know the answer to an arbitrary quiz question.

Giving more time doesn't give you an advantage, because the correct answer isn't what gets you points.

I don't know why you would want to make time pressure a feature in your interview process. Normally it only happens because there's a fixed number of questions that people want to ask, but they're unprepared to allocate more an a hour to do so.

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.

If I allocate more time to each interview question, then how am I supposed to judge between a candidate that completes it in half the allotted time vs one that completes it using all the time?

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.

If you want to use speed as a measure, then you can't avoid time pressure. But you don't need to use speed as a measure.

> If I allocate more time to each interview question, then how am I supposed to judge between a candidate that completes it in half the allotted time vs one that completes it using all the time?

How about you judge them on the quality of their answers? Is giving a long more detailed and nuanced answer a bad thing?

Why would time not be highly relevant to job performance? Productivity is defined as an amount of work output (whatever that is for the job in question), divided by time. So time is in fact central, and a team member who can do more in a unit of time should be more desirable, no?

Might be relevant if the person's job is to answer interview questions all day, but in practice this is hardly ever the case.

All else being equal, productivity might drop. But by hiring some less productive people as well, there are likely some non-productivity-related benefits to be enjoyed, such as broader brainstorming about how to make the product/service work well for a more diverse set of customers, and whatever value might be created by the morale boost (people generally like to do good) along the way.

Not that simple. Time is usually a quarter not an hour. The amount of work is intermingled with value, perceived or actual.

Of course it is that simple. A quarter is made up of a bunch of hours.

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.

> A quarter is made up of a bunch of hours.

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.

[0] https://en.wikipedia.org/wiki/Sorites_paradox

Well, you only quoted and responded to one part of my argument.

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

> Productivity is defined as an amount of work output (whatever that is for the job in question), divided by time.

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.

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

Why do you think that performance of an individual in a one hour interview is going to be representative of the average performance of the individual over a much longer period of time (months to years).

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.

> If you’re worried about people cheating by passing the questions around

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.

Reply on news.ycombinator.com