11 ms·

Ask HN: Have you ever regretted hiring a developer?

84 points by omidfi 10y ago

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?

49531 10y ago
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.
coralreef 10y ago
Replace the word developer with plumber, electrician, financial adviser, mover, etc. and you pretty much sum of the difficulties of relying on outside help.
dougireton 10y ago
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.
- hliyan 10y ago
  Unfortunately, this describes a substantial percentage of "10x" engineers...
  - marktangotango 10y ago
    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.
    - hliyan 10y ago
      Perhaps we ought to normalize the scale and call the other variety 0.1x engineers.
- jordanb 10y ago
  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.
- bbcbasic 10y ago
  > 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.
- zepolen 10y ago
  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.
  - jkmcf 10y ago
    You sound like my twin. Wait, are you me? 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).
  - scarface74 10y ago
    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.
deleted 10y ago
[deleted]
seehafer 10y ago
Lack of empathy for the customer is the big thing that has led me to fire developers in the past
aisofteng 10y ago
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.
EliRivers 10y ago
Interviewee seemed "odd". Stilted interaction during interview. Technical skills fine enough. Uncommonly, a second interview held with an extra interviewer brought in. Technical director asked everyone; everyone said "no hire". Technical director hired him anyway, allegedly (but not proven) on the grounds of a bizarre, unshakeable faith in the supremacy of Russian programmers. About day two, overheard on the phone apparently interviewing for another job. MD noticed he didn't seem to be doing much; asked if he had some work. "No." Do you want some? "No." Gone on day three. What went wrong? One person permitted to discount everyone else's opinion and hire a clearly bad candidate anyway, on the grounds of their own personal prejudices.
- thr0waway1239 10y ago
  Good story, but probably not one answering the question. You only regret something when you realize you ignored all the bad signs initially. In this case, your feeling was probably vindication and not regret. Besides, if this person was only there for 3 days, its almost as if the whole episode didn't even happen :-)
  - EliRivers 10y ago
    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."
  - rikkus 10y ago
    [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.
wanderr 10y ago
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.
cauterized 10y ago
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.
- acjohnson55 10y ago
  That's one reason we rely heavily on thorough, structured reference checks.
  - cauterized 10y ago
    How do you structure your reference checks? And what do you do for new hires who are very early in their careers and don't have real work references? Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.
    - partycoder 10y ago
      References from internship colleagues/managers, school mates or teachers can work a bit. But be aware that you will be getting very few data points. Now, it is easier to influence new professionals than changing habits of seasoned professionals.
angvp 10y ago
In my case when I've regretted it was much because the "attitude problem". For a team of 10 devs (I've recruited all of them), I remember two specifically cases in which I regretted to hire those guys. Guy #1: A "developer" who was trash talking everyone (even me) and then he pretended he didn't do it or he alleged "I didn't say that", he complained about every one of his teammates, he pretended and believes that he was a workaholic (but he failed to be on call when the shit hits the fan). In his very last days at the company, he was harassing me to give him attention I was swamped of work and attending useless meetings and I couldn't give him much attention, so he started sending me whatsapp messages and e-mails at ridiculous hours and complaining because "I didn't reply his messages", this guy has some issues IMO. Guy #2: A brilliant student (almost summa cum laude in a recognized university), he was hired for built a parser for several input formats, he needed several meetings for understanding the problem, he was complaining about technical decisions so he bring more people to the meetings and he got the same result, as a developer he's the guy with the ugliest practices that I've seen in my life, he overengineered everything, he used lot of irrelevant algorithms for solving silly problems, once I asked to do a silly cronjob to fetch from an API the exchange rates of 8 different countries and cache them, so he did build a nodejs app (I asked him to do this in python) that didn't what I wanted (he built a webservice that given two currencies find the rate), a script of 10 lines max, he did 400 ugly js lines, but the worst is that those 400 lines were useless for what we wanted to achieve.. My advice when hiring please don't be desperate (guy #2) and always check his background with their previous employers (guy #1). With the other 8 guys, I was ok, even if couple of them weren't 100% perfect (I could add couple of more guys of this team but they weren't so bad) overall I felt great with the team.
- closed 10y ago
  Serious question--for some reason, I've always believed that previous employers tend to avoid saying anything negative about their former employees. Is this not the case?
  - oxguy3 10y ago
    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.
