Ask HN: How to handle a senior hire turning out to be junior?
Essentially we had deficiencies in our technical interview that allowed for custom-fit preparation, the candidate excelled at selling themselves and negotiating, and there was a breakdown in internal communication where HR was under the impression we wanted to hire at any cost despite us giving the candidate a mediocre rating.
Now we've found they're struggling to do even basic stuff without help and are far from helping others or even taking ownership of minor areas.
They suffer from imposter syndrome (appropriately for once), which further hampers their productivity, communication, and growth as they're reluctant to ask for help with tasks they know should be easy, and equally reluctant to join the efforts of others who might notice their deficiencies.
The result is net-negative productivity. It would probably take another 6-12 months of intense training to get them somewhat productive, and several years to get them closer to the level we hired them at, assuming we can accelerate their learning.
This would require addressing the elephant in the room that they're not at the level we assumed, so that they will understand why we're changing the work mode, accept that learning should be a high priority, and feel permitted to seek more help when they need it. We probably can't reduce the salary, so more productive devs might also be offended if they become aware of it.
Even if we were to successfully address this elephant in the room, they might at some point realize they can't catch up to the level they were hired at without years of dedicated effort and thus quit or "quit internally", making our investment pointless.
I guess in most companies this would be a no-brainer, but we're a small outfit with a focus on personal development, intrinsic motivation, good climate, and low turnover.
Do you think there is any way to rescue this situation? Or should we make this (perhaps justifiably, after their misleading self-presentation) the first time we let someone go for performance reasons?
230 comments
[ 4.0 ms ] story [ 270 ms ] threadEvaluate the hiring process, how did you mess up so bad? Fix it.
I'd sit down with employee, and present options.
Start with: You're not performing at the level, technically or with leadership, that we were expecting. Some of this is our fault, for not figuring that out in the interview. So this is going to be an uncomfortable conversation...
Option A: We decide you aren't a good fit for this position, part ways, and we wish you good luck in your next opportunity.
Option B: We adjust your salary and title to fit with what we've seen of your productivity. We realize this is a hard ask. We also come up with a plan in which you have a training and responsibility plan over the next year to get you to what we'd expect for someone in your original role, at which time we'll consider you for promotion.
A lot of responses here start and end with firing, which seems kind of callous to the individual for an HR fuckup. Better to at least present the demotion option.
This can backfire, is this same training resource made available to the other devs in the team ? , are they being passed away for this promotion by guaranteeing it to the new entrant.
The original poster specifically said its a small tight knit personal community of devs, if they could self promote inside, they would have provided training to existing dev itself.
After demoting this person, they’ll need to hire a new senior dev, what’s the guarantee they will need 2 senior devs anytime soon ?
Guaranteeing a future promotion if training goals are met would be a disingenuous commitment and dangerous for team building if other existing devs are not given equal opportunity to compete for that promotion.
It would be even more complex.
If they're outright fired, that says something to the existing team too, and especially in smaller shops where each head holds valuable knowledge, I'm not sure that's the company-benefiting message to send either.
Plus if the individual chooses to leave, "I think we all noticed that so-and-so wasn't a good fit for the senior role. We extended them the opportunity to realign to a different level, which they declined" is a message I'd feel more comfortable presenting to the team.
"We're not going to immediately shitcan you..." is a powerful truth for retention in small teams/companies.
Especially coupled "... but we expect you to perform to your level, and we will address things if we see someone underperforming."
I do agree with other comments that do-nothing and ignoring the problem will be cancer to building a high-performing team.
It sounds more like legacy / messy systems with no dev/staging platform, or very bad documentation, or even a terrible onboarding process if you really need 9 months for someone to deploy code.
Linux Kernel development is a fairly organized C software, it is no different than working on Chromium or Unity, or like any other large codebase.
It used to be easy to get lost.
However now, for only $20 you have an expert coder, sitting by your side (and this is what ChatGPT does), then your learning curve is certainly reduced from the 6-9 months, which seems gigantic.
Simulations, number manipulations, data analysis, etc, you have, thanks to ChatGPT, turnkey code solutions.
It was tough, when you had no internet, no GitHub, no AI, no documentation, no Wikipedia, no StackOverflow sites, but now the barrier for entry to be productive is much lower.
If you need one year to start deliver one basic feature, and you have ChatGPT on your side, then it means the onboarding process is broken.
My question for you is -- what exactly do you do? What programming could you possibly be doing that is so trivial that you actually believe that ChatGPT is capable of solving these things?
Yes self-learning is better, but it takes a much longer period of time, whereas if you have a tutor, then it saves lot of time (and companies don't often have such resources, which is where AI and books fill the gap).
I strongly believe that LLMs are a serious helping tool for programming that helps programmers to onboard their project faster.
Regarding more exotic techs, as a cousin of ChatGPT, Google Gemini used to be very very bad, but with Gemini 1.5-Pro you can feed it very long documents, and this is super helpful for specific implementation (e.g. the exotic processors), and it's, really, really not bad at programming, or at least pushing you in the right direction.
Of course it's not autonomous (and whether it can be in the short-term on complex projects is unlikely), but it reduces the onboarding time, and this was the point raised in the conversation.
A dev paired with a LLM is much much more productive.
I suppose that you are concerned that it may push people to lose their jobs in the long-term. I am as well, but we still have some time ahead.
I don't like this situation either, but I have to recognize that it is a very helpful co-programming tool.
Reading the documentation is basically never the hard part. If it's where most of your work is going, you're not doing hard work. Gemini 1.5-Pro may be able to summarize documentation, but it's what isn't there that hurts you. It may make for a helpful reference, but that wasn't the initial claim. The claim was that "domain-specific knowledge can be solved with a $20 ChatGPT subscription", and being frank, that's just stupid. The difference between a smart person and a domain expert is orders of magnitude more than an LLM is able to paper over.
It's a struggle to replace even the most trivial paper pushing with an LLM. I'm sure we'll find something one day, but it's going to be doing a hell of a lot more than an LLM.
In my experience, usually some level of existing expertise is considered a prerequisite for senior dev positions.
* Although a whole year sounds really long for a senior dev to get going in any of those topic areas.
I moved to something entirely different and it took me less than a week to find something that is useful to contribute to on the side while I am trying to better understand the context and everything we are doing.
Being able to dive into different projects is, imho, a core skill for engineers and a good litmus test for seniority.
Most 4 year degrees aren't even sufficient, as they just teach academic knowledge and "hacking" skills (as in "hacking your grades") that produce juniors that leave a massive wake of technical debt unless checked.
But yes, 6mo could be enough to get a particular employee productive, assuming they are highly engaged (ideally not remote) and have someone available to train them every day, and so on.
In fact, I'd argue that for anyone that knows some programming and in good GPA standing, 3 months is good enough for being productive. He can work on minor stuffs starting from 3 months.
Turns out he wrote some of the worst code I've seen, and worse, was unreceptive to feedback.
Ended up firing him by the 3rd day.
> 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.
- a sheet of paper i found in a desk 20 years ago
It's probably fine to fire them, but also everyone involved should be open about the fact that the hiring and so also the firing is the direct result of their own failure. The morale implications of this could be lot more nuanced than you're implying.
Could they have also lied on the interview?
I would consider personality as a strong factor in keeping them, and if the company has room for a junior.
Lowering the salary is a hard requirement though.
Everyone lies on interviews. Especially interviewers.
I kept someone for too long once and people on an adjacent team didn’t want to get stuck with that person during a re-org and were vocal about it. And that person bungled some important projects that set us back years on our ambitions.
Fire them and use this as an opportunity to address your interview process. The longer you keep them the worse it will be.
You should be looking for the employee to be making good general efforts, just without taking everything into account yet. And the employee should see evidence that you are serious about helping them master specifics of their new environment.
But the way you handle it will also be observed. Others need to know you won’t just fire someone on the spot if performance doesn’t match expectations. Life happens, people have personal life issues that may occasionally require attention, and you don’t want everyone else assuming they are one bad sprint away from unemployment.
In most of the US at least, start with a performance improvement plan. Ideally one crafted with HR’s help. It should lay out specific expectations for a Senior Engineer, and call for immediate and sustained improvement. Use that to initiate a conversation and clearly lay out that they are not meeting expectations for the level at which they were hired. Present meeting those goals as a requirement for continued employment. You may also present a severance option here if you want them to have an out.
This makes it clear to everyone that you treat all employees with respect, offer a clear warning, and then so long as you expectations in the PIP are clear, it’s a lot cleaner if you end up needing to part ways a week or four weeks later.
If the individual doesn't have the skills (or seemingly temperament) for a senior role, I'm not sure PIP is setting them up for success.
Versus demotion with possibility of promotion allows them to perform at their level of competence, leaving open the possibility for them to chose (or not) to aim for promotion.
I think it’s easiest to cut the relationship and let them start clean somewhere else.
On top of that I’ve never seen anyone get through a PIP successfully (n=6).
Furthermore, it can also create a culture of just dismissing any candidates who don’t come from the right pedigree because the risk of a mishire is way too high.
Its worth asking if it’s worth your time to do this for the sake of following process. Larger companies that need to standardize management for hundreds of managers have a greater need than startups do.
It’s a warning shot, and sometimes it only lasts a week.
BigCo HR can definitely make it take months, but the practice in general doesn’t have to be that way. We did this at startup size as small as 20 people, and I never regretted it.
I don’t think they’re meant to succeed. If you want to keep an employee, you give them feedback and coach them. A PIP is used to document evidence that an employee is incompetent and is incapable of improving despite your best efforts, as a precursor to firing them.
I hate this rat race of being a performant engineer. The moment your performance declines, your managers will let you know and you’re under the radar now.
I don't think so. A company is under no obligation to handhold their employees. It should be a 2 way street, beneficial in both directions. If it's not beneficial for one party, they should be able to be honest about it and move in another direction. We're all adults here.
Why should I stay at your company as a junior engineer if the people I’m teaching things to are senior to me?
It devalues seniority and the general appearance of meritocracy in your organization to keep this person at senior. If you really want to be nice, give them the title and compensation that is appropriate for them. If you can’t do that, the right thing to do is to politely say it’s not a great fit for the role and let them go.
The other devs are going to be PISSED if they find out they're making less, and everything will start derailing.
There's loads of other good devs available instead.
I.e., what if you agreed to let them keep their current job title, but gave them the responsibilities and salary of a junior dev until the skill gap was closed?
Then (a) they have a way forward, (b) they avoid a career-limiting feature on their resume, and (c) you wouldn't be overpaying for their work.
That's the best balance of kindness and fairness I can think of at the moment.
The rest of us work and learn honestly for years if not decades. If an employer asked me about my skillsets, I would be honest about my experience and deficiencies and negotiate honestly from there, and make plans to address the weaknesses accordingly.
Finding a good dev fit for any given project or team is already hard enough when people are honest and well intentioned. We have no good credential system or standard way to suss out ability. It's how we get endless whiteboarding challenges and leetcode that isn't relevant to the actual job. Allowing charlatans into the mix just makes it worse for everyone, both employers and other employees and prospective employees.
It's one thing if this person came in honestly and needed some specific remediation, maybe a particular technology or domain knowledge or whatever, but were generally competent. But that doesn't sound like what happened here. They lied to get their foot in the door, abusing the company's family-like atmosphere. They'll just drag everyone else down.
Let them go and have a better hiring process next time. Ask your other employees for better ways to evaluate candidate ability if you need to. They are often better able to evaluate whether someone can do their job or lead them. But show them that you care about fairness, not charismatic lying ability.
You have to fire. No hiring process is 100%. It is worse to have them stay. If your organization is unable to fire people because you have 'not firing people' as an objective, you're optimizing for things that aren't advancing the business, and essentially shooting yourselves in the foot.
This is sort-of true. Employment law in the U.S. is by state, and there are only a handful of states that are truly at-will with no exceptions at all (and even in those there are federal exceptions for thew 'protected categories' - race, gender, sexual orientation, religion, national origin, disability that can be reasonably accommodated, etc.). Montana is not employment-at-will at all - you have a probationary period and can only be fired for cause there after that.
America has a thing called the 'Uniform Commercial Code' which is basically templates for business and employment law that states can voluntarily pick and choose from (Louisiana, where the law is based on French legal tradition, uses it the least). But even with the UCC there is actually a lot of variation in state laws on stuff like this.
In my experience outside of Montana having an explicit probationary period is rare in the U.S. You are seeing why in this thread. Your employer may be able to legally fire you at any time, but the social expectation is that they will get the hire right and not fire you for being a mismatch unless they absolutely have to.
At a large company they likely wouldn't recover from this situation either - but they have the financial and management resources to just sandbag him with the worst jobs until he quits, which I'm assuming you can't afford.
A good strategy would be to have them be a lead on a minor project that requires technical chops and communication. Ensure there is a daily standup and grind them on details and timelines. Get them some juniors as direct reports to expose their lack of knowledge, then have meetings with these junior devs about project performance.
The stress alone will probably make them quit. Document as much as you can in emails and messaging systems.
In most other countries you cannot fire people just for reasons like this.
In other countries people have to resort to backhanded ways like the parent comment mentioned if you want to get someone off the payroll.
If after several months you decide you no longer want them that's different, but if you hire someone, they're no good, you can fire them pretty easily, assuming you've specified the probationary period in the contract.
(country specific)
I agree, but a lot of things that are not allowed but happen frequently.
Doesnt matter what the law says is illegal, unless its enforced.
Im not saying its a good thing to resort to such toxic measures.
Parent comment said it is evil and should not be done, I just mentioned the reality that in most countries its one of the classical tried and tested method to bypass employment safety laws that almost rarely gets backlash.
I myself dislike such toxic behaviour, but just stating the reality of what happens.
> The stress alone will probably make them quit. Document as much as you can in emails and messaging systems.
My god, no. Unless you want to set a precedent for super-toxic, manipulative workplace environment. (You don't get to pick&choose when evil happens: "I learned it from watching you".) As well as expose the company to potentially an 8-figure harassment suit.
What is expensive in most European jurisdiction to fire a permanent contract after the initial trial period/first year contract without wrongdoing. But that is typically after a year or more.
The reason here is that they are trying to be a employer which focus on personell development. Which is contradictive to capitalism and obviously they have not figured out yet, how to deal with situations like this.
Capitalism doesnt have any 1 original author like Karl Marx, not everything can be made to fit in “capitalism” and villified.
The latest devices you’re writing code and comments on here with are devices powered by latest silicon fabrication tech made by teams of engineers on whose careers, companies greatly invested long term to get to this.
There are tons of capitalistic employers there who invest in their employees careers retain them and take their help to grow the company, even give them esops and stock options.
High skilled labour isnt a cogwheel readily available on the market churning out of colleges, they are trained, retained and further developed throughout their careers to bring value to business and build new products.
Capitalism isnt this great evil thing that wants to suck you dry and destroy you. It has perfectly healthy versions that give people a chance at Life, Liberty and the Pursuit of Happiness.
If someone's under-performing whilst in their probation period getting rid of them is incredibly easy. Outside of the probation period there's a bit more of a process, but it's still not particularly hard - all you actually need to be doing is documenting.
> It’s impossible to fire an employee for performance reason after the probation period in Germany.
This is untrue.
It's true that Kündigungsschutzgesetz does set a really high bar.
You can get rid of them if they aren't delivering on assigned tasks, but you need to show that they are able (and are therefore simply unwilling). There's also the possibility of doing it if there are personal reasons (i.e. something in their life has impacted their suitability for the role) but that's more complex.
That's why you see people get assigned easier tasks - they're being given tasks that are so noddy that anyone could do them (a failure to do so showing that they're not really trying).
But it's hard. The level they have to achieve is really low - something like 65% of a "normal" employee.
But Germany is just one country in Europe. Have a look at France, Italy, Belgium or even the UK - it's *nothing* like the level of stringency that Germany applies.
Do not do this. You do not need a “strategy”. Just do it! Rip off the band-aid. Either tell them the truth or give no reason even if asked. Reverse the mistake asap and get moving on your company’s mission. You don’t need one second more of this. Nor does anyone else at your organization. Do it today! Do it dispassionately. Do it as nicely as possible. You are going to feel bad because you are a good empathetic human.
Some people will have a reaction. Some people will “have a reaction” to try to get more out of you. You are not responsible for either. You are responsible only for your own actions. Figure out what you should give them to be fair and add a little extra so you are sure it isn’t unfair.
Plan what you will say and do in advance and have someone you trust with you in the meeting. Stick to your plan. Even the best hiring processes succeed only 50% of the time (though this goes beyond just a bad hire). Firing, and firing quickly is just as important as hiring well.
Also remember that if an applicant tailors to a hiring process to this extent, that’s not just a failure of the process. It’s dishonesty. Even if the applicant were competent, you absolutely don’t want to entertain someone dishonest in your company.
If they lied, fire them.
If they were honest during interview and their previous company salary, wasnt higher than your junior pay, give them an option for either demotion or resignation (with decent severance if you can afford to so that they have safety net to look for new jobs)
If you were going to hire someone junior too in the short term, then just demote this new dev to his real level.
If not, and you desperately need senior dev, make this current new dev resign or fire them.
Letting go of someone sucks, but offset that against upsetting your current good, hard-working team. The quicker you let this person go, the more easily they can pretend the job never happened on their CV.
Critically, discuss your options and intentions with HR. It can get messy for everyone if you don't approach dismissal in the right way.
The stories I keep hearing, about companies ghosting the applicant after 5-6 exhausting rounds of interviews, are scaring me, to be frank. It feels like the companies are optimizing towards not hiring as much as possible, and it's very tempting to optimize for passing the interview and make it into the primary skill...
Given the comments here, you don't have the couple months to unrust your skills. You will be deemed unfit after the first one and fired, the prevailing sentiment seems to be.
I guess it’s the same amount of time in other countries.
The going rate for firing without cause is about 1/3rd of a month of salary per year of employment for an employee under 55 (?) on a permanent contract. On a yearly contract this is difficult - I would recommend hiring on permanent contracts because they are even seen as a positive.
Demoting will mean that you overpay someone, but will at least clarify the new hierarchy to the team.
Second thing is: most of our countries have a more direct conversation style.
When I was in France it was quite jarring and imo, it seems like it would be more stressful than at will employment as it's basically a yearly stress (as opposed to stress only when the economy is bad for example). But I think some European countries have some protections for contractors too, I just don't know if those apply to when your contract just doesn't get renewed.
As a full-time employee of the company you're working for (i.e. not simply contracted in), you still have an employment contract (it's a right/required) which'll lay out the employment expectations (salary, hours per week, whether you can be required to work additional hours etc).
We do also have contractors - i.e. those who work for an external company who are brought in for a specific project (or to provide easy-to-get-rid-of headcount).
In my experience, working as a contractor isn't all that much more common than in the US. But people having some form of contract is, because basically all employees have one.