
Ask HN: Have you ever regretted hiring a developer? - omidfi
I&#x27;m trying to find out what can go wrong while hiring​ a developer. What might cause that? 
Lack of technical skills? Or attitude problems?
======
cauterized
I've never had a hire go wrong for technical reasons. I have hired,
participated in hiring, or inherited several developers who had to be let go
for reasons related to attitude or soft skills. Some examples:

\- a guy with an alcohol problem who would disappear for a week at a time or
come in to work sloshed

\- a junior developer who had major problems with authority, mixed with
bizarre paranoia. He refused to take direction from his team lead and had to
be let go after he started accusing anyone and everyone of trying to undermine
him.

\- a guy so obsessed with doing everything perfectly that it took him a year
to produce what other engineers could accomplish in a month. Granted, his work
has been running for 3 years now without a single bug, but even taking that
into account he still wasn't cost effective to have on the team

\- a developer who refused to take ownership of his projects and insisted that
everything expected of him be specified down to the pixel (might work at a
large corporation, but not a startup - we don't have time to hand-hold like
that)

\- a guy who was hired as a junior mobile engineer and then began throwing
fits when we denied him the authority to change the priorities of the entire
web and mobile product team

Takeaways:

It's fairly easy to assess who is and is not capable of developing basic CRUD
apps. Getting meaningful information about a person's neuroses, self-
management ability, and ability to play well with others is extremely
difficult in the space of a handful of hours of interviewing.

~~~
dilap
The perfect code guy doesn't sound so bad.

~~~
pryelluw
Until you ship a product so late that its declared DOA. Perfect coders are
more dangerous than shitty ones. They usually slow down progress in the name
of perfection so much that nothing gets done. IMO.

~~~
stouset
I don't know that I agree that perfect coders are more dangerous than shitty
ones. When you're behind on a project because someone is taking too long, it's
upfront and obvious and usually they can be encouraged to speed up things as
long as they document where work needs to be done afterward.

Bad developers are the gift that keeps on giving. Everything looks great, you
ship, it mostly works, and then you spend four years struggling to build
anything on top of what was written, squashing data-loss bugs that take weeks
to track down and can never have their root causes fixed, etc.

Companies that end up in the latter situation are basically zombies. They're
already effectively dead, but nobody knows this is the case for years, pouring
time, effort, and money into a bottomless sinkhole.

Perfect coders can also serve as _really_ good mentors on teams, and catch
serious issues everyone else would have missed.

------
samblr
In interview what appeared to be a potential-hire's strength - became a real
nuisance when we hired him. We wanted someone who could do both android and
iOS. He was a senior, had enough to showcase and plenty to 'talk about
software architectural things'. It turned out, he was jack of all trades
(python, java, objective-c) but he really-really struggled at designing
software but he could talk through people and walls. And then he formed a bad
habit of mailing in out-of-hours to group that somebody's else code has this
problem - how to fix, so on and so forth. Initially we didn't know of what to
make of it. He could small bug-fixes ok. Then we assigned a good chunk of work
in new project. And boy, did he create a mess of it. Since he was lagging
behind from dates assigned - we sat for a code-design-review. I sat in horror
that day on how confidently he was presenting to what was not even a
freshman's work. He didn't have a clue on why blocking calls should not be
made on UI thread. We didn't give any good work to him later. He left us soon
and last time I checked - he was a CTO of a mobile development shop! N

~~~
Spooky23
Sometimes people like that are better in leadership roles. Knowing a little
about a broad scope of things is very useful in those roles.

~~~
late2part
Managers that can't do are generally shepherds. Only sheep follow them.

Yes, it's good that managers can know a lot about a broad amount, but they
should be skilled enough to dive fairly deep and realistically be expected to
jump into anyone's job.

Otherwise, you're hiring an administrator or a non-technical manager.

And there's a place for that, but not one I want to be near.

~~~
scarface74
I see nothing wrong with a manager who is technical but can't take a deep dive
into the code.

A manager's role could be to decide strategy, priorities, budgets, inter team
communications, working with the customer etc. the biggest thing I want from a
manager is to hire good people and to trust them with the "how". My manager
decides the "what" and "when". He leaves it up to his team to decide the how.

