[wanderr]

If you hire enough people, eventually you'll have a bunch of examples for this question, unless of course you never make mistakes.

Pretty much everything you can imagine can go wrong and probably more. Hiring anyone is always a risk but it's one you can't avoid, nor do I think that the interview process should be so tough as to have lots of false negatives to prevent those bad hires; better IMO to have a reasonable filtering process and then be on the alert for problems post-hire so they can be addressed early, including the possibility of termination.

That said, specific bad hire examples that were tough to deal with:

-Developers who get stuck and don't ask for help - spinning your wheels making no progress until someone notices is a great way to derail a project and make yourself look incompetent. Often times the things these developers get stuck on are quickly solved by some outside perspective, rubber ducking, or specialized knowledge.

-Negative attitude, high aptitude: a developer really good at their job but constantly sowing seeds of discontent, either getting into conflicts with others directly or subverting management directives, talking to others about how terrible the company is doing, etc. Letting an otherwise extremely competent person go is very tough so often they are allowed to remain way beyond when they should.

-Architecture astronauts/overcomplicators - maybe a cultural fit issue but some people are allergic to the move fast and break things approach, focusing way too much on nebulous code quality aspects, high levels of abstractions that often end up interacting in weird ways that are hard to debug, with the aim of high levels of code reuse and extensibility, but in the long run often leads to the need for major refactoring when underlying assumptions change. It's not that these qualities are are always bad and never work, but some developers are seemingly bored working on less complicated systems and majorly over engineer even things intended to be thrown away or overhauled later, so often times is a huge waste of time and ends up being more difficult to maintain. Of all the bad habits or deficiencies developers can have, this is the one that I haven't had much luck with intervention on.

-Lone wolf - some developers are great in one on one interviews and are quite capable, but turn out to not work well with others. They either refuse to follow processes, or on group projects will just do what they want even if it doesn't match what the group decided, they might decide that a midnight refactor of a core piece of code someone else is working on is something they have to do right now, and not even bother giving the other person a heads up. Sometimes you can give them sufficiently isolated projects that they can work effectively, but in the long run it doesn't really work, and you risk harming the rest of the team.

-Sloppy / lack attention to detail. Developers who fail to check their own work, or do it so hastily they don't notice glaring mistakes, or who are rushing so much they don't / can't follow a simple spec. These developers also often have trouble following coding standards because either they never learn them or they're not really looking at their code enough to notice when it doesn't follow.

-Not curious / quick to BS through a problem. Debugging skills are critical to being a good developer, but some developers don't spend much time or effort figuring out how to effectively debug their code and surrounding systems, so as soon as something goes wrong they have no idea where the problem is, are often quick to resort to ghost stories to explain the phenomenon, I.e. blaming a heisenbug that's caused by a race condition on the browser, a failed request caused by a network outage on the API, etc. These developers are frustrating to help because even when you teach them how to investigate these issues, their lack of interest means they'll never pick it up. Subsequently they're more likely to ship bugs because they're good at convincing themselves that bugs they observe are not the result of their changes.

[throwaway9475]

I'm on a phone, so typing is not the easiest, but as a quick response to moving fast and breaking things: maybe people don't do that because they don't like getting paged at 3 AM when some clever piece of code breaks. :)

[wanderr]

Yeah that's definitely a company culture thing too, breaking things at some places is considered terrible and the company would prefer a 5x longer development cycle for half as many bugs. But clever code usually takes longer to write anyway, writing dumb code that just does what it's supposed to is less fun, can be downright boring but usually fails in obvious ways that are easy to detect and even easier to remedy because there's no cleverness involved.

[kungtotte]

Don't you think the first one can be a result of imposter syndrome and not wanting to risk looking like a fool for asking for help?

If they feel like they ought to be able to figure it out on their own, asking for help suddenly is a big hurdle because they think that their colleagues will judge them for it.

[wanderr]

Definitely a possibility, but whatever the reason it drastically affects performance so it's something that needs to be overcome. Also if the company has a strong culture of openness and collaboration, examples of everyone else constantly asking for and receiving help, even the most senior developers, should quickly allay those fears of looking like a fool just for asking for help if you pay attention to what is going on around you at all.

[lobotryas]

Absolutely can be, I know from first hand experience. Know what the solution is? Adjusting your world view and learning how to ask for help without looking incompetent. This usually boils down to:

1. Research the problem first as best you can and describe the steps you took to solve it when asking for help

2. Take notes so you don't end up asking the same question twice

[lj3]

> Developers who fail to check their own work, or do it so hastily they don't notice glaring mistakes, or who are rushing so much they don't / can't follow a simple spec.

You would actually fire somebody for being unable to keep up with a deadline they didn't set? In my experience, this is mostly the result of management placing too strict a deadline on too junior a dev. It's a mentoring moment, not a firing one.

[wanderr]

None of these are things that directly lead to firing (aside: deadlines shouldn't just be handed down to developers, and deadlines shouldn't be so rigid there's no room for mistakes), of course you try to mentor and provide guidance to correct. But these traits are regrettable in a hire because in my experience these are the most difficult to deal with or correct even over a long period of trying.