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?
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.
It's always hard to let someone go, especially in a small company with a focus on personal development and a positive work environment. However, if you don't address this situation:
1) The morale of the company will likely decrease.
2) The productivity of the team will suffer.
3) Employees may start questioning the leadership's decisions.
4) Some may consider leaving as a result.
One of the most cost effective and humane things you can do is extend their health benefits out further than their monetary severance. For example, a month's pay with 2-3 months health benefits.
At least in cases where I've had to let people go, I've found they appreciate an approach like this. It's a relatively easy way to thread the needle between human dignity and corporate finance demands. A rarity.
Evaluate the hiring process, how did you mess up so bad? Fix it.
I'm assuming you don't have an HR department because why on earth would you be handling this and asking the internet if you did (LARPing aside), but if you want to go through the motions, notify them of their under-performance, ask them what resources they need to perform to the expectation of the role as applied for (which you also make clear and document), bring that to whomever for approval, and then set progress improvement checkpoints every week to see where they're at. This could be training, additional staff support, consulting, etc. Give the employee a week to decide and put together their proposal.
If they don't get the picture and start applying elsewhere while they're still employed, then evaluate them per the agreed timeline or, if the resources aren't approved and the project can't be delegated, go ahead and terminate their employment.
Otherwise, and this is more mature, better, kinder way to handle it, just let them know they weren't a good fit, don't apologize but do offer them a generous severance, and let them go. Or if you want, you can hire me for a day, and I'll do it.
Your blaming the wrong guy. The elephant in the room is that your interview process massively fucked up, and you failed to understand the most basic question of this process: junior or senior.
For example: I was hired by a company as a developer, and they loved me, I was very productive there. But just a few months into the employment, a competing company offered me a much higher salary with a much shorter commute. I went to my manager and told him all about the offer, and asked him what he would do in my shoes. He said he'd take the other offer (since he knew that a competitive counter-offer was impossible). I took the offer, and we parted on very good terms.
So you may be able to say something like this to this employee: "There seems to have been a misunderstanding about our expectations and your experience. We thought you had more experience relevant for this role. We don't want to leave you high and dry, but the current arrangement isn't tenable. Would you prefer to restart as a junior developer and work your way back up as you gain experience, or do you feel it would be better to part ways?"
Though now that I've typed it out, I'm not sure the strategy works as well when the one instigating the conversation has more power than the person being asked. Hmm. I'll post this in spite of my self doubt, just in case someone replies with interesting insights. I'm happy to be wrong if I learn something.
Critically, discuss your options and intentions with HR. It can get messy for everyone if you don't approach dismissal in the right way.
I can't tell from the description whether the candidate was outright deceptive, like claiming experience they didn't have, or candidate was just good at the normal interviewing rituals, and the real problem was mess-up on company's end (i.e., interviewers said "mediocre" but HR somehow heard "hire at all costs").
In any case, talk with appropriate management and HR -- with everyone clear on what the cause of the hiring mistake was -- and figure out what the acceptable options are.
Then, if the candidate seemed to be dealing in good faith, then probably talk with the employee, candidly, about the problem, and what options you're presenting.
If they're leaving, you can assist to do it in a gentle way. You might not have to assist much; they might hear it's not working out, and start job-hunting urgently.
If they're staying but downleveled, you can probably figure out the details to do it in a sufficiently non-awkward, discreet way. If employees noticed a bad-performer, they might be relieved to see that corrected, but hopefully they can also see the sympathetic and constructive way it was done, and adopt that tone themselves.
But, if the candidate wasn't in good faith, then they helped make this an adversarial situation, so talk with HR, and maybe also legal counsel, about how to terminate promptly and with a minimum of drama.
You not saving the world or anything like that, so just syphoon as much of the idiots vcs moneys to normal people lives. That is the goal with start ups right?
Eventually the "senior" left the company himself, but it took 2 years. That was 2 years of frustration for everyone in the team because we felt it was so unfair when somebody got paid more than us but caused so many blocks because of their incompetency.
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.
Once you take into account not only the net negative you're getting from your recent hire, but the effect on other employees too, the rational decision is to let them go. Think of it this way: intrinsic motivation and good climate for everyone else means not having someone higher paid but clearly less competent on the team.
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.
It sucks to see an underperformer stick around and get lots of $$. It just tells your team that surrounding them with great people isn’t actually a priority.
It also sucks to be a person in this position feeling like you’re underperforming for the long term. Or feel on the precipice of being let go without it happening.
Gotta be OK being upfront with folks and ripping the bandaid off. It’s a day of feeling bummed on the team that’s better than months of team members feeling unmotivated.
I’ll also say this should be really rare and if it keeps happening you need to review your hiring practices, as that’s actually the root cause of people getting into your team that aren’t a good fit.
I liked to use GWC for all employees: - do they "get it"? - do they want it? - do they have the capacity to do it?
All three must be yes for a role to be a good fit.
It's nobody's fault; perhaps they -were- at a senior level at another org, but your definition of senior might be more aligned with the market.
Ultimately, it doesn't matter. Their capabilities do not match the requirements of the business. Take the emotion out and it's an easy decision.
There's a classic paper out there...
The Net Negative Producing Programmer by G. Gordon Schulmey
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
(The early 60s may be a reference to (from https://news.ycombinator.com/item?id=421858 )
> Gordon Bell, architect of the DEC VAX wrote "High Tech Ventures" and included this section on NNP's
Negative Productivity is a principle that I claim is worthy of a Nobel Prize.
Normal principles of productivity assume that workers create positive output.
Brooks refined the concept of software productivity to express it in terms of
the "mythical man month," and in software engineering, it is understood that
different programmers vary in their productivity by several orders of magnitude.
According to the principal of negative productivity, it is possible for an individual
to produce bad results that others must then redo; hence, someone who is
very negatively productive can keep a whole team busy with damage control,
preventing the team from producing any output whatsoever.
And here it is discussed at C2 - https://wiki.c2.com/?NetNegativeProducingProgrammer
I've been in this position before and the hire dragged down team productivity for almost a year as we struggled to find something that he was competent at. Wasted untold hours assigning other skilled devs to help him because we were sure that all he needed was a "bit more guidance."
After 9 months of this, our manager finally bit the bullet and he had to go. In nine months, we could not find a single task that he could be trusted to do and he had shown no improvement in that time.
Learn from our mistake!
Secondly, while your process might be biased or “broken” this is a situation where someone got through when they shouldnt have. Some people are slow to ramp up but others just wont ever do it. Ive hired former Google engineers who ended up being in this exact same situation. It cracked my brain to have to do it, but letting them go was better for everyone.
1. The team already knows theyre underperforming. If they know the titles and that salaries are banded to titles then they’ll easily infer they’re getting less than this person.
2. Values around personal development, motivation are noble but you can improve from all sorts of starting conditions. I believe in a growth minded environment but also that its not everyones job to invest in people. Some people just dont have it.
3. You can rescue it by thoughtfully letting them go. By adjusting your hiring process to avoid false positives (at the expense of some false negatives) and by talking to the team if it’s required.
It sucks. Its never easy but its the kindest thing to do for you, for them, and for the team.
Is the poster a hiring manager who takes staffing problems to an internet forum instead of HR?
Is the poster someone else on the team hoping to generate responses on HN to try to coerce management into taking action?
The story is very one-sided and negative. How much of it is missing? How much is even true?
I've been at the opposite end of the spectrum at companies where the CTO wants a perfect team, and fired employees that weren't perfect or made (what we considered) reconcilable mistakes. We were all stressed out that we would be next on the chopping block.
Your team members want to work with other great people who can help them deliver success - after all, the feeling of success is one of the most rewarding things a job can give you.
I’ll also add that letting someone go (constructively) can be a net positive for them, if you can put them on a path for greater success in life elsewhere. Struggling to deliver for months or even years is also not a good use of their time.
It might feel harsh, and it’s definitely a very difficult conversation to have, but I think if you remember that your responsibility is towards the team as a whole it can help you emotionally accept and navigate the situation.
No. Let them go and move on. This is the problem with title inflation and it happens all the time.
How did you evaluate this candidate for this role exactly?
Some candidates are great at acing the interviews (since 90% of the time it is measured on predictable leetcode puzzles) but as soon as the real work begins, the new hire lacks basic skills, asks for too much help on issues that can be solved by 5 second googling or they take extremely long on simple tasks.
If you used Leetcode and yet this was the result, then perhaps you might need to find another way of evaluating actual 'senior' hires.
A wrong hire is worse than no hire. Not only the money is spent but time is also wasted and will be wasted further by training.
If HR hired the person despite a mediocre rating then they're the ones that need to be sacked.
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.
No.
"Or should we make this (perhaps justifiably, after their misleading self-presentation) the first time we let someone go for performance reasons?"
You need to let them go. Whether you call it performance reason or not is your call. You made a mistake hiring the wrong person. It is your fault. But you need to correct it by letting them go.
Doesn't matter whether you are a small team or large. Wrong hire is a wrong hire and things won't magically change just because you wish to. Fix the problem now and go back to hiring mode. Thank me later. Been there many times.
They're not fit for the role, and to boot, they misrepresented themselves. Your process screwed up, but the key is to not compound that. I'd encourage you to still be decent and give a good severance, because this is ultimately your company's fuck up, and you should take your medicine.
Fire away and move on.
Time you dedicate asking around is wasted money for your company.
Learn from your mistakes and try to avoid a bad hire in the future.
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.
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.
Though, it would be a shame to not transfer them to sales or marketing, they sound very talented at that, at the very least.
Question: how does that "helping others" look like? In companies there's a planning phase with meetings, the work phase with assigned tickets - how does the helping fits in? Is it in those cases when somebody asks about features - unknown to him - in the codebase which somebody else knows about?
You need to do the same thing with all of the employees involved in the hiring process, or get them out of the hiring process if that isn't their primary role and they are otherwise competent.
That cuts both ways, of course -- while I have only seen one person who "failed" their probationary period, I have myself left a job during my probationary period when it turned out to not be what I'd been promised. That's what the probationary period is for.
You could put them on a project by themselves, with expectations on par with other senior devs. Let them provide you with the evidence you need to make your case.
* They still have an up-to-date resume
* They may still have warm leads for other jobs
* Employment with you is probably short enough, they can just leave it off their resume entirely
I’ve learned that peers often won’t say what needs to be said even if it impacts the team, but they will expect leads and managers to pick-up on the problem and handle it all the same.
sales / executive track
It helps both sides.
Have you considered giving them a role as a sales engineer instead of as a developer?
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.
This is cool and all, but company culture is a two way street. Presumably you have this focus because you expect that employees appreciate it and in return are happier, more resilient and ultimately more productive because of it. But you can’t have this with someone who misrepresented themselves from the moment they walked in.
Consider also how this looks for other employees. They were hired for a job, do it well and in return got a great employer who cares about their wellbeing. But if you keep this person on, then you devalue the effort everyone else puts in, because apparently you can just lie on your resume and get the same great treatment as everyone else without any consequences.
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.
How is having having good negotiating skills and being well-prepared considered misleading self-representation?
> We probably can't reduce the salary, so more productive devs might also be offended if they become aware of it.
So you're telling me you'd be the first manager in history who noticed someone's lacking in experience before your team members do? I think not. You're also giving away the possible fact that there might be enough of a disparity between the pay of a new hire and a (company) senior that the current employees might get upset.
> 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.
How would you know? If you just hired them, you don't know, and obviously your hiring process doesn't work, so, again, you know nothing.
The fact firing is even an option, when you fucked up, and that this situation is even a thing, is telling me you're obviously oblivious to what "culture" you actually have.
Then again...
> It would probably take another 6-12 months of intense training to get them somewhat productive
Have you already spent 6-12 months of intense training on them? Then fire.
One way that breakdowns can happen is if people are too subtle in their reviews. For example, damning with faint praise, or being overly constructive. Lots of people aren't good at reading comprehension, and even less good when wading through the piles of communication noise that many companies tend to generate. Combining free-form text with unambiguous "multiple-choice" options on the interview reports can help (e.g., interviewer writes constructive things about growth potential, but clicks the "lukewarm" or "not for this role" radio button).
Another way is if different interviewers had very different impressions, and one interviewer's takes precedence. (This can also happen the other direction: false-negative. As a team lead, I gave a very strong recommendation to hire this one very determined designer-y frontend engineer. But another team lead, who would have temporary loan of the hire before my team's project spun up, proceeded to Leetcode-haze them. I wouldn't say the candidate bombed it, but rather that the company bombed it. The company really didn't want to hire someone who got a strong negative, so they said no. Rejected candidate instead went to a different super-cool engineering-driven company, and I soon saw them featured in a tech demo video of that company on LinkedIn, explaining to customers this neat new product thing they built.)
Other ways?
Also, this was HR's mistake, so give them in no uncertain terms your decision to let this person go, and let them handle the rest.
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.
My recommendation would, for his sake and yours, to let him go sooner rather than later. Working in the wrong position is also going to tank his self confidence and will do him no favours.
Really? You want low turnover in people who lie to you in the interview and are a drag on the rest of the team?
That’s exactly how you get high turnover from the good-fit people.
You need to provide feedback for your employee. Have a frank discussion about their performance and try and find out what is the actual problem. Assuming there has been little to no actual conversations, it seems you are merely projecting various ailments here. Maybe their cat died, maybe whatever. We simply do not know.
To your face they are worried and "what will we do, oh no what a mistake we all made", behind your back they think you are suckers (and based on your post they are probably correct).
The bar is really, really low. You will have to step over it however.