5 ms·

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), divide

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?

projectazorian 5y ago
Might be relevant if the person's job is to answer interview questions all day, but in practice this is hardly ever the case.
hunter2_ 5y ago
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.
maininformer 5y ago
Not that simple. Time is usually a quarter not an hour. The amount of work is intermingled with value, perceived or actual.
- dolni 5y ago
  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.
  - Twisol 5y ago
    > 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 https://en.wikipedia.org/wiki/Sorites_paradox
    - dolni 5y ago
      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.
klyrs 5y ago
> 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.
- Zababa 5y ago
  > 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.
avianlyric 5y ago
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.

projectazorian 5y ago

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

hunter2_ 5y ago

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.

maininformer 5y ago

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

dolni 5y ago
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.
- Twisol 5y ago
  > 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 https://en.wikipedia.org/wiki/Sorites_paradox
  - dolni 5y ago
    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.

klyrs 5y ago

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

Zababa 5y ago
> 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.

avianlyric 5y ago

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.