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.
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.
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.
For a startup, sure. But the machine doing LASIK surgery on a human's cornea dozens of times per day absolutely should have a perfect coder. There are some industries where sloppy code should get you fired, because it will get someone killed.
People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time.
If you're building life support software or manned lunar probes, maybe you want him on your team.
If you're a startup trying to find product-market fit before you run out of funding, better to ship a few bugs every week (in features that have an 80% chance of not existing or being rewritten anyway within a few years) than nothing at all for months.
Does that actually work? I've never had anybody ask me for references for a technical job. Few people are going to say anything bad about a former employee for fear of being sued. And that's if the candidate plays fair. For less than $100, you can bribe three people to say you're the next best thing to Steve Jobs himself.
It works great! I agree that we're unusual in the weight that we put in our references, but I've never had it be a blocker with an applicant. We run every reference through the same script of questions, for a call that tends to last about 30 minutes. Since many engineers often talk in interviews about what their team did, versus their own contributions, the third-party viewpoint is very helpful for getting that perspective. We've found references to be helpful in differentiating between average, good, great, and exceptional individual performance, and extremely helpful in understanding a candidate's teamwork. I personally find it vastly more useful than whiteboard coding and work samples for predicting how a candidate will actually perform.
Aside from their usefulness in making hiring decisions, as a manager, it has been great for jump-starting my relationship with my new hires with context on how they have worked in the past. That has been really helpful.
I agree with you that references have some limitations. We do, of course, expect that applicants will cherry-pick their references to make themselves shine. Yet, I typically get very candid feedback from the reference providers. I think most people simply aren't built to straight-up lie for someone else, even if they are a friend. References are typically someone in some level of authority someplace else, and they put their word on the line. Most people seem to take that seriously.
Another limitation is that people often can't use their current boss as a reference, and for people on an upward career trajectory, that may exclude someone who is capable of talking about the applicant's greatest career achievements. This was the case for me when I applied to my current role.
Lastly, we have to keep in mind that any single reference is colored by the biases and personality of its provider. And some applicants simply have access to better referrers than others for reasons out of their control. All we can do is make judgment calls when it comes to these things.
See my other response for more context, but we have a behavioral interview-style reference call script, which is universal for all roles at the company. But it still does tend to reveal good knowledge about the candidate's technical ability, even with generic questions. Occasionally, I'll add an additional question for tech context, but I find the basic script to be pretty comprehensive.
I'll echo the sibling post for inexperienced candidates. References from jobs in other careers also work. But to be honest, if someone can't find anyone to speak in-depth about their achievements and teamwork, they are going to have a really tough time passing the bar to get hired. We don't generally do work samples of any kind, but I'd probably have to make an exception in that case, to get some kind of picture for how they work.
We've certainly had a couple people not work out on our engineering team. But I don't think we've ever hired a total dud or a toxic person.
It's interesting that you mention internal referrals, because I think that can be a major source of bias. People feel obligated to put in a good word for their friend, and if I hold the referrer in high personal regard, my natural skepticism of them as a reference diminishes. I feel referrers should say their (small) piece at the beginning, but from that point onward, the hiring process needs to be independent of their influence.
It's definitely fair to check this. Also I think this works very well when the hire worked in a well-ordered place beforehands. On the contrary, if someone worked at a toxic work place before - it's probably counterproductive to ask colleagues or even managers. Odds are high the person is exactly leaving because of that.
I will only take a contract position if that's the only way I can get a job doing something I know academically -- I studied the technology and did a side project -- but don't have any on the job experience.
I agree. Good ones always have good options. I avoid contract to hire, because even a talented developer who chooses to stay as contractor will avoid contract-to-hire positions.
I guess you just have to go with who you think is the best candidate, and if the decision turns out to be incorrect, fire quickly.
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
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.
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.
"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.
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.
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.
>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.
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.
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.
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.
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.
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.
Seriously, I was surprised to find that Splunk uses Mongo. Given its performance and reliability with Splunk, I'm willing to give Mongo another chance given the right conditions (given that someone on my team has significant experience administering it).
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.
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.
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?
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.
Flip side with the mentorship thing is not blocking out the senior dev's time to do the mentoring.
If the senior dev is supposed to mentor his junior teammates with no impact on the number of story points he grinds through then it's not reasonable for him to relish the thought of spending time peering with colleagues that he'll have to make up after hours.
> 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.
But we operate in a marketplace that wants to hire people based on their tech stack. So to keep their skills up they have to push for their stack.
Despite your use as a pejorative, 10x is real. Developers who pound out mountains of spaghetti in whatever stack they want ignoring maintainability and best practices? I've heard the phrase "cowboy coders", or asshole works too.
- 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.
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.
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.
> 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"
Sorry, but this doesn't sound so horrible on his part. Are "useless" meetings more important than getting work done at your company?
Well, those meetings were useless, but as I said first he just wanted to trash talk about other people (he wasn't calling for attention to show me work, I used to sync up with him about work frequently), and those meetings even useless were much important than listening crap like .. "I couldn't connect all the day to the network, somebody banned my mac address" (that wasn't true of course, he just had issues on his environment but instead of think of that, he was paranoid about someone on the team hacking him or something)
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?
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.
> but the accuser also suffers because they look
> like a jerk for publishing it
Or the accused now goes "well, I wasn't going to say anything, but here are all the things I didn't like about you."
Somewhat related, but this is one of the reasons for 5-star inflation in feedback systems like Airbnb.
I recently saw this exchange in a review:
Host: The guest kept the windows open with the A/C on full blast the whole time.
Guest: lol, you were spying on me? I wasn't going to say anything, but your place smelled like human feces.
Looks pretty bad for both parties and not something you want in your history, so my experience with Airbnb is that people give good ratings except for the worst of conditions. I think as far as Airbnb cares, it's working as intended. Everything looks peachy.
They don't usually trash former employees, but you can read between the line.
One time a reference given by the candidate for a senior post glossed over everything but focused on attendance. "He is a good guy. He is always on time for work and very punctual for meetings."
Well, after Guy #1 left the company I met a former colleague of him on other company, and she told me "why you didn't call us? we would advise you to not hire this guy!" so that's where my assumption came from, you're right, there are probably people that will hide the truth just to be diplomatic.
Replace the word developer with plumber, electrician, financial adviser, mover, etc. and you pretty much sum of the difficulties of relying on outside help.
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.
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 :-)
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."
[s]he regrets the hiring of the developer. And if they're hired at all and then leave quickly, that's an awful lot of money (even it was all in people's time) wasted.
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.
> 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).
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?
Being strictly professional and capable and executing on a problem has nothing to do with being a "drone". Developers should be looking out strictly and exclusively for their own interests, just as the company that employs them does. Excitement and enthusiasm are tools used to get a better deal on behalf of the company than the company deserves, and that's literally it.
There's also something to be said about a salary. A good salary isn't something to scoff at. If someone paid me a lot of money, and the product and underlying technologies were interesting, and I didn't have any business ideas myself at the time, I would feel odd not having any enthusiasm about the job.
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.
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.
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. :)
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.
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.
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.
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
> 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.
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.
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.
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.
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
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.
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.
I think here the main issue was that the company hired programmers without any kind of actual technical screening. It kind of seems quite likely that in this case they would end up hiring developers, that they would come to regret later.
Questions like what you code for fun or what technical sites you browse are all fine as supplementary discussion points, but they are in no ways going to be indicative of whether the person knows how to code, unless you actually ask them to code.
Did she have a CS degree? I find it hard to believe someone with a CS degree from a top school could float through w/o being able to code at all. Why would you apply for a job you know you couldn't hit the ground running and then not try at all?
I've seen many CIS-type grads not know squat and still be able to churn out something.
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.
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.
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.
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.
This reminds me that the laws for firing vary by state. I think California is one of the strictest in this area, right?
Actually, quite the opposite -- California is an "at-will" state.
From the website of an attorney who deals with employment issues in California [0]:
In the state of California, an employment relationship with no specified duration is considered to be employment “at-will.” This means that under California at-will employment laws both California employers and employees can terminate an employment relationship at any time, for any reason.
From another California law firm dealing with these issues [1]:
If you are an at-will employee, you can be fired or demoted on a whim, without warning, with no due process, for no reason at all, or even for a false reason.
There is some nuance though (back to the first site [0]):
However, while your employer may not need a “good” reason to fire you, there are exceptions to the at-will rule, including employment contracts that say an employee can only be fired “for cause,” or union agreements that lay out circumstances in which you can be fired. Because of these exceptions and others, California employees should always examine employment contracts, employee handbooks, and policies closely to find out what their employee rights actually entail under their contractual agreements.
The second site [1] goes into some detail:
California workers are loaded with rights. There are a million wrongful termination attorneys in California; they must be doing something. Because while you can be fired for no reason or even a made-up reason, the law also states that you cannot be discriminated against or fired or have any negative job action taken against you for a reason that violates public policy.
A long list of things that are illegal to use for firing, e.g. race, religion, gender, pregnancy, etc. follows and then the page continues:
These are the grounds for a discrimination claim, but there are many more public policy violations that would make a termination wrongful. For example, an employee can't be fired for serving on jury duty, or voting, or for trying to form a union, or for taking a leave under the Family Medical Leave Act (FMLA), or for filing a workers compensation claim. The list goes on and on. (In that regard, be glad you live in California. In some states, there is no public policy exception to the at-will rule.)
So, TL;DR:
California is an at-will state, meaning you can be fired at the drop of a hat, but there are certain protections you get automatically and certain things one may be able to do to protect oneself (e.g. getting an employment contract that specifies one can only be fired "for cause").
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.
- 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.