~~~
late2part
"strategy, priorities, budgets, inter team communications, working with the
customer" is 90% of how. Your manager just presents these things as if they're
not.

weak e.g. [http://www.inc.com/jeff-haden/5-ways-to-ask-the-perfect-
ques...](http://www.inc.com/jeff-haden/5-ways-to-ask-the-perfect-
question.html)

------
49531
The biggest issue I've had is with engineers with strong opinions strongly
held. A lot of time they're unwilling to compromise and do things their way
100% of the time.

Recently I had an engineer on my team who would never pattern match in a
project. He would always introducing new patterns everywhere he went. It was
all just an unwillingness to be flexible.

------
wheelerwj
This is an interesting question, because it signals that you are most likely
very new to hiring, and maybe ill-equipped to handle managing people in
general. Although, at least you're asking questions.

First, very rarely does a manager regret a hire even though it's very common
for a hire not to work out. Hiring and interviewing are in terrible shape
right now, and more often then not lead to terrible hiring/job acceptance
choices.

Second, you regret hiring PEOPLE, not developers because regrettable hires
aren't specific to developers. When they are, it's because an engineer was
given too much access to something they should not have been and a
theft/breach occurs.

Examples of these concepts in play: The NSA probably regrets hiring Edward
Snowden. I don't regret hiring the last JS dev I hired even though it didn't
work out and he moved to a different company.

Lack of technical expertise is a problem sometimes, but it can be nurtured.
Lack of personal skills is a huge problem in an office environment, and is
much, much harder to nurture. But neither of these are regrettable in-and-of
themselves.

The thing to remember is that you have to weigh the urgency of hiring against
the long term impacts of hiring the wrong person. In other words, be careful
and set up controls, but don't allow decision paralysis.

Good luck with your project, keep your head up, and expect failure. Great
employees are rare, so just keep at it.

post mobile edit:

Go read:

Good To Great: [https://www.amazon.com/Good-Great-Some-Companies-
Others/dp/0...](https://www.amazon.com/Good-Great-Some-Companies-
Others/dp/0066620996)

How to Win Friends and Influence People: [https://www.amazon.com/How-win-
friends-influence-people-eboo...](https://www.amazon.com/How-win-friends-
influence-people-ebook/dp/B01H38S9FY)

Emotional Intelligence:
[https://www.amazon.com/dp/B000JMKVCG/](https://www.amazon.com/dp/B000JMKVCG/)

~~~
blablabla123
>Lack of technical expertise is a problem sometimes, but it

>can be nurtured. Lack of personal skills is a huge problem

>in an office environment, and is much, much harder to

>nurture. But neither of these are regrettable in-and-of

>themselves.

That's actually a cool attitude. When looking the first time for a full time
job 7 years ago I was astonished how static employers seemed to perceive skill
- at least in Germany. I had various conversations with headhunters/recruiters
and oftentimes it went like this: "Do you know [insert simple technology X]?"
\- "No, but I can learn it quickly as I have experience with [similar
technology Y]" \- "Ok, but I asked for X". I found that really frustrating.

Also in most jobs I worked in between I had to learn everything on my own
initiative - no matter if that was tech or people skills. There were countless
occasions when people, especially ones in manager(-like) positions would
discourage me from spending time learning certain skills. I'm happy that I
didn't follow so much on that.

Anyways, on my recent job hunt I was very surprised to find companies that
actually have programs to develop their tech employees on a wide range of
skills. Luckily I'm now working at a place that at least has interest in
developing their people.

~~~
late2part
Have you ever gone and quickly learned it and called the recruiter/company
back?

~~~
blablabla123
Didn't try that yet. But that would only work for microscopic node js
libraries. I mean when someone asks you: "are you proficient with SuperAwesome
ORM XYZ?" Apart from the fact that the person on the phone probably won't even
know what an ORM is, it's not possible to learn an API by heart in 5 minutes.
;) (I doubt it's desirable but that's another thing.)

I understand the desire of people wanting to have competent hires who get up
to speed quickly. But that is just going in the completely wrong direction and
likely costing such companies tons of money because they need to search
longer/spend more on a dev.

~~~
late2part
Maybe. Or you could invest the short time you said it takes to come up to
speed, do that, and call them back. You'd be much more valuable to them and
should be able to get a job more quickly with higher value to you.

