Ask HN: How to handle a senior hire turning out to be junior? | Hacker News Reader

Ask HN: How to handle a senior hire turning out to be junior?

127 pointsthrow94680732220 comments

We hired a developer at the senior level who is lacking basic skills.

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?

View on HN

As you consider the decision to let them go, consider the impact on other people in your work place too. Other developers notice someone like that underperforming and getting overpaid, and it can hurt the good climate you aim for. It may feel bad to fire them, but it may be worse to keep them.

>“The fastest way to demotivate a good employee is to show them the lengths you are willing to tolerate a bad employee”

- a sheet of paper i found in a desk 20 years ago

From this post there's not really any indication they're a "bad employee" though. They aren't up to the needs of the team that hired them, but that was on that team to figure out before they hired them.

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.

Well, not calling for help when needed makes them a very dangerous junior. I don't know by the post if they are a good person.

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.

> Could they have also lied on the interview?

Everyone lies on interviews. Especially interviewers.

This 100%. Whether I would fire someone depends on why I thought they were underperforming. You should consider the first month on the job a work sample and if someone isn’t measuring up within the first week tell them what your expectations are and that they’re not being met. If they don’t remediate within a month let them go.

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.

How do you reconcile this advice with the fact that in both places I've worked at, the expectation was that just the onboarding takes significant amount of time (up to ~0.5yr)? Even if I personally didn't need that much time, it was nice to know that it's available -it's not easy to get into the grind and catch up to others that already have all the institutional knowledge when starting a new job.

You shouldn’t need to be onboarded to basic development skills when you come in as a senior developer as the OP is saying here. Institutional knowledge specific to each company takes time to learn, but many dev skills should be directly transferable.

Be sure that half a year is thought through. I’ve seen places that pay too little attention to new employees in the first few months and then surprise them with complaints about performance. Those first few months should be drilling specific institutional knowledge (through bugs, presenting on parts of the stack, talking to a variety of people, shadowing, studying certain tech/tools most people don’t know.)

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.

You absolutely need to consider how the rest of the team will interpret you actions. Most probably know this individual is underperforming already. Teammates usually have a sense before the manager does.

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.

Do you have thoughts on offering PIP vs demotion and salary adjustment?

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 haven’t personally seen that work in practice. I’ve been in situations where we considered it, but people usually have picked a role with salary considerations in mind, and often can’t really walk that back, and if they do it’s demotivating. And they may be able to perform elsewhere in a way that meets the need at your senior comp level.

I think it’s easiest to cut the relationship and let them start clean somewhere else.

As a counter point to this, I’ve witnessed the practice of designing these processes to terminate someone creates a ton of burnout for the manager. Expect to spend at least 20% of your time managing the PIP. Documentation, one on ones, babying tickets being assigned, etc.

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 definitely not zero effort. But every time I’ve seen it draw out the timeline, it’s been because the expectations weren’t clear at hire time, nor in the PIP. You’re looking for a specific number of “significant PRs/week”, or story points, or something with subjectivity where you the manager still get to decide.

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’ve never seen anyone get through a PIP successfully (n=6).

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.

If I were working on that team, I wouldn’t like the company firing the senior dev. If they keep them, and train them, that would reinforce the idea that the company is taking care of its employees. That’s nice.

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.

> If they keep them, and train them, that would reinforce the idea that the company is taking care of its employees. That’s nice

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.

You are right in general, but in this case it is clear that the issue is not "guy has a tough break, going through a divorce, underperforming for a little while - let's wait it out". It's "we thought we got Messi and we ended up with Henry Bemis - which cannot be salvaged. Imagine the other top players on the team seeing Henry Bemis getting paid Messi-money.

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.

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

The only correct answer in this situation.

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.

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.

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.

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.

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.

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.

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.

> 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".

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

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

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.

>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.