samblr 10y ago
In interview what appeared to be a potential-hire's strength - became a real nuisance when we hired him. We wanted someone who could do both android and iOS. He was a senior, had enough to showcase and plenty to 'talk about software architectural things'. It turned out, he was jack of all trades (python, java, objective-c) but he really-really struggled at designing software but he could talk through people and walls. And then he formed a bad habit of mailing in out-of-hours to group that somebody's else code has this problem - how to fix, so on and so forth. Initially we didn't know of what to make of it. He could small bug-fixes ok. Then we assigned a good chunk of work in new project. And boy, did he create a mess of it. Since he was lagging behind from dates assigned - we sat for a code-design-review. I sat in horror that day on how confidently he was presenting to what was not even a freshman's work. He didn't have a clue on why blocking calls should not be made on UI thread. We didn't give any good work to him later. He left us soon and last time I checked - he was a CTO of a mobile development shop! N
- Spooky23 10y ago
  Sometimes people like that are better in leadership roles. Knowing a little about a broad scope of things is very useful in those roles.
  - late2part 10y ago
    Managers that can't do are generally shepherds. Only sheep follow them. Yes, it's good that managers can know a lot about a broad amount, but they should be skilled enough to dive fairly deep and realistically be expected to jump into anyone's job. Otherwise, you're hiring an administrator or a non-technical manager. And there's a place for that, but not one I want to be near.
    - scarface74 10y ago
      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.
philmander 10y ago
I've regretted hiring a few developers who have been apathetic about the actual software product we're making. I am sometimes too optimistic about a technically proficient candidate sharing these traits, during the interview process. After hiring they are depressingly unexcited about delivering a new feature that promises business value, significantly improves performance etc. It's just work to be done.
- eropple 10y ago
  > After hiring they are depressingly unexcited about delivering a new feature that promises business value, significantly improves performance etc. It's just work to be done. Well...yeah, it is just work to do, because it's just a job. Turn it around: why should they be excited about something they have no meaningful ownership (and I don't mean a few tenths or hundredths of a percent) in? If the co-founder who owns fifty percent of the company isn't excited, sure, be worried. If the developer who you value only for work-units provided doesn't, it's because you haven't created a reason to (and "hard problems" isn't one; pretty much anybody can find hard problems to work on).
  - philmander 10y ago
    I'm not sure what to make of that. Assuming the product isn't genuinely boring, is it the norm then that developers without a direct financial incentive in the growth of the company should just be drones who type code in exchange for a salary?
    - eropple 10y ago
      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.
    - tonyedgecombe 10y ago
partycoder 10y ago
So far: - Takers: mentally healthy people, but heavily biased towards self-benefit and competition. Never a volunteer, tries to profit from every little interaction and sees everything as a zero-sum game. Only interjects in a conversation with the objective of gaining social rank, doesn't see value in altruism and collaboration, and is rude or dismissive to people considered lower ranking. - Neurotics: people characterized by high anxiety, low tolerance to frustration, envy, depressed mood, loneliness, etc. In the "Big 5 personality traits" system, neuroticism plays against any person in any professional setting. - Groupthinkers: people that form cohesive groups that collectively become biased towards group harmony, becoming incapable of applying critical thinking in problem solving or having a difficult conversation even if it's in the collective best interest.
- linkmotif 10y ago
  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.
RidingQwerty 10y ago
You're not a tech company, you build human traps. Now you know why you have "culture fit" problems with talent. https://www.youtube.com/watch?v=C0Y4uzaf2HA https://www.youtube.com/watch?v=C0Y4uzaf2HA
wheelerwj 10y ago
This is an interesting question, because it signals that you are most likely very new to hiring, and maybe ill-equipped to handle managing people in general. Although, at least you're asking questions. First, very rarely does a manager regret a hire even though it's very common for a hire not to work out. Hiring and interviewing are in terrible shape right now, and more often then not lead to terrible hiring/job acceptance choices. Second, you regret hiring PEOPLE, not developers because regrettable hires aren't specific to developers. When they are, it's because an engineer was given too much access to something they should not have been and a theft/breach occurs. Examples of these concepts in play: The NSA probably regrets hiring Edward Snowden. I don't regret hiring the last JS dev I hired even though it didn't work out and he moved to a different company. Lack of technical expertise is a problem sometimes, but it can be nurtured. Lack of personal skills is a huge problem in an office environment, and is much, much harder to nurture. But neither of these are regrettable in-and-of themselves. The thing to remember is that you have to weigh the urgency of hiring against the long term impacts of hiring the wrong person. In other words, be careful and set up controls, but don't allow decision paralysis. Good luck with your project, keep your head up, and expect failure. Great employees are rare, so just keep at it. post mobile edit: Go read: Good To Great: https://www.amazon.com/Good-Great-Some-Companies-Others/dp/0066620996 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-ebook/dp/B01H38S9FY https://www.amazon.com/How-win-friends-influence-people-eboo... Emotional Intelligence: https://www.amazon.com/dp/B000JMKVCG/ https://www.amazon.com/dp/B000JMKVCG/
- blablabla123 10y ago
  >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.
