4 ms·

Out of curiosity, did you ever figure out the disconnect that caused: > Excellent interview to turn into > couldn't even handle explorer.exe. I had to deal

Out of curiosity, did you ever figure out the disconnect that caused: > Excellent interview to turn into > couldn't even handle explorer.exe. I had to deal with a similar situation. The size and scale of my employer at the time meant the employee stuck around for multiple years. They never got worse but sure never got better. In our case, the problem was that our interview questions were based on algorithmic knowledge with some OS fundamentals. This person happened to be really good at those types of problems. But ask them to change a few lines of Python or Javascript and they just could not figure it out. So the underlying flaw was assuming that anyone who could figure out algorithmic optimization in C++ (psuedo-code, we weren't looking for perfect syntax) under interview pressure would also figure out higher level languages, test frameworks, CI systems, etc, in an efficient fashion. My simple solution was to push for a more diverse set of interview questions and interviewers. Actually, a "take home" style problem might have fleshed out these weaknesses but that was too radical, relative to the company culture, to even propose.

rl1987 2y ago
Exactly the problem with whiteboarding and the likes of Leetcode being so widespread. If getting a job becomes a complex skillset on its own largely disjoint from actual realities of day-to-day work you don't select the person best at doing the job - you select the person best at doing interviews. Ironically speaking, the person in question could handle all the interviews with new candidates if he's so good at interviewing.
brunoarueira 2y ago
My experience, mainly because when I was hiring through hunters and they participate on interviews, was to not take pre formulated questions and have questions based on the candidate resume, therefore I stress some points depending on the role.
koonsolo 2y ago
I also had this problem with hiring a front-end developer. Someone was really good at the theory, but practically couldn't handle himself. I currently do a job interview where we start from a super easy app, and then I ask "how would you add feature X", then I go to the next (predefined) step. The challenge of the test is that we run into certain problems. Some senior devs can foresee them, but most don't. Then the question comes "Why isn't this working and how to fix it". I've done a crazy amount of interviews already, and this kind of job interview gives me the most confidence. I didn't have any false positives anymore. You could see the test as "There is this junior that is stuck on something, can you help him out". I want my candidates to be able to deal with the weird shit, and in the end that requires a proper understanding of the underlying technology. I don't like "take home" assignments, because you never know that someone's software dev spouse is sitting besides them. We have a HackerRank test to first filter out the worst, and next stage is this interview I described. We use the same for both juniors and seniors.
bob1029 2y ago
Our flaw was similar. We were asking high level questions. At no point did we ask things like "have you ever used Microsoft Windows" or "have you ever used a desktop computer". It would seem we cannot take these questions for granted anymore. The best strategy I've come up with is to build an intern program and source talent from that lower cost/risk pool. Pulling high level employees off the street was almost always a circus for us.
- pavel_lishin 2y ago
  We had an apprenticeship/internship program, and it worked out great. It gave new grads (from both colleges and bootcamps) on-the-job experience as well as active mentorship, it gave us an extended but time-limited way to verify that these folks were actually good at their job, and for the most part, they were all excellent software engineers, and we extended offers to something like 75% of them, and 50% of those accepted and worked there for awhile before moving on to another company. imo, a very worthwhile investment of time and money.
  - BrandoElFollito 2y ago
    This is my favorite way of hiring (in France). You have all your time to get to know the employee and the employee has all the time to get to know the company. It usually brings excellent people for long, no surprises.
- anthomtb 2y ago
  > build an intern program I agree this is the best way to hire. Additional benefits are the chance to work on greenfield problems for low cost and creating leadership opportunities for folks with a couple years of experience. The only downside I have seen with the intern-to-FTE path is a tendency to leave after a few years as an FTE. I never ran numbers, and didn't have the god-power to get the data anyways, but would guess that half the interns who came on as FTE's were gone within 5 years. It would have been particularly interesting to compare intern->FTE tenure versus college grad->FTE tenure. Thinking about it more, moving on after a few years of productive work is not that much of a downside. Much better than not moving on after years of non-productive "work".
aPoCoMiLogin 2y ago
at my $work we are doing hires in 2 phases, first is mostly talk, and second is "trial day". on the "trial day", the candidate gets simple task (with few requirements and optional bonus points), that we could manage to do in 1/2 or 1/3 time that the candidate gets. the task has to solve something similar that we were working on, so that we test how the candidate perform in real scenario. in the past few years it worked quite nicely but that still is not bullet proof. and we had to refine our methodology further. for example one candidate solved the task perfectly, but on the end of the "trial day" the candidate was unable to answer some of our questions regarding his code. so we think that he had access to the task details upfront, or someone else helped; another example was with candidate that solved the task, answered our questions, but in the office was lacking everything that he presented to us in the "trial day". we suspect that the relative of the candidate helped here, as we found later that the relative has job in similar position in another company. so the "trail day" is good way to test candidate, unless he has early access to the details of the task, or relative is helping with the task. it sorted a lot of candidates that were unable to follow the task details, or worse lacked team working skills
- ok_dad 2y ago
  As long as you pay for the trial day. Otherwise, that’s hilariously entitled of your company to ask.