No, there is no way to rescue the situation. If you make this sort of weak/poor management process where you tolerate incompetent employees standard, you will end up with a money hemorrhaging, adult daycare facility where all of the performing employees hate you and their job. If you aren't a monopoly, non-profit, or government organization, you'll also be bankrupt in short order.

Not only that, but also not optimizing for the happiness and satisfaction of the people working at the company. In particular those working with this person. Everyone will have a worst work environment to allow one person to get away with not being earnest during the hiring process

The real mistake is not correcting a mistake when you see you've made one.

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.

Generally speaking, the well-being and efficiency of the entire team should be a top priority for the company. From this, it also follows that having a solid interview process is crucial.

At the same time I kept thinking if they did fire the dev those 4 points you listed would happen. Damned if you do damned if you don’t.

I don't know, if they really are as bad as op says then I think most people would cheer them on.

I certainly appreciate seeing the occasional "we agreed it would be best for them to take a different path" emails from my company. Bit weird for them to send a global email for that tbh, but it really does send the message that they are actually responding to complaints and taking performance seriously, which is good.

In most companies in Europe it's incredibly hard to fire people even if they are bad at their job, and people know it. It's refreshing when managers actually do get rid of poorly performing employees.

Yea, I think it really depends on if the team's manager is getting comments from other devs on the team about the person getting fired. I had a QA get fired from one of my teams way back and while I liked them as a person, it was clear they weren't doing good work or having any real focus on what they were assigned, unlike their peers in the role, so it made sense.

I would add, a big point of the announcement should be "And we'll be expediting backfilling them". The worst sort of firings/quits is when management sits on their hands for weeks in replacing them.

Let them go. Provide a respectable severance, since it's the company's fault they were hired in the first place.

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.

It was a mistake to hire, but they misrepresented thrmselves and aplied for a position they must have known they didn't qualify for. To be considered they must have significantly embellished their resume. Fire for incompetence, no severence.

It's hard for me to morally justify firing an employee for incompetence without severance... for an issue that was created by HR's incompetence. (And potentially the interviewing team, depending on how "mediocre" the rating was)

Opportunistic applications are totally normal, and yes I’m a hiring engineering manager. If those aren’t caught in the recruitment process, then it’s the process that’s flawed.

Fire them. You are obviously paying senior money for a junior. Unless of course you tried to rip them off by underpaying them. Then I suppose it balances out.

Evaluate the hiring process, how did you mess up so bad? Fix it.

It's important to take responsibility. HR and the company fucked up. The employee negotiated well and over-sold their skills.

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.

> at which time we'll consider you for promotion.

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.

I definitely wouldn't guarantee it. But I think at least extending the possibility seems reasonable, given the fault.

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.

I agree with the general consensus to fire them, but if by "senior" OP means 3-5 years and this is a junior with potential, people are so hard to find that I wouldn't worry about misleveling or the salary difference. But the key is someone with potential. If it's a mismatch, cut your losses.

It's not an elephant in the room. They misrepresented their experience and qualifications, and now they're flirting with gross incompetence.

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.

We hired a guy like that. Clear deficiency in hiring process. I wasn't in management, but letting the mistake fester won't make it better. Additionally, if someone is that "senior" and good at interviewing, but not at thier job, it's unlikely they will come up to speed at a reasoble rate. Thier primary skill is interviewing, they might not be able to learn the skills they need to succeed. Let him go!

And also change the interviewing process, because clearly it's not testing for the skills that are needed.

I'm wondering if it's possible, given the current job market climate, to spend way too long trying to get a job, in multiple rounds of interviews, and basically pigeonhole oneself into passing the interview but losing other skills that are pertinent to performing and keeping the job.

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...

IMO, you don't lose a good engineering mindset or skills within a year or few months. Rusty, sure, but I'd say those skills quickly start to sharpen after working at a new job for a couple months.

> those skills quickly start to sharpen after working at a new job for a couple months.

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.

Yeah, it's hard because sometimes you just know that it isn't going to work and others you can see promising signs. It's all very situational.