~~~
blablabla123
I'm sure you're right but on the other hand I'd then declare myself as having
not enough value. I find it already ridiculous which amount of preparation
some companies ask, just for a simple interview. Doing even hours (or days -
in case of a lib) for making a good impression on the phone is just insane.
Interviewing with 20 companies would then be a half year full-time job.

On the other hand taking a few days to get to know something is still waaayy
better than taking months for the exact same thing. But yeah, that's just over
the top for recruiters who just want to go through a checklist.

------
dougireton
Developers who insist that their favorite technology is the best vs. what's
the best for the task at hand, what technology will the team as a whole be
successful with.

Developers who don't have empathy for less experienced team members; who
can't/won't mentor well.

~~~
zepolen
Meh, takes me back to a couple years ago when the MEAN stack was all the rage,
I was pointing out flaws/problems which would arise from:

\- Mongo not having a schema, relations \- Angular having a fundamentally
flawed update system

But of course the argument was that 'MEAN is what everyone is using, its easy
to find MEAN developers'.

Sure, if you mean it's easy to find kids who learnt how to make apps, via a
MEAN stack, over a couple months as their first ever tech and now are ready to
work for very cheap.

Of course it's never cheap - what you save on quality you make up in quantity.

The amount of developer time wasted writing migration scripts, debugging silly
problems because of no schema, data loss (at least they took my advice on
automating backups!), not to mention a ton of frontend issues - was
staggering.

Yes, this was a 6 month old startup with about 6 fresh college "engineers".

Experienced developers have a favorite for a reason, usually they've been
bitten by other ones - I would say don't trust a developer who pushes a
certain tech without giving a _reason_ beyond that they are familiar with it.

For example, I've found javascript a painful language to work with (although
that's starting to change with all the latest revisions to the spec) - but it
makes no sense to push for a different language when half the app is already
written and all the devs know javascript.

Using Mongo as a db on the other hand I wouldn't suggest ever, data integrity
is way too important to use a (badly implemented) cache as a database.

There are much better technologies out there that give you everything that
Mongo tries to provide, and faster too.

~~~
scarface74
I'm relatively new to Mongo and I've only used it in C#.

But a few points:

I would only use Mongo as a backing store for a micro service. All access
would be through one service that enforced business rules, data integrity, and
would be responsible for exposing business objects/aggregate roots.

App servers are a lot cheaper/easier to scale than database servers. By
keeping all of the logic in the business tier, it's a lot easier to scale/load
balance.

~~~
zepolen
See, what you just posted is a typical response which tries to justify Mongo,
even though you yourself have little experience with it!

Fine, I'll bite:

> All access would be through one service that enforced [rules, integrity]

That's a very good idea; you just described what a database is. Now why take
it upon yourself (and team) to reimplement that yourself when there exist
quite a few that have had thousands of programmer _years_ scrutinizing every
detail to create the most robust and optimized systems... these are much
better programmers than you or I for this job, these guys eat shit and live
databases.

> App servers are a lot cheaper/easier to scale than database servers. By
> keeping all of the logic in the business tier, it's a lot easier to
> scale/load balance.

Ah there it is, the typical FUD, by moving everything out of the 'database',
you can scale.

Nope, that's not true.

The only thing that doesn't scale easily with a database server is joins - In
all other cases it's possible to (even with an rdbms) scale infinitely via
sharding. In fact there are many implementations that do so, and they are
usually _faster_ than Mongo.

Now onto joins, these get implemented in the "app server" by the inexperienced
developer in 2 ways:

A. Real joins using normalized data

1\. generates a ton of network congestion from getting the data

2\. ton of cpu because because json decoding/encoding

3\. ton of cpu because scripting languages vs optimized C

4\. the use of O(shit) algorithms to make the joins

5\. inconsistencies when things fail like network or disk or shutdown

B. Redundant data

1\. use a ton of memory/disk

2\. create deferred overheads in order to keep things sync

3\. despite that, end up with inconsistent data all over the place

4\. _wont actually be faster or scalable(!!!)_

In both cases they end up creating a bottleneck once you start caring about
concurrent access not messing up your data.

