5 ms·

A few more things: 1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show the

by sklivvz1971 7y ago

A few more things: 1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show them how good you are at coding Ruby). Many people with creds get offended when they realize they are not as good as their credentials would imply. 2) Know yourself. Most candidates I've seen, including myself, encounter a moment in the interview where they get hit by the nerves. Know that it's going to happen, announce it to the interviewer, recompose yourself, start again when calmer. You are not going to fail an interview because you are nervous. You will not succeed if you are terrified, panic, and shut up. 3) Explain your reasoning. The way you approach a problem, which is a large part of what the interviewer wants to see is in your mind only unless you vocalize it. With a good enough mental approach, you will get a lot of slack on the actual code by most interviewers. 4) Interview your interviewer. Go prepared with smart, non-trivial questions on the job and the company. Ensure your interviewer is an empathic, intelligent, and humble person. Assume anything annoying you experience is going to be relatively permanent at the job -- will that be acceptable or not?

trickstra 7y ago
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.
photonios 7y ago
#1 does not make always sense to me. Open-source authors and contributors have their work out in the open. You can see their work, the way they interact with others online. Would you reject Guido van Rossum if he can't solve your whiteboard problem? Assuming he's suited for the job, his work speaks for itself.
- izacus 7y ago
  But that's exactly the thing - just because Guido did some project it doesn't automatically mean he has the skills for the job you're hiring for. Especially if you're interviewing people who aren't Guido (most of them aren't!) but are more local celebrity level contributor - being a contributor to something doesn't always give transferrable skills. And people lie on their resumes all the time. It's amazing how many outright lies we've caught when interviewing people (even those with "streed cred").
  - clarry 7y ago
    And just because someone solved (or didn't) a whiteboard puzzle doesn't mean they have (or don't have) the skills for the job you're hiring for. I would argue that actual working code out in the open speaks more than a puzzle solving session.

trickstra 7y ago

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.

photonios 7y ago

#1 does not make always sense to me. Open-source authors and contributors have their work out in the open. You can see their work, the way they interact with others online. Would you reject Guido van Rossum if he can't solve your whiteboard problem? Assuming he's suited for the job, his work speaks for itself.

izacus 7y ago
But that's exactly the thing - just because Guido did some project it doesn't automatically mean he has the skills for the job you're hiring for. Especially if you're interviewing people who aren't Guido (most of them aren't!) but are more local celebrity level contributor - being a contributor to something doesn't always give transferrable skills. And people lie on their resumes all the time. It's amazing how many outright lies we've caught when interviewing people (even those with "streed cred").
- clarry 7y ago
  And just because someone solved (or didn't) a whiteboard puzzle doesn't mean they have (or don't have) the skills for the job you're hiring for. I would argue that actual working code out in the open speaks more than a puzzle solving session.