My experience with hiring is it's better to error on the side of not hiring. If you make a bad choice, unless it's a flagrant fraud, you're going to spend a couple of months trying to get them to be productive. That's way more time then doing a couple more interview. And firing is risky from a legal standpoint as well.

Irrationally, I always think that posts like this are about me in my own role at work. Thankfully, I’m not this out of my depth. My impostor syndrome has decreased by 6% today.

ha I was reading this as well thinking shit, is this about me?

Im happy there are comments like those, makes me feel Im not alone in this..

> addressing the elephant in the room that they're not at the level we assumed

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.

It's only impostor syndrome if you're competent.

It aint easy to trully assess a candidate at the beginning. They may be overwhelmed with on onboarding and accomodating to the workplace. But they may as well be incompetent, that’s a possibility. Firing on the spot is a rash decision though. I’m a senior myself but at times (not always) when starting a new job the amount of stress I take to feel and adapt to the new team makes my imposter syndrome spike like there’s no tomorrow. Give me some time to accomodate and I perform as expected and am very much liked.

Your mileage may vary, but I have repeatedly used a particular strategy in difficult work conversations: Explain the problem to the person in direct, plain language, then ask them what they would like to be done about it and/or what they would do in your shoes. You're not committing to actually doing what they suggest, but you're making them aware of the problem and giving them some agency, and some insight into your perspective.

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.

I think being direct and giving someone a chance to explain what a good path for them looks like is a good option. That way, you don't dance around the issue and provide them an opportunity to explain (maybe something is going on in their personal life) which obviously doesn't guarantee their employment but may allow for a bit of leeway.

Do they know they're underperforming? While they may have imposter syndrome, it's a different thing to know you're actually under performing in the eyes of management. Have the difficult conversation and address the elephant in the room.

Critically, discuss your options and intentions with HR. It can get messy for everyone if you don't approach dismissal in the right way.

(Not an expert manager; just some thoughts based on things I've seen.)

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.

> "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."

I'm not pro-HR by any means, nor have I had to hire/fire a bunch of people, but the minute you hint that an employee could be terminated, there's a chance that they could take retaliatory measures.

Further, OP stated, "Essentially we had deficiencies in our technical interview that allowed for custom-fit preparation..." So, it doesn't seem like the candidate had "good faith" intentions from the start.

If OP is in the US, most states have an at-will employment clause, so a quick break isn't illegal by any measure (as long as they aren't terminating the employee for things like sex, race, religion, etc.).

If the candidate was dealing in good faith, then company should too.

The whole corporate-think "this person might do something evil, though we have no reason to suspect that, so we should do evil first" is wrong.

(I said talk with management and HR first; they might counsel or instruct differently, but you should make an effort to stand up for employee while you have the chance, before you potentially have to disagree and commit.)

If the candidate wasn't dealing in good faith, then, like I said, terminate.

I'm not sure "custom-fit preparation" counts as not having good faith. If I was doing an interview process and was told the next step would involve a live coding exercise in a specific language/package that I wasn't already fresh on, I'd be cramming for it to a degree where my performance would mostly show how fast I can learn something and not my net level of skill in that language/package. If the hiring folks inferred the wrong thing from that, that's not my fault for studying based on the information and parameters they provided me.

You fucked up, but most likely you are playing with vc money so who gives a fuck? Pay him, keep him. Chances are you will fold in a year or two so at least you make someones life a bit better for a while.

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?

Surprises me this is not the top voted answer. After years in this industry, I have zero empathy for startups and VCs, and all the empathy of the world for employees. Keep him.