Watching Mongo evolve is like watching the past 30 years of rdbms - which
started out as flat text files which were 'fast and simple' \- gaining
indexes, efficient datastructures, foreign keys, disaster recovery etc.

But it's all good, and I can't complain, I make a killing putting out fires
caused by badly architected systems.

~~~
scarface74
_A. Real joins using normalized data_

Then you end up denormalizimg your data anyway in the business layer anyway
because most real world applications work with denormalized data and being a
good DDD person you work with "aggregate roots". With Mongo you can store and
load the whole aggregate root as is without the whole "object relational
impedance mismatch".

 _1\. generates a ton of network congestion from getting the data 2\. ton of
cpu because because json decoding /encoding 3\. ton of cpu because scripting
languages vs optimized C_

I don't use scripting languages. I use C#.

 _4\. the use of O(shit) algorithms to make the joins_

If you're doing a lot of joins with a non relational database, you're doing it
wrong. You should be Store the whole object hierarchy as one document.

If I'm doing joins. I'm using Linq which should be doing joins based on
hashes.

 _5\. inconsistencies when things fail like network or disk or shutdown_

Again you should be storing the whole document with the relationships.

 _B. Redundant data 1\. use a ton of memory /disk 2\. create deferred
overheads in order to keep things sync 3\. despite that, end up with
inconsistent data all over the place_

You're doing it wrong you're using a non relational database like a relational
database.

 _4\. wont actually be faster or scalable(!!!) In both cases they end up
creating a bottleneck once you start caring about concurrent access not
messing up your data._

If you use it like an RDMS it won't be. But if you're storing all of the
related data as a document, using good algorithms when you have to join, it is
faster. How much time do OO programmers spend denormalizing data and using
bloated ORMs?

~~~
zepolen
Sounds like you're married to the fact that data should be an [object].

> How much time do OO programmers spend denormalizing data and using bloated
> ORMs?

OO programmers that try to make data into objects sure. Those are the same
programmers that love document based datastores because they don't have to
think about their data - just get a nice "object" which fits their "everything
must be an object" programming mindset.

Thing is, data _is_ relational, and data _isn 't_ an object.

It's much better to use views of data, eg. "get me what I need to display a
listing page in an eshop" \- which entails getting the price, photos, title,
description, delivery cost etc. - in a single list that you can then use - the
database can do this for you - and all the underlying details are abstracted
away, better yet - your app server will never have to CARE that at some points
product.photos changed from being a simple array of strings to a fully fledged
table - because the view remains the same.

> Again you should be storing the whole document with the relationships.

Okay so you're saving the entire list of 'followers' of a user inside the user
document

What happens when you have a really popular user with a million followers...

What do you do when you update a user who happens to follow thousands of other
users...

Oh you don't do it like that in that case? I guess... you're now relational.

Denormalization only helps with performance up to a certain degree, and in
fact what you save on read access you pay dearly in update access or stupidly
huge extra storage/memory.

~~~
scarface74
_Thing is, data is relational, and data isn 't an object_

Only if you are more concerned with the data first approach instead of
thinking about the domain first.

 _It 's much better to use views of data, eg. "get me what I need to display a
listing page in an eshop" \- which entails getting the price, photos, title,
description, delivery cost etc. - in a single list that you can then use - the
database can do this for you - and all the underlying details are abstracted
away, better yet - your app server will never have to CARE that at some points
product.photos changed from being a simple array of strings to a fully fledged
table - because the view remains the same._

It's only "much better" until everyone wants there own one off view that has
to be kept in sync with the code and reverting/branching/versioning has to
keep in sync with what the hundreds of brittle views, stored procedures, etc.
that are being created. Instead of treating the data store like a dumb data
store. By putting as much logic in the business later as possible. I can not
only branch, version, etc. I can completely unit test my whole application and
mock out the data store.

 _Okay so you 're saving the entire list of 'followers' of a user inside the
user document What happens when you have a really popular user with a million
followers... What do you do when you update a user who happens to follow
thousands of other users..._

Mongo best practices are to think about the orthoganility of your
relationships - one to few, one to many, or "one to quintillions" and choose
whether to embed based on that.