YouDeserveThis 10y ago
If you're having problems with finding technology workers, consider the idea that you're not a tech company. You build human traps. That's why you are getting the talent you are getting. You don't need programmers. You need digital plumbers. TRIGGER WARNING: This guy is a super big evil meanie who needs rainbows and huggie hugs..... but he's not wrong when it comes to who you attract and why you attract them: https://www.youtube.com/watch?v=C0Y4uzaf2HA https://www.youtube.com/watch?v=C0Y4uzaf2HA
yuhong 10y ago
This reminds me that the laws for firing vary by state. I think California is one of the strictest in this area, right?
- late2part 10y ago
  Generally these sort of discussions are not focused on the laws about firing - but more about the risk of valid or invalid accusations of violating EEOC enforced laws[1]. The risk in most places is that firing is often subjective, and folks rightly worry that the firing is done on subjective means, especially if the person is a 'protected class' which is generally loosely interpreted as anyone other than a white male under 40. There are rules and laws that govern firings, especially with large layoffs at large companies - but the 'fear' you hear in Silicon Valley and other places is the fear of a lawsuit about the firing more so than breaking a law per se. [1] https://www.eeoc.gov/laws/statutes/ https://www.eeoc.gov/laws/statutes/
  - yuhong 10y ago
    Yea, I dislike anti-discrimination laws too for that reason. They probably worked well for manual labor and the like. Don't forget "performance reviews" and "PIPs" too.
    - late2part 10y ago
      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.
- qohen 10y ago
  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"). [0] http://employmentattorneyla.com/california-at-will-employment/ http://employmentattorneyla.com/california-at-will-employmen... [1] http://www.atwillinfo.com/ http://www.atwillinfo.com/
late2part 10y ago
Joel Spolsky's Guerilla Guide to Interviewing lays out the rational for two simple filters: 1. Is the person smart? 2. Can they get stuff done? Good read. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
partisan 10y ago
The employee knows about all of the parts of a standard application and can speak to them, but cannot put them together without hours of coaching and discussion. Or the inability to make the right decision when presented with information. Or to fail to ask questions when presented with an unknown, instead making the wrong decision. When presented with a standardized solution that is formalized and utilized across the entire application, will either implement a new, inadequate solution or keep asking around the senior members of the team until someone, given a small enough slice of the problem set, is coerced into validating the inadequate solution, usually devolving into wasteful group meetings on said topic. When asked to following the standard conventions of the large codebase he or she is now working in, decides to implement new folder hierarchies, naming conventions and to litter the code with unnecessary common functions, copied and pasted code blocks, large commented blocks, all of these against the communicated and often repeated standards of the application. --- I initially took it as an affront. Most of the standards were being ignored or questioned by this person. And I had regrets about hiring them. Having had some time to consider the problem, I think that part of the issue is that the person comes from a background where they were in a "get things done" frame of mind. Technology was the means to an end and never a first class citizen. And they were the only programmer. And they had major business responsibilities as well. Being the sole programmer of an organization leaves you in a very isolated position, unable to learn about new standards and technologies unless you actively seek them out. If you are getting things done, well then all is well with you and your skill set. You clearly have the right answers because things are working. I believe that someone coming from that type of background is likely to need to reframe the world in the way they have known it, unable to accept new standards. They are lost without being able to anchor themselves in their old conventions. They are likely to accept the first working solution, because the code is not an asset, it's a tool. Copying and pasting are a savings in the short term. Commented out code is an artifact of their results-driven development process. --- I agree that there are times when you just have to fire someone, but that is not always the only option on the table. Sometimes you can work with what you have by understanding why things are they way they are. In order to get the best value out of this person, I try to capitalize on their strengths by assigning tasks that I am comfortable letting them own. They have a niche, and they call the shots in that niche. They are empowered and in control of their own domain again. When I find that they are deviating from our standards, I convey the reasoning for the standards, but I do so in the form of questions that lead the person to arrive to the right conclusions. In this way, they are deriving the right answers and they own that reasoning. The old way is no longer necessary because the new way makes sense to them now. And it gets better.
navalsaini 10y ago
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.
omidfi 10y ago
wow so many nice comments. Thanks, I'll try to digest these and probably come up with a summary.
donovanm 10y ago
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.