I have zero empathy for them too, but this is still just stupid even assuming that this company is VC funded (most aren't).

Most of us do not go to work to warm the seat in exchange for paycheck and poor performers are devastating for morale. It's difficult enough to manage how people perceive themselves with relation to others and their compensation and you do absolutely no favors to anyone with making this even more complicated by having a visibly incompetent employee being over-compensated.

Please do let them go asap. I have seen this before in my career, and as a junior software engineer (at least that was my title when I got hired) I was furious when I had to clean up after the "senior" engineer so many times because of their incompetence. My teammates were all frustrated equally, but we were working as a flat hierarchy team so there was no boss to report this to...

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.

Fire immediately.

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.

Even in European countries with strong employee rights, the typical contract is allowed to have a 3 month or so "probation period" during which either party can terminate at short notice. I guess this is one of the situations that clause is meant for.

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.

Your hiring process screwed up, so let them go, and figure out how to fix it next time around. There's really no salvaging the situation as you have described it. The engineer is unlikely to take the option of a role that has lower status and pay, especially given that you've already introduced them to the team as a senior.

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.

Mediocre rating and imposter syndrome but excelled in selling themselves? I don’t feel like this is the full story. What is the purpose of this ask? To receive validation and an excuse to go against some self perceived principles? If you look to let them go do it without requests for psychological support or pursuit of excuses. You are a human too and you deserve support, but in this situation, the other party will need more of it and possibly bears less responsibility for the outcome.

Yeah this seems indeed missing details. It's not the candidate's responsibility to guess what the hiring manager is really looking for and kind of normal to get the best position possible. That said, the hiring process seems utterly broken if it wasn't possible to distinguish a junior from a senior.

edit: personally I think though that the company should take responsibility and make sure the employee either gets ramped up or a very smooth exit financially since the application probably meant he missed other options

Have you had a direct conversation with them? If not, have one with a line manager, an out of the line technical expert, and a member of HR. Explain specifics, and how expectations are not being met. Then be silent and see how they respond. Develop an action plan with dates. Mention consequences later, if the action plan is not being followed. Bad things happen to good companies. You must use a process to get out of it.

Don’t drag out these decisions.

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.

Unrelated: did this manage to work its way up to the #2 spot in under an hour because everyone on HN is worried this is about them deep down?

I think a lot of people deal with this exact situation because some developers stumble into this field and "get by" for awhile until they get hired at place where their BS is obvious.

Consider firing your HR department too https://www.youtube.com/watch?v=DKL47LUeHYM

Only hearing your side of the story, it sounds like they significantly misrepresented themselves and then negotiated something way more than they're worth. It's the kind of developer that makes the rest of us look bad, IMO. Why not let them go? This one's on them.

I appreciate your willingness to try to salvage the situation, but the best thing for all parties in scenarios like this is to transition them out.

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.

> The result is net-negative productivity.

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.

Various locations of the paper - https://web.archive.org/web/20160305234708/http://pyxisinc.c... https://www.scribd.com/document/557220119/NNPP-Article

And here it is discussed at C2 - https://wiki.c2.com/?NetNegativeProducingProgrammer

Why it needs another 6-12 months to get them to be productive? Is it some system programming position? I can't imagine anything else that would require a year to get people into shape.

Kernel development, simulations, numerical methods, ML, graphics, database internals, compilers, infosec engineering, etc.

10 years ago yes, but nowadays that domain-specific knowledge can be solved with a $20 ChatGPT subscription (as it simulates very well pair-programming and spitting out explanations for you).

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.

This is a joke, right?

It is very true, ChatGPT makes it very easy to learn all the “domain-specific” knowledge, and makes the learning-curve less steep.

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.

I get the sneaking suspicion that you don't actually do this shit. ChatGPT isn't an expert coder sitting by your side. It's not even remotely close. Go ahead and get ChatGPT to walk you through how to implement even a non-novel CFD analysis that won't get you laughed out of the room. Get it to help you port an Ada Ravenscar runtime to an exotic (or even a not-so-exotic) processor. Try and have it generate non-trivial ladder logic programs for industrial controls. Try to get any help from it at all when doing microcontroller programming that isn't just "read the manual".

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?

No need to get so upset ? It is like if I say that reading a book will help you learn faster about a domain than if you have to discover all by yourself.

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.

I'm not so much upset as I am flabbergasted.

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.

It's the opposite imo. Knowledge specific stuff isn't what chatgpt excels at. It will be great for general programs but once you step into a niche, it just has a lot less data to work on

Agreed *, but (IMO) that's if you're starting with someone who has no prior experience in those topic areas.

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.

A whole year for a senior is too much imho.

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.

Yeah that's why I asked if it's a system programming position. Anything else should not take a year.

I think the belief that a 6 month bootcamp (or equivalent) is sufficient to create a competent developer even in "easy" domains like web is a big reason why most software sucks and why "impostor syndrome" is over-reported.

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.

OP merely asks for being productive. It is a pretty wide range.

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.

Fire them immediately.

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!

First off which country youre in determines what you can do and how much it will cost you. If you don’t already have HR staff who are well versed in local laws and regulations then you should engage some outside help.

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.

Was the candidate informed about the expectations before or after being hired? Has anyone communicated to them that they are not meeting those expectations?

I never understand these situations, it took me months to get a job offer and somehow incompetent people accidentally stumble into senior roles?

You can thank HR for that.

Because there are incompetent interviewers too out there, its just you haven’t encountered those yet.

Remember there is lot of incompetent people being interviewed. Majority of people being interviewed do not get hired. Some of it must be because incompetency, and they keep trying to get hired. So occasionally some of them do pass through the filter and this is one of the results.

If you were wrong then, maybe you’re wrong now. What are these basic skills and can you measure them across the new hire and the existing devs? In order to hire better next time, you’ll need to be able to apply this sort of screening at the front end. If you can’t, then maybe it’s a management / utilization issue.

I really wonder about submissions like this. Is it real?

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?

If you’re willing to write all of this in a hacker news post, it’s clear that you take this very seriously, and it weighs heavily on your mind. Based on what you said, it’s also clear you must let this person go, but be helpful in finding them an opportunity that matches their skill level. Easier said than done!

Maybe they should create a startup teaching very talented people how to better represent themselves in interviews.

It's not me, is it?

Nah I think it's me

We better start doing some work, just in case.

I really appreciate that you want to salvage the situation.

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.

It is your responsibility to look after your team as a whole. Sometimes that means taking decisions that negatively affect a single individual.

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.

> Do you think there is any way to rescue this 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.

> 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

If HR hired the person despite a mediocre rating then they're the ones that need to be sacked.

If someone had used the phrase "hire at any cost" to HR then a candidate being mediocre seems to not be a fatal flaw.

Indeed, it feels as if the OP would be relatively happy if they'd hired a mediocre senior dev, but feel this guy isn't even that.

Quality is a process that begins with management. How they value it is revealed by the actions they take in cases like these.

It's unfortunate OP wrote plenty about their displeasure with the candidate but failed to tell us anything about their role in the hiring process, how well the job description matched the actual job requirements or how HR got the impression it did.

But the situation as described strikes at a reason I've left previous jobs: the feeling that I couldn't trust the competency and integrity of those I worked with.

Like the time our in-house recruiter presented me "resumes" they fabricated from linked-in profiles of people they wanted me to interview but who hadn't actually applied to our company, or the time I was pressured give passing reviews to candidates who couldn't pass basic programming tests from managers eager to hire loyal toadies.

A small outfit with a focus on personal development, intrinsic motivation, good climate, and low turnover can't afford incompetent or perversely motivated HR people who "hire at any cost" candidates with mediocre reviews.

The same happened with me a while ago, I hired a dev with 8 YoE because he had the best resume and was good on a video call.

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.

If you're a small outfit you can't keep someone like that around. You need to part ways. You can't rescue this particular situation. You're screwing the guy/gal you hired, too - they're probably under a ton of stress, and high stress over the long term is not good for anyone. You should also recognize that this stress is not entirely their fault - it was _you_ who hired them, so you share some responsibility for this hiring failure. You may be tempted to demote, but I have not seen this actually work out in practice. I'd let that person go.

"Do you think there is any way to rescue this situation?"

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.

If keeping this person onboard requires the effort of training them and keeping their comp a secret, it's not worth it. It will get out that this person is getting paid senior comp for entry-level work, and that isn't going to fly for the people who are performing. Don't overthink this.

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.

Don't take it personally.

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.

I’ve been in this situation when I was a junior engineer and found it really frustrating. I’d literally done more work in a week than the “senior” had done in their time at the company. They had shipped one change (a migration) and then nothing for 8 months.

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.

In my humble opinion, the best approach depends on your specific circumstances, the employee's willingness to learn, and your company's culture. It's a complex situation, but with open communication, a commitment to support, and a clear plan, you may be able to salvage the situation and help this employee develop into a valuable asset for your team.

I'm curious how much they're willing to invest in skills development for the sake of their future career.

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.

Not knowing their side of the story, the OP makes it sound like they basically lied and practiced interviewing to score a high paying job. That sort of dishonesty shouldn't be tolerated, much less rewarded.

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.

Got to hand it to them, they know how to play the game.

Though, it would be a shame to not transfer them to sales or marketing, they sound very talented at that, at the very least.

Fast fire. You've gotten past the hard part, admitting the mistake. The quicker you let someone like that go, the better for you and your team. The mistake here would be to work on their performance and drag it on. Your team morale will take a big hit. At best you'll see a marginal performance improvement over months. At worst you'll waste months on this employee and have to fire them anyway.

> they're struggling to do even basic stuff without help and are far from helping others

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?

Do also consider that if this was your mistake (which you say), and they quit their previous job or declined other offers because of your erroneous offer, then you might have done them harm by your error, at least ethically if not legally. Be sure to talk to your lawyer, and consider what obligations you have to them in parting ways, both legally and ethically.

This is very strange that you're asking HN how to handle the situation. Who are the "We" that is running your company? Of course, if you're just posting something to generate some chat on HN that's fine, but if you actually need to ask the opinion of the HN community about what to do in this situation, then you have bigger problems.

It is perfectly acceptable to seek advice and opinions from a community you respect - not a problem whatsoever, it is a sign of making attempts at being the best leader one can be.

It can also be good to get input from people that do not have any stakes, worries or agenda. Plus that have a wider ser of experience (collectively). Of course one should also discuss it inside the company.

Document the performance issues in writing, create an improvement plan for the employee that they sign, and if the employee cannot correct the issues, you fire them.

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.

This (as a few others have noted) is the purpose of a probationary period.

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.

From my experience working on managing roles for 5 years, the most critical part is to be honest and transparent. Especially in terms of expectations. Be clear. talk to them, ask right questions,bring them to the state where they realize and agree with the reality. The rest is simple.

This is what probationary periods are for.

Assuming your side of the story is true, can you downlevel them to a more junior position and reduce their salary? If they won't accept that, then the only reasonable option is to let them go. Other developers will notice and become disgruntled having a incompetent co-worker making more than them.

Add people slowly but let go quickly, nothing good will come out hanging on to this person hoping for the best.

Dealing with the exact same situation now but I'm not the manager. The new hire has a 12+ YoE but severely lacking technical ability. While they fall short in the specific stack we use (not a huge deal), they're completely unwilling or unable to adapt & learn it seems.

This is a good case study and how different the US versus European climate for scenarios like this is

How does Europe handle it?

Probation periods at the start of employment, mostly. And once the probation period is over, you need to provide robust cause to fire someone.

You can fire people in Europe too. In a lot of cases you have a six month trial period in which the employer or the employee can cancel the employment without any notice period. After six months there is a notice period from both parts, typically one to three months.

Most companies in France have a trial period of 3 or 4 months which can be doubled to "make sure that everything is right." Which means that companies have to 6 or 8 months to fire new guys.

I guess it’s the same amount of time in other countries.

It is expensive --- but here (the Netherlands) you can still fire or demote someone after the initial trial period. Instant dismissal without cause (for non-discriminatory reasons) is possible in the trial period, with trial period being time-limited (1 month for 12 month contract, 2-3 for permanent).

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.

In many places, there is a trial period of 3 months and then usually you do a one year contract. So you have at least two decision points.

Second thing is: most of our countries have a more direct conversation style.

Contract work is a lot more common in Europe for a reason

I don't think I ever realized that's why there are so many discussions of "employment contracts" here on HN (which has a heavy European population, from what I can see). In my entire adult working life in the US, I've never once had an employment contract (and still have never seen one or heard of anyone else with one, either).

Yeah,contract work in north america is more reserved for very specific situations (for example, you need expertise in some very niche system) and even then that's pretty rare outside of consultants. In Europe it's everywhere.

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.

Having an employment contract is more common over here, but that's not the same as what we'd call being a contractor.

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.

Does this mean employees have to renew the contracts? As in, if the employer doesn't renew the contract, does it count as getting fired? Also maybe it's regional, I know that in France contractors are very common but I might have outdated data!

Can you explain?

Trust me, others notice this person is GROSSLY overpaid. They also resent the fact that if that person is paid as a senior, and they are obviously better. They will move on to a company that appreciates their skill and not overpay a buffoon.

Do you need to demonstrate to others this person's incompetence before you can let them go?

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.

Yeah, he's talking about team morale, so I guess he has to make sure that the team also thinks he's underperforming.

It may not be immediately obvious, but firing them asap is probably less disruptive for them:

* 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

Being a small company, you could have hired them on trial & part time for a month or so, evaluate their skills before taking them in as a permanent full timer.

Don’t drag out a hopeless under-performer.

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.

> the candidate excelled at selling themselves and negotiating

sales / executive track

This is why we need to have coding tasks during the recruitment process.

It helps both sides.

For seniors it’s not that easy. The best interview process I had to do was in a restaurant where the recruiter and I were both ranting about how shitty C++ was.

I got hired on the spot because the conversation we had proved that I was not bullshitting anyone.

It may be more difficult for a junior, but that’s not the topic of the post.

Yes, one of the questions I ask is "what do you hate most about X?". However, in this case the person lacks "basic skills".

Let $dev go, and apologize to your team for messing up this badly.

It sounds like they out-negotiated both you and your HR team.

Have you considered giving them a role as a sales engineer instead of as a developer?

If you allow him to stay, and do the learning (if he's willing to) you would be magical fairy granting wishes. There is no such work place with such an attitude

Get that interview process fixed ASAP and let this lemon go. Don’t be surprised if there is pushback from non-technicals if this hire checked a bunch of boxes for other departments.

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.

That is just evil to both that person and your team. Just let the person go if they do not satisfy what they were selling them self as. Dont play evil and stupid games.

US is an exception in terms of at-will employment.

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.

You can in the probationary period.

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.

That's "constructive dismissal", which is not allowed. Firing for "performance" is ok in the first year or two

(country specific)

> "constructive dismissal", which is not allowed.

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.

And those countries generally have laws against constructive dismissal (which is what a lot of these "persecute then until they quit" recommendations amount to)

> 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.

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.

This proto-sociopathic behavior is the direct result of European employment law. It's disgusting.

It is not. You would fire the person in the trial period or after a year.

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.

Entrapment is sociopathic.

> which is contradictive to capitalism

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.

No, it's the result of that poster's mindset - there's absolutely no need to do any of that. In fact, that type of behavior is against the law in a lot of countries and will leave the employer likely liable.

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.

This is not true. It’s impossible to fire an employee for performance reason after the probation period in Germany. If an employee cannot deliver on the tasks assigned, they need to be assigned easier tasks. In order to risk your job you have to actively work against solving your skill gap, e.g. declining offers of upskilling.

First, let's be fair, Germany really is an awful example if you're going to then try to apply it to the rest of Europe.

> 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.

I agree on the statement that Germany really is an awful example. Period. :)

> 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.

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.

Aside from the predicament at hand, I just want to say that this post was incredibly well written. I enjoyed reading it and read it several times.

You need to let them go, there is no other alternative. They were hired by mistake for a position they’re not qualified for, it’s that simple.

This is what the 'probation' period is for?

We don't have those in America. Mostly because your healthcare is tied to your job, so nobody would risk taking a probationary role that could land them out of work and without healthcare at the end of it...

I don't follow (not from the US, please excuse my ignorance). I was told that, with some exceptions, in the US every job is permanently "on probation" ("at will employment"). As in, you can get fired from one day to the other, no severance and no reason needed (as long as it's not discrimination based on sex, religion, etc). Is my understanding incomplete?

