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.
> 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.
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.
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.
imo, a very worthwhile investment of time and money.
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".
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
Ironically speaking, the person in question could handle all the interviews with new candidates if he's so good at interviewing.