rl1987 2y ago

Exactly the problem with whiteboarding and the likes of Leetcode being so widespread. If getting a job becomes a complex skillset on its own largely disjoint from actual realities of day-to-day work you don't select the person best at doing the job - you select the person best at doing interviews. Ironically speaking, the person in question could handle all the interviews with new candidates if he's so good at interviewing.

brunoarueira 2y ago

My experience, mainly because when I was hiring through hunters and they participate on interviews, was to not take pre formulated questions and have questions based on the candidate resume, therefore I stress some points depending on the role.

koonsolo 2y ago

I also had this problem with hiring a front-end developer. Someone was really good at the theory, but practically couldn't handle himself. I currently do a job interview where we start from a super easy app, and then I ask "how would you add feature X", then I go to the next (predefined) step. The challenge of the test is that we run into certain problems. Some senior devs can foresee them, but most don't. Then the question comes "Why isn't this working and how to fix it". I've done a crazy amount of interviews already, and this kind of job interview gives me the most confidence. I didn't have any false positives anymore. You could see the test as "There is this junior that is stuck on something, can you help him out". I want my candidates to be able to deal with the weird shit, and in the end that requires a proper understanding of the underlying technology. I don't like "take home" assignments, because you never know that someone's software dev spouse is sitting besides them. We have a HackerRank test to first filter out the worst, and next stage is this interview I described. We use the same for both juniors and seniors.

bob1029 2y ago

Our flaw was similar. We were asking high level questions. At no point did we ask things like "have you ever used Microsoft Windows" or "have you ever used a desktop computer". It would seem we cannot take these questions for granted anymore. The best strategy I've come up with is to build an intern program and source talent from that lower cost/risk pool. Pulling high level employees off the street was almost always a circus for us.

pavel_lishin 2y ago
We had an apprenticeship/internship program, and it worked out great. It gave new grads (from both colleges and bootcamps) on-the-job experience as well as active mentorship, it gave us an extended but time-limited way to verify that these folks were actually good at their job, and for the most part, they were all excellent software engineers, and we extended offers to something like 75% of them, and 50% of those accepted and worked there for awhile before moving on to another company. imo, a very worthwhile investment of time and money.
- BrandoElFollito 2y ago
  This is my favorite way of hiring (in France). You have all your time to get to know the employee and the employee has all the time to get to know the company. It usually brings excellent people for long, no surprises.
anthomtb 2y ago
> build an intern program I agree this is the best way to hire. Additional benefits are the chance to work on greenfield problems for low cost and creating leadership opportunities for folks with a couple years of experience. The only downside I have seen with the intern-to-FTE path is a tendency to leave after a few years as an FTE. I never ran numbers, and didn't have the god-power to get the data anyways, but would guess that half the interns who came on as FTE's were gone within 5 years. It would have been particularly interesting to compare intern->FTE tenure versus college grad->FTE tenure. Thinking about it more, moving on after a few years of productive work is not that much of a downside. Much better than not moving on after years of non-productive "work".

aPoCoMiLogin 2y ago

at my $work we are doing hires in 2 phases, first is mostly talk, and second is "trial day". on the "trial day", the candidate gets simple task (with few requirements and optional bonus points), that we could manage to do in 1/2 or 1/3 time that the candidate gets. the task has to solve something similar that we were working on, so that we test how the candidate perform in real scenario. in the past few years it worked quite nicely but that still is not bullet proof. and we had to refine our methodology further. for example one candidate solved the task perfectly, but on the end of the "trial day" the candidate was unable to answer some of our questions regarding his code. so we think that he had access to the task details upfront, or someone else helped; another example was with candidate that solved the task, answered our questions, but in the office was lacking everything that he presented to us in the "trial day". we suspect that the relative of the candidate helped here, as we found later that the relative has job in similar position in another company. so the "trail day" is good way to test candidate, unless he has early access to the details of the task, or relative is helping with the task. it sorted a lot of candidates that were unable to follow the task details, or worse lacked team working skills

ok_dad 2y ago
As long as you pay for the trial day. Otherwise, that’s hilariously entitled of your company to ask.