You are correct, however, that isn’t the same as probation. Companies with a probation period may not grant full benefits until after the probation period ends. For example, a company may not let an employee take any time off during the probation period or the company may not let an employee participate i. The company 401k retirement savings plans until after the probation period.

> I was told that, with some exceptions, in the US every job is permanently "on probation" ("at will employment").

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.

There most definitely are companies that have a probationary period in the US. It may not be common but it does happen. My first dev job had a probationary period and I put up with it because it was a job that was willing to employ me as a dev without a CS degree or prior dev experience. I lasted about 7 or 8 months before I quit for somewhere better.

I don't really understand the reluctance to fire them? Is the shortage of good developers so dire that you need to keep a bad hire?

> but we're a small outfit with a focus on personal development, intrinsic motivation, good climate, and low turnover.

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.

https://youtu.be/XchwE9zVdnw

If you hired from an external recruiter, don’t delay getting rid of them — there’s probably a warranty clause where you’ll get most of your recruiter fee back if and only if you turn it around quick enough. 12 weeks in and the warranty is normally done.

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.

Obvious answer is to fire immediately. Huge red flag if you cant fire someone under these circumstances.

> Or should we make this (perhaps justifiably, after their misleading self-presentation) the first time we let someone go for performance reasons?

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.

> 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.

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?