84 points by omidfi 10y ago

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?

49531 10y ago

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.

coralreef 10y ago

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

dougireton 10y ago

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.

hliyan 10y ago
Unfortunately, this describes a substantial percentage of "10x" engineers...
- marktangotango 10y ago
  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.
  - hliyan 10y ago
    Perhaps we ought to normalize the scale and call the other variety 0.1x engineers.
jordanb 10y ago
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.
bbcbasic 10y ago
> 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.
zepolen 10y ago
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.
- jkmcf 10y ago
  You sound like my twin. Wait, are you me? 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).
- scarface74 10y ago
  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.

deleted 10y ago

[deleted]

seehafer 10y ago

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

aisofteng 10y ago

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.

EliRivers 10y ago

Interviewee seemed "odd". Stilted interaction during interview. Technical skills fine enough. Uncommonly, a second interview held with an extra interviewer brought in. Technical director asked everyone; everyone said "no hire". Technical director hired him anyway, allegedly (but not proven) on the grounds of a bizarre, unshakeable faith in the supremacy of Russian programmers. About day two, overheard on the phone apparently interviewing for another job. MD noticed he didn't seem to be doing much; asked if he had some work. "No." Do you want some? "No." Gone on day three. What went wrong? One person permitted to discount everyone else's opinion and hire a clearly bad candidate anyway, on the grounds of their own personal prejudices.

thr0waway1239 10y ago
Good story, but probably not one answering the question. You only regret something when you realize you ignored all the bad signs initially. In this case, your feeling was probably vindication and not regret. Besides, if this person was only there for 3 days, its almost as if the whole episode didn't even happen :-)
- EliRivers 10y ago
  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."
- rikkus 10y ago
  [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.

wanderr 10y ago

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.

cauterized 10y ago

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.

acjohnson55 10y ago
That's one reason we rely heavily on thorough, structured reference checks.
- cauterized 10y ago
  How do you structure your reference checks? And what do you do for new hires who are very early in their careers and don't have real work references? Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.
  - partycoder 10y ago
    References from internship colleagues/managers, school mates or teachers can work a bit. But be aware that you will be getting very few data points. Now, it is easier to influence new professionals than changing habits of seasoned professionals.

angvp 10y ago

In my case when I've regretted it was much because the "attitude problem". For a team of 10 devs (I've recruited all of them), I remember two specifically cases in which I regretted to hire those guys. Guy #1: A "developer" who was trash talking everyone (even me) and then he pretended he didn't do it or he alleged "I didn't say that", he complained about every one of his teammates, he pretended and believes that he was a workaholic (but he failed to be on call when the shit hits the fan). In his very last days at the company, he was harassing me to give him attention I was swamped of work and attending useless meetings and I couldn't give him much attention, so he started sending me whatsapp messages and e-mails at ridiculous hours and complaining because "I didn't reply his messages", this guy has some issues IMO. Guy #2: A brilliant student (almost summa cum laude in a recognized university), he was hired for built a parser for several input formats, he needed several meetings for understanding the problem, he was complaining about technical decisions so he bring more people to the meetings and he got the same result, as a developer he's the guy with the ugliest practices that I've seen in my life, he overengineered everything, he used lot of irrelevant algorithms for solving silly problems, once I asked to do a silly cronjob to fetch from an API the exchange rates of 8 different countries and cache them, so he did build a nodejs app (I asked him to do this in python) that didn't what I wanted (he built a webservice that given two currencies find the rate), a script of 10 lines max, he did 400 ugly js lines, but the worst is that those 400 lines were useless for what we wanted to achieve.. My advice when hiring please don't be desperate (guy #2) and always check his background with their previous employers (guy #1). With the other 8 guys, I was ok, even if couple of them weren't 100% perfect (I could add couple of more guys of this team but they weren't so bad) overall I felt great with the team.