But going back to thinking in terms of DDD an aggregate roots, a user would be
an entity, an address of the user would be a value type that belongs to the
user - embed it into the document. A user's followers would be entities, that
would be a related object that should be able to change independently. In that
case use Mongo references.

 _and all the underlying details are abstracted away, better yet - your app
server will never have to CARE that at some points product.photos changed from
being a simple array of strings to a fully fledged table - because the view
remains the same._

If I'm changing the representation of the data. I still have to change it
somewhere - whether the database -- where you don't have proper versioning,
branching, source control -- or the app server. If you're changing the
representation in the app server in more than one module/microservice, you're
doing it wrong. With a microservice/module, I can still represent the data as
old clients expect by versioning the API and have much better tooling than
have five different versions of the view that never die.

~~~
marktangotango
You are wrong, pure and simple. Please post back here in 5 or 10 years, let us
know how that all worked out for you.

------
partycoder
So far:

\- Takers: mentally healthy people, but heavily biased towards self-benefit
and competition. Never a volunteer, tries to profit from every little
interaction and sees everything as a zero-sum game. Only interjects in a
conversation with the objective of gaining social rank, doesn't see value in
altruism and collaboration, and is rude or dismissive to people considered
lower ranking.

\- Neurotics: people characterized by high anxiety, low tolerance to
frustration, envy, depressed mood, loneliness, etc. In the "Big 5 personality
traits" system, neuroticism plays against any person in any professional
setting.

\- Groupthinkers: people that form cohesive groups that collectively become
biased towards group harmony, becoming incapable of applying critical thinking
in problem solving or having a difficult conversation even if it's in the
collective best interest.

~~~
linkmotif
Really well written. Thank you. I've definitely been the neurotic. Good
learning experience. And I've seen some of the other two groups in other
people.