Just do the right thing and don't waste time on it. The candidate is out.

I've usually had a probation period clause in my employment terms.

Offer choice of either downrank (and criteria to get back), or fire.

Fire their ass or downgrade the job title (and pay) to intern.

Fix the glitch and let the problem work itself out naturally.

Just fire them u know it's the right decision

Make them senior.

To echo everyone else's sentiment - fire them.

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.

Does this employee have any positive traits?

First talk to this dev face to face to understand if they were lying to you and being disingenuous about their skill level or was it your own interview tests that just failed to detect they weren’t a senior

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.

Document document document and PIP

I was in a team where this happened. Management stuck their head in the sand for the longest time, while the morale of the team started tanking, as noone wanted to work with this person, who needed a lot of attention and never seemed to improve, even after years of trying.

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.

> 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.

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.

It is not clear at all if you have even taken the most basic step -- provide feedback for this employee. It's just not clear how to reconcile this impression -- nothing has been said at all -- with the plea for "rescue" from this situation. You mentioned "personal development", so this is a great opportunity to develop those management skills.

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.

no offense (okay, maybe some), but how is this even a question lol... fire immediately. it's not something tangential like communication, but about someone lacking the core skill that you are paying for.

Dude you’ve been lied to. Letting them go is salvaging the situation.

It isn't impostor syndrome, they are literally an imposter. They committed fraud to get in the door, you didn't coerce them to get a much better paying job than they are qualified for. Now that they know they can't do the job, they are content to keep cashing paychecks and hope that your company is too hand wringing and soft to call them out.

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).

I didnt get enough info from GP to make this judgement. The problem could be on HR hiring wrong person due to their interviewing incompetency. It could also be bad hire, but Im careful not to jump to conclusions, I’ve seem both scenarios IRL

Not possible for somebody who knows what they are doing. I've aced technical interviews with zero prep where the leetcode I was writing was the first code I'd written in six months.

The bar is really, really low. You will have to step over it however.

Reply on news.ycombinator.com