3 ms·

ad 1.) yes, being a contributor doesn't automatically make you good programmer. But having 7 years of coding practice in several companies kinda does, because w

ad 1.) yes, being a contributor doesn't automatically make you good programmer. But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long? Yet these programming interviews are required even for them. Probation period is much much more telling about a programmer than the 15 minute coding task.

eitland 7y ago
> But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long? Several jobs in 7 years might very well imply several companies gave that person a chance and then gave up. I often got questions about that years ago, and it was completely reasonable, at one point I'd worked in 4 different positions in 5 years. (There were good reasons for it and I had good references so I just explained it and it was OK, but I can easily see why they asked.)
- trickstra 7y ago
  > gave that person a chance and then gave up. Nobody "gives a chance" for a year. Either the problems were discovered during the probation period, or they were not as bad. Definitely not so bad that you'd have any chance discovering it during the interview. Besides, this high fluctuation is quite normal in IT.
  - ThrowawayR2 7y ago
    You'd be surprised. A common scenario is that manager A hires a bad employee but doesn't want to admit their mistake. Then they move on to another position and the new manager B has to go through the lengthy PIP and termination process.
    - trickstra 7y ago
      Yes, but say 4 times in a row? And 3 times without discovering how bad the person is during the interview? That says something about the prediction power of an interview...
  - majkinetor 7y ago
    That is simply not true in my experience. Its very hard to know if somebody is valuable within 6m unless they are completely bonk or completely great and majority of people is somewhere in between. Most of the folks I personally ditched were working for company for about 1y. You still may not want to kick a person if he fails because you might recognize that he could be better at a different type of job (frontend -> automatic tests -> ci/cd ?). Notably, I didn't have success with this type of shifting so far but sample size is still small, maybe its just a failure bias. Nevertheless, in my mind this is the right thing to do, to offer another chance at something different, rather then kick people out on inability to adapt to particular problem space.
sklivvz1971 7y ago
Agreed, but they are not alternatives, they are both possible. Also, I was not referring to super hard questions that require practicing "cracking the coding interview" for a month before passing. I've had "popular" candidates that could not shuffle an array, find a substring within a string or do some other relatively simple task that requires the candidate to think a bit. The reality is that of course, people with seven years experience should not need to do such tests, but in practice, there are many candidates with such prerequisites that can't even code anything. How they get the seven years, is beyond me. All I know is that they can't code.

eitland 7y ago

> But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long? Several jobs in 7 years might very well imply several companies gave that person a chance and then gave up. I often got questions about that years ago, and it was completely reasonable, at one point I'd worked in 4 different positions in 5 years. (There were good reasons for it and I had good references so I just explained it and it was OK, but I can easily see why they asked.)

trickstra 7y ago
> gave that person a chance and then gave up. Nobody "gives a chance" for a year. Either the problems were discovered during the probation period, or they were not as bad. Definitely not so bad that you'd have any chance discovering it during the interview. Besides, this high fluctuation is quite normal in IT.
- ThrowawayR2 7y ago
  You'd be surprised. A common scenario is that manager A hires a bad employee but doesn't want to admit their mistake. Then they move on to another position and the new manager B has to go through the lengthy PIP and termination process.
  - trickstra 7y ago
    Yes, but say 4 times in a row? And 3 times without discovering how bad the person is during the interview? That says something about the prediction power of an interview...
- majkinetor 7y ago
  That is simply not true in my experience. Its very hard to know if somebody is valuable within 6m unless they are completely bonk or completely great and majority of people is somewhere in between. Most of the folks I personally ditched were working for company for about 1y. You still may not want to kick a person if he fails because you might recognize that he could be better at a different type of job (frontend -> automatic tests -> ci/cd ?). Notably, I didn't have success with this type of shifting so far but sample size is still small, maybe its just a failure bias. Nevertheless, in my mind this is the right thing to do, to offer another chance at something different, rather then kick people out on inability to adapt to particular problem space.

sklivvz1971 7y ago

Agreed, but they are not alternatives, they are both possible. Also, I was not referring to super hard questions that require practicing "cracking the coding interview" for a month before passing. I've had "popular" candidates that could not shuffle an array, find a substring within a string or do some other relatively simple task that requires the candidate to think a bit. The reality is that of course, people with seven years experience should not need to do such tests, but in practice, there are many candidates with such prerequisites that can't even code anything. How they get the seven years, is beyond me. All I know is that they can't code.