closed 10y ago
Serious question--for some reason, I've always believed that previous employers tend to avoid saying anything negative about their former employees. Is this not the case?
- oxguy3 10y ago
  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.

samblr 10y ago

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

Spooky23 10y ago
Sometimes people like that are better in leadership roles. Knowing a little about a broad scope of things is very useful in those roles.
- late2part 10y ago
  Managers that can't do are generally shepherds. Only sheep follow them. Yes, it's good that managers can know a lot about a broad amount, but they should be skilled enough to dive fairly deep and realistically be expected to jump into anyone's job. Otherwise, you're hiring an administrator or a non-technical manager. And there's a place for that, but not one I want to be near.
  - scarface74 10y ago
    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.

philmander 10y ago

I've regretted hiring a few developers who have been apathetic about the actual software product we're making. I am sometimes too optimistic about a technically proficient candidate sharing these traits, during the interview process. After hiring they are depressingly unexcited about delivering a new feature that promises business value, significantly improves performance etc. It's just work to be done.

eropple 10y ago
> After hiring they are depressingly unexcited about delivering a new feature that promises business value, significantly improves performance etc. It's just work to be done. Well...yeah, it is just work to do, because it's just a job. Turn it around: why should they be excited about something they have no meaningful ownership (and I don't mean a few tenths or hundredths of a percent) in? If the co-founder who owns fifty percent of the company isn't excited, sure, be worried. If the developer who you value only for work-units provided doesn't, it's because you haven't created a reason to (and "hard problems" isn't one; pretty much anybody can find hard problems to work on).
- philmander 10y ago
  I'm not sure what to make of that. Assuming the product isn't genuinely boring, is it the norm then that developers without a direct financial incentive in the growth of the company should just be drones who type code in exchange for a salary?
  - eropple 10y ago
    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.
  - tonyedgecombe 10y ago

partycoder 10y ago

So far: - Takers: mentally healthy people, but heavily biased towards self-benefit and competition. Never a volunteer, tries to profit from every little interaction and sees everything as a zero-sum game. Only interjects in a conversation with the objective of gaining social rank, doesn't see value in altruism and collaboration, and is rude or dismissive to people considered lower ranking. - Neurotics: people characterized by high anxiety, low tolerance to frustration, envy, depressed mood, loneliness, etc. In the "Big 5 personality traits" system, neuroticism plays against any person in any professional setting. - Groupthinkers: people that form cohesive groups that collectively become biased towards group harmony, becoming incapable of applying critical thinking in problem solving or having a difficult conversation even if it's in the collective best interest.

linkmotif 10y ago
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.

RidingQwerty 10y ago

You're not a tech company, you build human traps. Now you know why you have "culture fit" problems with talent. https://www.youtube.com/watch?v=C0Y4uzaf2HA https://www.youtube.com/watch?v=C0Y4uzaf2HA

wheelerwj 10y ago

This is an interesting question, because it signals that you are most likely very new to hiring, and maybe ill-equipped to handle managing people in general. Although, at least you're asking questions. First, very rarely does a manager regret a hire even though it's very common for a hire not to work out. Hiring and interviewing are in terrible shape right now, and more often then not lead to terrible hiring/job acceptance choices. Second, you regret hiring PEOPLE, not developers because regrettable hires aren't specific to developers. When they are, it's because an engineer was given too much access to something they should not have been and a theft/breach occurs. Examples of these concepts in play: The NSA probably regrets hiring Edward Snowden. I don't regret hiring the last JS dev I hired even though it didn't work out and he moved to a different company. Lack of technical expertise is a problem sometimes, but it can be nurtured. Lack of personal skills is a huge problem in an office environment, and is much, much harder to nurture. But neither of these are regrettable in-and-of themselves. The thing to remember is that you have to weigh the urgency of hiring against the long term impacts of hiring the wrong person. In other words, be careful and set up controls, but don't allow decision paralysis. Good luck with your project, keep your head up, and expect failure. Great employees are rare, so just keep at it. post mobile edit: Go read: Good To Great: https://www.amazon.com/Good-Great-Some-Companies-Others/dp/0066620996 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-ebook/dp/B01H38S9FY https://www.amazon.com/How-win-friends-influence-people-eboo... Emotional Intelligence: https://www.amazon.com/dp/B000JMKVCG/ https://www.amazon.com/dp/B000JMKVCG/

