TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Have you ever regretted hiring a developer?

84 点作者 omidfi大约 8 年前
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?

19 条评论

cauterized大约 8 年前
I&#x27;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:<p>- a guy with an alcohol problem who would disappear for a week at a time or come in to work sloshed<p>- 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.<p>- 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&#x27;t cost effective to have on the team<p>- 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&#x27;t have time to hand-hold like that)<p>- 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<p>Takeaways:<p>It&#x27;s fairly easy to assess who is and is not capable of developing basic CRUD apps. Getting meaningful information about a person&#x27;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.
评论 #14013225 未加载
评论 #14011791 未加载
评论 #14013152 未加载
samblr大约 8 年前
In interview what appeared to be a potential-hire&#x27;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 &#x27;talk about software architectural things&#x27;. 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&#x27;s else code has this problem - how to fix, so on and so forth. Initially we didn&#x27;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&#x27;s work. He didn&#x27;t have a clue on why blocking calls should not be made on UI thread. We didn&#x27;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
评论 #14013190 未加载
评论 #14013297 未加载
49531大约 8 年前
The biggest issue I&#x27;ve had is with engineers with strong opinions strongly held. A lot of time they&#x27;re unwilling to compromise and do things their way 100% of the time.<p>Recently I had an engineer on my team who would never pattern match in a project. He would always introducing new patterns everywhere he went. It was all just an unwillingness to be flexible.
wheelerwj大约 8 年前
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&#x27;re asking questions.<p>First, very rarely does a manager regret a hire even though it&#x27;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&#x2F;job acceptance choices.<p>Second, you regret hiring PEOPLE, not developers because regrettable hires aren&#x27;t specific to developers. When they are, it&#x27;s because an engineer was given too much access to something they should not have been and a theft&#x2F;breach occurs.<p>Examples of these concepts in play: The NSA probably regrets hiring Edward Snowden. I don&#x27;t regret hiring the last JS dev I hired even though it didn&#x27;t work out and he moved to a different company.<p>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.<p>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&#x27;t allow decision paralysis.<p>Good luck with your project, keep your head up, and expect failure. Great employees are rare, so just keep at it.<p>post mobile edit:<p>Go read:<p>Good To Great: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Good-Great-Some-Companies-Others&#x2F;dp&#x2F;0066620996" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Good-Great-Some-Companies-Others&#x2F;dp&#x2F;0...</a><p>How to Win Friends and Influence People: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;How-win-friends-influence-people-ebook&#x2F;dp&#x2F;B01H38S9FY" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;How-win-friends-influence-people-eboo...</a><p>Emotional Intelligence: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;B000JMKVCG&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;B000JMKVCG&#x2F;</a>
评论 #14013312 未加载
评论 #14014541 未加载
dougireton大约 8 年前
Developers who insist that their favorite technology is the best vs. what&#x27;s the best for the task at hand, what technology will the team as a whole be successful with.<p>Developers who don&#x27;t have empathy for less experienced team members; who can&#x27;t&#x2F;won&#x27;t mentor well.
评论 #14011604 未加载
评论 #14010931 未加载
评论 #14011093 未加载
评论 #14010913 未加载
partycoder大约 8 年前
So far:<p>- 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&#x27;t see value in altruism and collaboration, and is rude or dismissive to people considered lower ranking.<p>- Neurotics: people characterized by high anxiety, low tolerance to frustration, envy, depressed mood, loneliness, etc. In the &quot;Big 5 personality traits&quot; system, neuroticism plays against any person in any professional setting.<p>- 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&#x27;s in the collective best interest.
评论 #14032503 未加载
angvp大约 8 年前
In my case when I&#x27;ve regretted it was much because the &quot;attitude problem&quot;. For a team of 10 devs (I&#x27;ve recruited all of them), I remember two specifically cases in which I regretted to hire those guys.<p>Guy #1:<p>A &quot;developer&quot; who was trash talking everyone (even me) and then he pretended he didn&#x27;t do it or he alleged &quot;I didn&#x27;t say that&quot;, 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&#x27;t give him much attention, so he started sending me whatsapp messages and e-mails at ridiculous hours and complaining because &quot;I didn&#x27;t reply his messages&quot;, this guy has some issues IMO.<p>Guy #2:<p>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&#x27;s the guy with the ugliest practices that I&#x27;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&#x27;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..<p>My advice when hiring please don&#x27;t be desperate (guy #2) and always check his background with their previous employers (guy #1).<p>With the other 8 guys, I was ok, even if couple of them weren&#x27;t 100% perfect (I could add couple of more guys of this team but they weren&#x27;t so bad) overall I felt great with the team.
评论 #14013216 未加载
评论 #14013040 未加载
coralreef大约 8 年前
Replace the word developer with plumber, electrician, financial adviser, mover, etc. and you pretty much sum of the difficulties of relying on outside help.
EliRivers大约 8 年前
Interviewee seemed &quot;odd&quot;. Stilted interaction during interview. Technical skills fine enough. Uncommonly, a second interview held with an extra interviewer brought in.<p>Technical director asked everyone; everyone said &quot;no hire&quot;. Technical director hired him anyway, allegedly (but not proven) on the grounds of a bizarre, unshakeable faith in the supremacy of Russian programmers.<p>About day two, overheard on the phone apparently interviewing for another job. MD noticed he didn&#x27;t seem to be doing much; asked if he had some work. &quot;No.&quot; Do you want some? &quot;No.&quot;<p>Gone on day three.<p>What went wrong? One person permitted to discount everyone else&#x27;s opinion and hire a clearly bad candidate anyway, on the grounds of their own personal prejudices.
评论 #14012667 未加载
seehafer大约 8 年前
Lack of empathy for the customer is the big thing that has led me to fire developers in the past
philmander大约 8 年前
I&#x27;ve regretted hiring a few developers who have been apathetic about the actual software product we&#x27;re making.<p>I am sometimes too optimistic about a technically proficient candidate sharing these traits, during the interview process.<p>After hiring they are depressingly unexcited about delivering a new feature that promises business value, significantly improves performance etc. It&#x27;s just work to be done.
评论 #14013214 未加载
评论 #14013253 未加载
评论 #14013221 未加载
navalsaini大约 8 年前
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 :-<p>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.<p>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.<p>This is from a very startup perspective where many times founders are very passionate and too optimistic about what they are building.<p>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.<p>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&#x2F;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&#x2F;vis the risks involved.
wanderr大约 8 年前
If you hire enough people, eventually you&#x27;ll have a bunch of examples for this question, unless of course you never make mistakes.<p>Pretty much everything you can imagine can go wrong and probably more. Hiring anyone is always a risk but it&#x27;s one you can&#x27;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.<p>That said, specific bad hire examples that were tough to deal with:<p>-Developers who get stuck and don&#x27;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.<p>-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.<p>-Architecture astronauts&#x2F;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&#x27;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&#x27;t had much luck with intervention on.<p>-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&#x27;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&#x27;t really work, and you risk harming the rest of the team.<p>-Sloppy &#x2F; lack attention to detail. Developers who fail to check their own work, or do it so hastily they don&#x27;t notice glaring mistakes, or who are rushing so much they don&#x27;t &#x2F; can&#x27;t follow a simple spec. These developers also often have trouble following coding standards because either they never learn them or they&#x27;re not really looking at their code enough to notice when it doesn&#x27;t follow.<p>-Not curious &#x2F; quick to BS through a problem. Debugging skills are critical to being a good developer, but some developers don&#x27;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&#x27;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&#x27;ll never pick it up. Subsequently they&#x27;re more likely to ship bugs because they&#x27;re good at convincing themselves that bugs they observe are not the result of their changes.
评论 #14012248 未加载
评论 #14013228 未加载
评论 #14013227 未加载
aisofteng大约 8 年前
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.<p>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:<p>1. &quot;Do you follow any tech news outlets or social media sites?&quot;, which seemed to confuse her and ended up being answered with a sheepish &quot;no, not really.&quot;<p>2. &quot;Can you give us an example of something you&#x27;ve coded for fun? It doesn&#x27;t have to be a big project and it doesn&#x27;t have to be particularly recent - whatever comes to mind.&quot; 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&#x27;t remember, which led me to suspect she made this up (how can you install Apache&#x2F;nginx&#x2F;other, configure it, use it, and then forget what server software you used?)<p>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&#x27;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&#x27;t seem like someone that does - I said that I didn&#x27;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.)<p>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&#x2F;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&#x27;t know.<p>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&#x27;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.<p>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&#x27;s question.
评论 #14011765 未加载
评论 #14012412 未加载
评论 #14013404 未加载
评论 #14011276 未加载
late2part大约 8 年前
Joel Spolsky&#x27;s Guerilla Guide to Interviewing lays out the rational for two simple filters:<p>1. Is the person smart?<p>2. Can they get stuff done?<p>Good read.<p><a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2006&#x2F;10&#x2F;25&#x2F;the-guerrilla-guide-to-interviewing-version-30&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2006&#x2F;10&#x2F;25&#x2F;the-guerrilla-guid...</a>
donovanm大约 8 年前
I haven&#x27;t (since I&#x27;m not in charge of hiring), but I&#x27;ve had to work with multiple people that simply couldn&#x27;t code to save their lives which was quite frustrating.
yuhong大约 8 年前
This reminds me that the laws for firing vary by state. I think California is one of the strictest in this area, right?
评论 #14013320 未加载
评论 #14026521 未加载
omidfi大约 8 年前
wow so many nice comments. Thanks, I&#x27;ll try to digest these and probably come up with a summary.
partisan大约 8 年前
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.<p>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.<p>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.<p>---<p>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.<p>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 &quot;get things done&quot; 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.<p>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.<p>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&#x27;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.<p>---<p>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.<p>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.<p>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.<p>And it gets better.