4 ms·

Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out o

by Taek 6y ago

Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out of you, we need some way before we hire you to understand what type of output we can expect. The best way I know would be to work with someone for a week or two on a real problem, but that's way too expensive to trial a junior role. At least for us, the system is more optimized around avoiding false positives than ensuring we don't pass over someone good.

sushshshsh 6y ago
Your current system is better. I'm happy to take 15 minutes of my life to prepare for your interview instead of 1 week. Since the denial rate in our industry is so high, you can see which one is more preferable.
Yajirobe 6y ago
Programming in an interview environment is completely different from programming at your 9-5 desk.
- recursive 6y ago
  Everything else in an interview is also completely different from 9-5 engineering.
  - tchaffee 6y ago
    Due to a lack of imagination and people who don't host interviews on a regular basis so they never put in the effort to get good at it. When I conduct a technical interview we are going to end up doing some stuff you do in your 9-5. And you probably won't even notice it. And if there is a budget available for it, I'm going to pay you to do a very small coding assignment. A few hours. Almost exactly your 9-5.
    - recursive 6y ago
      The fundamental difference is that a job is directly at stake based on your performance. For many people, this makes them more nervous than they would ever generally be during work. Due to the nature of interviews, I don't think there's really a way for it to be otherwise.
nogabebop23 6y ago
>> The best way I know would be to work with someone for a week or two on a real problem, So if I get the job will we just touch base ever week or so? This sounds unlikely. Why can't you break work down to the point that you can pay me for 3-4 hours of real output and then use that to evaluate my quality? All these tests around recursion and linked lists, etc are a feel-good proxy for actually measuring suitability, If someone is actually implementing them (IF!) it's not the junior, new-person; it's the senior architect who does it once every few years in a shared library. I can count the number of times I've used recursion in (a) a non-toy implementation and (b) not ripped it out and replaced with a faster, clearer iterative implementation on one hand.

by Taek 6y ago

sushshshsh 6y ago

Your current system is better. I'm happy to take 15 minutes of my life to prepare for your interview instead of 1 week. Since the denial rate in our industry is so high, you can see which one is more preferable.

Yajirobe 6y ago

Programming in an interview environment is completely different from programming at your 9-5 desk.

recursive 6y ago
Everything else in an interview is also completely different from 9-5 engineering.
- tchaffee 6y ago
  Due to a lack of imagination and people who don't host interviews on a regular basis so they never put in the effort to get good at it. When I conduct a technical interview we are going to end up doing some stuff you do in your 9-5. And you probably won't even notice it. And if there is a budget available for it, I'm going to pay you to do a very small coding assignment. A few hours. Almost exactly your 9-5.
  - recursive 6y ago
    The fundamental difference is that a job is directly at stake based on your performance. For many people, this makes them more nervous than they would ever generally be during work. Due to the nature of interviews, I don't think there's really a way for it to be otherwise.

nogabebop23 6y ago

>> The best way I know would be to work with someone for a week or two on a real problem, So if I get the job will we just touch base ever week or so? This sounds unlikely. Why can't you break work down to the point that you can pay me for 3-4 hours of real output and then use that to evaluate my quality? All these tests around recursion and linked lists, etc are a feel-good proxy for actually measuring suitability, If someone is actually implementing them (IF!) it's not the junior, new-person; it's the senior architect who does it once every few years in a shared library. I can count the number of times I've used recursion in (a) a non-toy implementation and (b) not ripped it out and replaced with a faster, clearer iterative implementation on one hand.