blablabla123 10y ago
>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.

YouDeserveThis 10y ago

If you're having problems with finding technology workers, consider the idea that you're not a tech company. You build human traps. That's why you are getting the talent you are getting. You don't need programmers. You need digital plumbers. TRIGGER WARNING: This guy is a super big evil meanie who needs rainbows and huggie hugs..... but he's not wrong when it comes to who you attract and why you attract them: https://www.youtube.com/watch?v=C0Y4uzaf2HA https://www.youtube.com/watch?v=C0Y4uzaf2HA

yuhong 10y ago

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

late2part 10y ago
Generally these sort of discussions are not focused on the laws about firing - but more about the risk of valid or invalid accusations of violating EEOC enforced laws[1]. The risk in most places is that firing is often subjective, and folks rightly worry that the firing is done on subjective means, especially if the person is a 'protected class' which is generally loosely interpreted as anyone other than a white male under 40. There are rules and laws that govern firings, especially with large layoffs at large companies - but the 'fear' you hear in Silicon Valley and other places is the fear of a lawsuit about the firing more so than breaking a law per se. [1] https://www.eeoc.gov/laws/statutes/ https://www.eeoc.gov/laws/statutes/
- yuhong 10y ago
  Yea, I dislike anti-discrimination laws too for that reason. They probably worked well for manual labor and the like. Don't forget "performance reviews" and "PIPs" too.
  - late2part 10y ago
    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.
qohen 10y ago
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"). [0] http://employmentattorneyla.com/california-at-will-employment/ http://employmentattorneyla.com/california-at-will-employmen... [1] http://www.atwillinfo.com/ http://www.atwillinfo.com/

late2part 10y ago

Joel Spolsky's Guerilla Guide to Interviewing lays out the rational for two simple filters: 1. Is the person smart? 2. Can they get stuff done? Good read. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

partisan 10y ago

The employee knows about all of the parts of a standard application and can speak to them, but cannot put them together without hours of coaching and discussion. Or the inability to make the right decision when presented with information. Or to fail to ask questions when presented with an unknown, instead making the wrong decision. When presented with a standardized solution that is formalized and utilized across the entire application, will either implement a new, inadequate solution or keep asking around the senior members of the team until someone, given a small enough slice of the problem set, is coerced into validating the inadequate solution, usually devolving into wasteful group meetings on said topic. When asked to following the standard conventions of the large codebase he or she is now working in, decides to implement new folder hierarchies, naming conventions and to litter the code with unnecessary common functions, copied and pasted code blocks, large commented blocks, all of these against the communicated and often repeated standards of the application. --- I initially took it as an affront. Most of the standards were being ignored or questioned by this person. And I had regrets about hiring them. Having had some time to consider the problem, I think that part of the issue is that the person comes from a background where they were in a "get things done" frame of mind. Technology was the means to an end and never a first class citizen. And they were the only programmer. And they had major business responsibilities as well. Being the sole programmer of an organization leaves you in a very isolated position, unable to learn about new standards and technologies unless you actively seek them out. If you are getting things done, well then all is well with you and your skill set. You clearly have the right answers because things are working. I believe that someone coming from that type of background is likely to need to reframe the world in the way they have known it, unable to accept new standards. They are lost without being able to anchor themselves in their old conventions. They are likely to accept the first working solution, because the code is not an asset, it's a tool. Copying and pasting are a savings in the short term. Commented out code is an artifact of their results-driven development process. --- I agree that there are times when you just have to fire someone, but that is not always the only option on the table. Sometimes you can work with what you have by understanding why things are they way they are. In order to get the best value out of this person, I try to capitalize on their strengths by assigning tasks that I am comfortable letting them own. They have a niche, and they call the shots in that niche. They are empowered and in control of their own domain again. When I find that they are deviating from our standards, I convey the reasoning for the standards, but I do so in the form of questions that lead the person to arrive to the right conclusions. In this way, they are deriving the right answers and they own that reasoning. The old way is no longer necessary because the new way makes sense to them now. And it gets better.

navalsaini 10y ago

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.

omidfi 10y ago

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

donovanm 10y ago

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.