Ask HN: Have you ever regretted hiring a developer?
I'm trying to find out what can go wrong while hiring a developer. What might cause that?
Lack of technical skills? Or attitude problems?
- 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.
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.
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 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.
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.
Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.
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.
Now, it is easier to influence new professionals than changing habits of seasoned professionals.
I'm not a world class developer, but I'm a good one, maybe great depending on the day but I had 3 offers to be contract to hire and I refused.
You may save yourself a bad hire, but more than likely you will do so at the cost of missing out on hiring a handful of good ones.
If I'm interviewing with you and you don't trust me enough to make me an employee from day one then why should I trust you as a company?
Basically, a resume builder
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.
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.
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.
weak e.g. http://www.inc.com/jeff-haden/5-ways-to-ask-the-perfect-ques...
Why didn't you guys fire him? Why did you just let him stagnate until he quit?
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.
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...
How to Win Friends and Influence People: https://www.amazon.com/How-win-friends-influence-people-eboo...
Emotional Intelligence: https://www.amazon.com/dp/B000JMKVCG/
>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.
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.
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.
You're right,this is new for me. But fortunately I'm not making decisions, or managing people at the moment. I'm just learning.
I'll check out the books.
Developers who don't have empathy for less experienced team members; who can't/won't mentor well.
- 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).
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.
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?
> 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.
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.
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.
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.
- 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.
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.
Sorry, but this doesn't sound so horrible on his part. Are "useless" meetings more important than getting work done at your company?
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
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.
"and always check his background with their previous employers (guy #1)."
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."
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.
Besides, if this person was only there for 3 days, its almost as if the whole episode didn't even happen :-)
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."
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.
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?
I know quite a few devs that would be like that if they had to work on something like a legacy J2EE webapp.
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.
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.
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.
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
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.
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.
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.
It's ok you don't have a degree but not sure why you would be shocked that some prefer college graduates
All other things being equal, of course.
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!
However I suspect there is very little rationality in hiring, even amongst this community.
Also, the definition of insanity is to do the same thing and expect different results.
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.
I've seen many CIS-type grads not know squat and still be able to churn out something.
1. Is the person smart?
2. Can they get stuff done?
Good read.
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
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.
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.
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").
[0] http://employmentattorneyla.com/california-at-will-employmen...
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.