3 ms·

We had one of these. Excellent interview, couldn't even handle explorer.exe on the other side. We fired them within the week. No one felt bad about it. Just do

We had one of these. Excellent interview, couldn't even handle explorer.exe on the other side. We fired them within the week. No one felt bad about it. Just do it and move on. The longer you drag it out, the worse it will get.

laborcontract 2y ago
Yes. The training effort shouldn’t be spent on the new hire, it should be spent on improving the hiring process.
- soheiljs 2y ago
  [dead]
codegeek 2y ago
The only correct answer in this situation.
brunoarueira 2y ago
Couldn't agree more! I, personally, hired some devs which are good in a specific tech stack, but struggle to learn the stack which the company was using , keeping demands too much from themselves and I trying to teach them, doing pair programmings and they fired themselves! So, after this two cases, I tried to filter even more and had good new hires.
anthomtb 2y ago
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.

laborcontract 2y ago

Yes. The training effort shouldn’t be spent on the new hire, it should be spent on improving the hiring process.

soheiljs 2y ago
[dead]

codegeek 2y ago

The only correct answer in this situation.

brunoarueira 2y ago

Couldn't agree more! I, personally, hired some devs which are good in a specific tech stack, but struggle to learn the stack which the company was using , keeping demands too much from themselves and I trying to teach them, doing pair programmings and they fired themselves! So, after this two cases, I tried to filter even more and had good new hires.

anthomtb 2y ago

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.