------
angvp
In my case when I've regretted it was much because the "attitude problem". For
a team of 10 devs (I've recruited all of them), I remember two specifically
cases in which I regretted to hire those guys.

Guy #1:

A "developer" who was trash talking everyone (even me) and then he pretended
he didn't do it or he alleged "I didn't say that", he complained about every
one of his teammates, he pretended and believes that he was a workaholic (but
he failed to be on call when the shit hits the fan). In his very last days at
the company, he was harassing me to give him attention I was swamped of work
and attending useless meetings and I couldn't give him much attention, so he
started sending me whatsapp messages and e-mails at ridiculous hours and
complaining because "I didn't reply his messages", this guy has some issues
IMO.

Guy #2:

A brilliant student (almost summa cum laude in a recognized university), he
was hired for built a parser for several input formats, he needed several
meetings for understanding the problem, he was complaining about technical
decisions so he bring more people to the meetings and he got the same result,
as a developer he's the guy with the ugliest practices that I've seen in my
life, he overengineered everything, he used lot of irrelevant algorithms for
solving silly problems, once I asked to do a silly cronjob to fetch from an
API the exchange rates of 8 different countries and cache them, so he did
build a nodejs app (I asked him to do this in python) that didn't what I
wanted (he built a webservice that given two currencies find the rate), a
script of 10 lines max, he did 400 ugly js lines, but the worst is that those
400 lines were useless for what we wanted to achieve..

My advice when hiring please don't be desperate (guy #2) and always check his
background with their previous employers (guy #1).

With the other 8 guys, I was ok, even if couple of them weren't 100% perfect
(I could add couple of more guys of this team but they weren't so bad) overall
I felt great with the team.

~~~
closed
Serious question--for some reason, I've always believed that previous
employers tend to avoid saying anything negative about their former employees.
Is this not the case?

~~~
oxguy3
This is very much the case. When employees/employers broadcast negative info
about each other, both parties suffer. Obviously, the accused suffers because
all this negative info about them is now public, but the accuser also suffers
because they look like a jerk for publishing it. Who would want to work with a
person/company that is known to talk crap about people they work with?

I think angvp is only publishing this because it's entirely anonymous -- he
hasn't named the two employees in question or his company.

~~~
enjo
I think the question was about the last second to last sentence:

 _" and always check his background with their previous employers (guy #1)."_

~~~
lobotryas
Maybe rules/practices are different in other countries. Never assume that OP
is from US.

------
coralreef
Replace the word developer with plumber, electrician, financial adviser,
mover, etc. and you pretty much sum of the difficulties of relying on outside
help.

------
EliRivers
Interviewee seemed "odd". Stilted interaction during interview. Technical
skills fine enough. Uncommonly, a second interview held with an extra
interviewer brought in.

Technical director asked everyone; everyone said "no hire". Technical director
hired him anyway, allegedly (but not proven) on the grounds of a bizarre,
unshakeable faith in the supremacy of Russian programmers.

About day two, overheard on the phone apparently interviewing for another job.
MD noticed he didn't seem to be doing much; asked if he had some work. "No."
Do you want some? "No."

Gone on day three.

What went wrong? One person permitted to discount everyone else's opinion and
hire a clearly bad candidate anyway, on the grounds of their own personal
prejudices.

~~~
thr0waway1239
Good story, but probably not one answering the question. You only regret
something when you realize you ignored all the bad signs initially. In this
case, your feeling was probably vindication and not regret.

Besides, if this person was only there for 3 days, its almost as if the whole
episode didn't even happen :-)

~~~
EliRivers
_Good story, but probably not one answering the question._

He said: "I'm trying to find out what can go wrong while hiring​ a developer."

I said: "What went wrong? One person permitted to discount everyone else's
opinion and hire a clearly bad candidate anyway, on the grounds of their own
personal prejudices."

------
seehafer
Lack of empathy for the customer is the big thing that has led me to fire
developers in the past

------
philmander
I've regretted hiring a few developers who have been apathetic about the
actual software product we're making.

I am sometimes too optimistic about a technically proficient candidate sharing
these traits, during the interview process.

After hiring they are depressingly unexcited about delivering a new feature
that promises business value, significantly improves performance etc. It's
just work to be done.

~~~
eropple
_> After hiring they are depressingly unexcited about delivering a new feature
that promises business value, significantly improves performance etc. It's
just work to be done._

Well...yeah, it is just work to do, because it's just a job. Turn it around:
why should they be excited about something they have no meaningful ownership
(and I don't mean a few tenths or hundredths of a percent) in?

If the co-founder who owns fifty percent of the company isn't excited, sure,
be worried. If the developer who you value only for work-units provided
doesn't, it's because you haven't created a reason to (and "hard problems"
isn't one; pretty much anybody can find hard problems to work on).

~~~
philmander
I'm not sure what to make of that.

Assuming the product isn't genuinely boring, is it the norm then that
developers without a direct financial incentive in the growth of the company
should just be drones who type code in exchange for a salary?

~~~
tonyedgecombe
Looking at it from the other perspective is it sensible to centre your life on
a job that may not even exist tomorrow?

~~~
philmander
Showing some enthusiasm doesn't mean centering to your life around it

------
navalsaini
I freelance with a lot of startups. I remember times when it did not work out
well for people who hired me and I assume that they regretted hiring me. The
problems were as follows :-

1\. They had very vague requirements and they overcomplicated their MVPs. I
had to charge them by the hour and because the requirements would change,
their costs went up. It was quite difficult for them and I could not really do
much - because they underestimated the development effort it takes and were
overtly confident of their product market fit.

2\. The other being that they were single business cofounders and overvalued
what they brought to the table. Thus they were not able to get onboard tech
cofounders quite soon.

This is from a very startup perspective where many times founders are very
passionate and too optimistic about what they are building.

I think a good way to handle such situations for a developer is to mentor them
early on and built trust with them; so that they let you help them simplify
their MVP goals.

Also I think for the hirer, building trust with a developer who has the
understanding of the product would be great. As a hirer, if you can gauze that
s/he is truly curious about the product - would be good. You cannot expect
them to buy into it; and it is more likely that they will have a lot of doubts
about the product offering initially. It could take a while for a developer to
buy into the offerings of a product vis/vis the risks involved.

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

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

------
aisofteng
About a year or so into my professional career and in the second position I
ever had, I was asked to help interview candidates who had passed some initial
screening which consisted of asking the candidate about their resume, but,
importantly, no programming or whiteboard test. The company I was working for
was a multibillion dollar corporation in a non-tech industry (think something
like healthcare or petrochemical), and I was working in its headquarters. The
following happened in a US state that, shall we say, does not have a
reputation for being very progressive, and that definitely is on the extreme
end of gender imbalance in tech.

The interviewee was a young woman who has just graduated from a reputable
engineering school (~top 10 private engineering school). This was the first
time I had interviewed anyone, so I let my two colleagues, the CIO and the
director of network engineering, handle most of it. She answered their
questions about her school experience reasonably; when they seemed to be
slowing down, I asked a couple questions of my own:

1\. "Do you follow any tech news outlets or social media sites?", which seemed
to confuse her and ended up being answered with a sheepish "no, not really."

2\. "Can you give us an example of something you've coded for fun? It doesn't
have to be a big project and it doesn't have to be particularly recent -
whatever comes to mind." She hesitated for a long time on this one, and said
she had set up a server at home for storing cooking recipes. When I asked her
what server software she used, she said she didn't remember, which led me to
suspect she made this up (how can you install Apache/nginx/other, configure
it, use it, and then forget what server software you used?)

When discussing the interview with my colleagues, I was surprised to find them
both immediately wanting to hire her. Having been at this company for under
six months, I didn't want to be the naysayer, so, while I expressed my
reservations - namely, that the position she was being considered for required
someone who had a passion for programming and that she didn't seem like
someone that does - I said that I didn't feel strongly enough to want to veto
and would defer to their judgement. (I mentioned earlier that this was in a
state with an extreme gender imbalance; I privately suspected that, having no
women on the development team, they very much wanted to hire a woman for the
sake of hiring a woman, but of course did not voice this. My suspicion was
also based on my being asked much more involved questions during my interview,
as compared to essentially none for her and no follow-up questions being asked
about her responses to any questions she did receive.)

We hired her, and we started her off with what should have been relatively
simple tasks. She could not complete any of them; this, in and of itself, is
fine, because it is to be expected that someone hired out of school would
require at least some amount of training. However, she would not ask for help
when stuck, even after being repeatedly encouraged to do so and my personally
saying I remember being in the same position as her and that it is normal to
do so. This is also pretty normal for someone in their first professional
position. However, she never knew how to get started on any task, never asked
for help, and never remembered anything I tried to teach her. More than once,
I walked into her office to ask about her progress on an assigned issue only
to find her doing literally nothing - not coding, not looking anything up on
Google/StackOverflow, not even on Facebook, but literally sitting at her desk,
staring at her monitor with no windows open of any kind, with her hands folded
on her lap. How a person could do that for eight hours, I don't know.

After two months of this and finding that she seemed to be literally unable to
write code, we gave up trying to train her. We didn't fire her, but we moved
her to a QA team; her job was to be given a script with a specific list of
steps to execute and to report back if any step failed. In my mind, this is
tantamount to firing her from a software development position.

I have some takeaways from this experience for myself and can tell them if
anyone is interested, but they are not directly relevant to OP's question.

~~~
id122015
But dont you find it ridiculous that employers get what they ask for. They ask
for degrees, they get people with degrees. I looked just now for some jobs
that I could do and they ask for degrees.

The reason I dropped out of a top 10 global engineering university was because
I saw right there that it didnt teach me programming. So I learnt on my own. I
recently applied for my first job, and its that type of job where its good to
have progrmming skils but not mandatory. I'm so interested to see if I'll get
an interview at least, cause hiring is broken.

~~~
brianwawok
But you are missing the case of both a degree and good programming skills. If
two programmers code equally, why wouldn't I hire the guy with the degree?
That took the algorithm classes and took the writing class and has more tools
in his toolbox than coding?

It's ok you don't have a degree but not sure why you would be shocked that
some prefer college graduates

~~~
charlesdm
Why would you pick the one with a degree? If two developers are of equal
technical ability, I would honestly pick the one with better social skills
over the one with a degree.

~~~
brianwawok
You are implying there is a downside. In my example they are the same in all
aspects you measure.

~~~
Nuzzerino
Since all other things are equal, the solution is simple. The person with the
degree is more likely to have student loan debt, so a salary of X dollars per
year will go further in the case of the one without the debt. The person with
the debt is more likely to require more money for the same level of
satisfaction.

All other things being equal, of course.

~~~
always_good
Seems like you're really stretching it.

The one that went to uni probably got laid a lot more, too. So as they're
working in an office space with no women and possibly not meeting any women on
the side, they are less likely to have a social crisis when they're working
their 60th hour of the week.

This is kind of fun!

------
late2part
Joel Spolsky's Guerilla Guide to Interviewing lays out the rational for two
simple filters:

1\. Is the person smart?

2\. Can they get stuff done?

Good read.

[https://www.joelonsoftware.com/2006/10/25/the-guerrilla-
guid...](https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-
interviewing-version-30/)

------
donovanm
I haven't (since I'm not in charge of hiring), but I've had to work with
multiple people that simply couldn't code to save their lives which was quite
frustrating.

------
yuhong
This reminds me that the laws for firing vary by state. I think California is
one of the strictest in this area, right?

~~~
late2part
Generally these sort of discussions are not focused on the laws about firing -
but more about the risk of valid or invalid accusations of violating EEOC
enforced laws[1].

The risk in most places is that firing is often subjective, and folks rightly
worry that the firing is done on subjective means, especially if the person is
a 'protected class' which is generally loosely interpreted as anyone other
than a white male under 40.

There are rules and laws that govern firings, especially with large layoffs at
large companies - but the 'fear' you hear in Silicon Valley and other places
is the fear of a lawsuit about the firing more so than breaking a law per se.

[1] [https://www.eeoc.gov/laws/statutes/](https://www.eeoc.gov/laws/statutes/)

~~~
yuhong
Yea, I dislike anti-discrimination laws too for that reason. They probably
worked well for manual labor and the like. Don't forget "performance reviews"
and "PIPs" too.

~~~
late2part
We do quarterly performance reviews. We give and get candid feedback.

I've never put someone on a PIP with the intention of firing them. I've never
fired someone that was reasonably surprised.

When I put someone on a PIP it's because they choose not to listen to what
needs to be done, and I desperately hope that a super formal message will get
it across.

------
omidfi
wow so many nice comments. Thanks, I'll try to digest these and probably come
up with a summary.

------
partisan
The employee knows about all of the parts of a standard application and can
speak to them, but cannot put them together without hours of coaching and
discussion. Or the inability to make the right decision when presented with
information. Or to fail to ask questions when presented with an unknown,
instead making the wrong decision.

When presented with a standardized solution that is formalized and utilized
across the entire application, will either implement a new, inadequate
solution or keep asking around the senior members of the team until someone,
given a small enough slice of the problem set, is coerced into validating the
inadequate solution, usually devolving into wasteful group meetings on said
topic.

When asked to following the standard conventions of the large codebase he or
she is now working in, decides to implement new folder hierarchies, naming
conventions and to litter the code with unnecessary common functions, copied
and pasted code blocks, large commented blocks, all of these against the
communicated and often repeated standards of the application.

\---

I initially took it as an affront. Most of the standards were being ignored or
questioned by this person. And I had regrets about hiring them.

Having had some time to consider the problem, I think that part of the issue
is that the person comes from a background where they were in a "get things
done" frame of mind. Technology was the means to an end and never a first
class citizen. And they were the only programmer. And they had major business
responsibilities as well.

Being the sole programmer of an organization leaves you in a very isolated
position, unable to learn about new standards and technologies unless you
actively seek them out. If you are getting things done, well then all is well
with you and your skill set. You clearly have the right answers because things
are working.

I believe that someone coming from that type of background is likely to need
to reframe the world in the way they have known it, unable to accept new
standards. They are lost without being able to anchor themselves in their old
conventions. They are likely to accept the first working solution, because the
code is not an asset, it's a tool. Copying and pasting are a savings in the
short term. Commented out code is an artifact of their results-driven
development process.

\---

I agree that there are times when you just have to fire someone, but that is
not always the only option on the table. Sometimes you can work with what you
have by understanding why things are they way they are.

In order to get the best value out of this person, I try to capitalize on
their strengths by assigning tasks that I am comfortable letting them own.
They have a niche, and they call the shots in that niche. They are empowered
and in control of their own domain again.

When I find that they are deviating from our standards, I convey the reasoning
for the standards, but I do so in the form of questions that lead the person
to arrive to the right conclusions. In this way, they are deriving the right
answers and they own that reasoning. The old way is no longer necessary
because the new way makes sense to them now.

And it gets better.

