Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What makes a software engineer unhireable?
28 points by kotrunga 8 months ago | hide | past | web | favorite | 49 comments
Engineers on my team were briefly talking about what makes a software engineer "unhireable". Not things like felonies or legal things, but more in terms of what experience they have / don't have and what they were doing before.

Is there anything in your mind that would stop you from hiring a software engineer? What are red flags to you? Again, about the skillset or experience(s), not any legal issues.




From my own experience here's one big way to become unhireable:

Being a senior engineer in years only, but not in skills. You become a laggard in learning new skills, and adopting good programming practices. This is the classic "1 years of experience for X years" problem. The harsh reality is that many good companies avoid these types of people. They assume that you are not proactive with your career. So it's easy to get trapped in a feedback loop where your sub-par experience can only land you offers with companies that provide more sub-par programmer experiences.


I've seen this. It usually results in the candidate performing at a junior level in an interview -- and generally we're not going to bother giving them a junior level offer when they already have a senior level title at their current job. It doesn't surprise me that some companies try to avoid wasting their time.


For what it's worth, I've never been a senior developer although I have been working for 10 years. I've gotten the title of mid-level software engineer or simply "software engineer". The situation is a bit more complex for me, since my salary when I was a junior level was well below the local average for a junior, and right now as a mid-level it's a bit better, but still only make slightly below an average junior.

As far as disqualifying seniors for junior jobs, depends on the companies they're moving from and to. A mid-level or senior-level job at a small company with only 3 developers doesn't necessarily qualify me to be a mid-level or senior-level job at a large established software company. So I'm fine with being downleveled in position when changing to those companies. And because of my salary situation, I'm 100% sure it will result in a pay raise regardless of the title. It's happened with some colleagues before, when they left the place I worked at. One left a 55k/year job with a technical lead role to a 70k/year job as a mid-level role.


It's not just that the pay is a problem (although it usually is). It's also that if someone has been in a role for a long time and has not bothered to level up their skills enough that they could pass at least our Mid bar, we question if they have enough initiative to move beyond a Junior role once they're here -- and we don't want people to be Juniors forever.


You are mistaken. In a small company you usually have the power to choose technology and make architecture decisions. Small company where you have many hats and work closely with stakeholder will teach so much more.

In the big enterprise, you will code on the locked windows7 machine and deploy to RedHat 5 box with the assistance of Ops team. You will use antiquated technology and all important architecture decision will be made by a clueless architect in the mothership.

My rule of thumb:

  Junior - require handholding often a negative contribution  
  Midd - work independently, add value but require oversight 
  Senior - can contribute multiple times more, can mentor or architect
Most people never reach senior but they feel entitled by having years of experience.


>So it's easy to get trapped in a feedback loop where your sub-par experience can only land you offers with companies that provide more sub-par programmer experiences.

Sorry but could not understand this. Can you please explain?

Also can you please guide improving your skills - It means learning new languages etc or improving deep understanding.


It's hard to suss out attitude, incuriosity, and/or inflexibility in the timeframe of an interview track. There's only so far those will hold a candidate back before they simply don't complete the interview of their own accord.

Red flags you're likely to encounter if you conduct interviews in the dozens are:

1. Don't know how to say they don't know. Have had candidates call up two screens and google the answers for questions they don't know, all while they're interviewing. (The eyes would give them away). The correct answer was "I don't know", not "let me google that for you".

2. Simple incompetence. They may be able to recite, rote, everything in the Android SDK documentation, but be unable to properly write a for loop. Almost makes you want to hire these people because the former is so rare to find, but, no.

3. Unrealistic expectations as to start date. Have had some great interviews where everything was perfect, but they wanted a year to travel before they would start (nothing against people from Europe, but, sigh..). I doubt that company even survived the full year.

4. Bait and switch. Apparently some devs contract out their end of the hiring process, paying "experts" a couple hundred bucks to interview under their name, get them the job, then on day 1, the interviewers and rank-and-file developers none the wiser, show up as a different person with the same name, without the requisite possibility to pass the interview or succeed in the workplace. They nod, smile, take on assignments, join the team at lunch, try maybe, but fail to deliver, and can glom on to the high-paying job for months before corporate axes them, never realizing the scam they were taken for.

Having been on both sides of the interview process far more than most, I firmly believe that the majority of the dysfunction in hiring software engineers is on the company side. Corporate monopsony breeds systemic incompetence in hiring.


#4 is hilarious (unless you work for the team who gets that dev), that's hands down something you'd see on Silicon Valley.


> Bait and switch. Apparently some devs contract out their end of the hiring process, paying "experts" a couple hundred bucks to interview under their name, get them the job, then on day 1, the interviewers and rank-and-file developers none the wiser, show up as a different person with the same name, without the requisite possibility to pass the interview or succeed in the workplace

There’s no fucking way this is real. There is NO possible way that a human could actually think this could work in their favor and be OKin any way.


why not, I mean criminality of all sorts happens and this isn't even criminal. Of course it requires not meeting HR or interviewers after interview/on hire, which means it's really only good for big companies.


Speaking from experience, small companies can fall for this too. Companies that completely isolate the existing employees from candidates are just asking for trouble. A single-digit percentage of recruiters will now make a point of photographing the interviewee as part of the process.


> show up as a different person with the same name

They don't interview with people who will see them on the first day and realize it's a different person, like their manager or teammates?


We had a "DBA" show up like that./ He didn't even seem too concerned that he looked nothing like the guy we interviewed over Skype.


This is absolutely hilarious and I did not realize this was a thing.


After some checking, apparently it is a thing. THere's a whole industry of people doing interviews from remote locations.

It was quite funny to see when we complained to the recruiting agency how they had to call him back to "sign some more papers before he can get paid". Apparently he did not realize that we are a small enough shop that people who interviewed him might remember that and start feeling suspicious when the guy who showed up looked nothing like any of the ones we did talk to before; it helped that one of the admins took a screenshot of his Skype image, too.

But the scariest thing is that he didn't even feel bad about it -- he told the agency "what? I need a job". That he did not know a database from a hole in the ground wasn't going to stop him.


Candidates often turn up in person to the interview with their new manager, but send a double to the aptitude test which is only supervised by HR staff. Because HR often get bonuses based on how many new recruits they bring in, they often skip ID checks and turn a blind eye to anything suspicious they see.


#4 actually happens? I thought paying someone to interview in your place is a pie-in-the-sky idea, as it's definitely more effort required than to BS on your resume.


As for 1), I've had several recruiters and my former professors say it's better to Google it than admit you don't know.

Our industry needs to professionalize with some kind of standard certification that proves holders are at least minimally qualified. Like the bar exam for lawyers.


> I've had several recruiters and my former professors say it's better to Google it than admit you don't know.

Oh, western culture. Please, it’s okay to admit you don’t know something!


It's better im a startup environment — shows initiative. And sometimes you find out that you already know the thing and forgot it, know it by another name, etc.


#4 is quite a bright idea. Couple of months of inflated tech salary can go a long way if you are good at frugal living.


Right now, for me, I think my age. I have interviewed for several development positions these past 3 months and no offers. One of them I had 4 interviews and they still picked someone else. What I am finding is that I am interviewing with a lot of young people, just finishing with college.

I had one job offer where I was told by the CEO that he really wanted to hire someone out of college but if I was willing to work for $29,000 a year he would give me the job.


What geo are you in? There’s no CEO on the planet worth a damn that expects to find someone to work for $30k/yr unless you’re WAY out there in, like, the Midwest or something—-and even that’s a god damn stretch.


> There’s no CEO on the planet

FYI other countries exist on this planet outside of the United States. In Australia a fresh-from-uni undergrad could expect to make 30k on their first posting.


My first job out of university was about $30k and that’s in the South East of England.


Very upstate NY


What type of companies are you going for that the interviewers are so young? Shouldn't they be at least senior engineers?


All sorts. A blockchain startup, a game programmer, an embedded software dev, a GPU developer....


1. Not showing me the way you solve a problem.

2. Having a strong belief that most non-programmers are dumb, including marketing/sales/customer service. This shows up when you interact with those folks. All the guys I've fired in my company are for this reason and never for their failure to not being able to implement an LSM based k/v store.

3. Asking for vacation with reason ("there is nothing to do at the moment"), then after returning from vacation telling us that the service got hacked because "I did not have enough time to fix that particular issue"

4. Failing to understand how the company makes money and our expectations. Some devs love their craft and take home big salaries but in office, they are busy painting us as a con show. Some part of your income comes from the effort of that sales guy/gal, how is your work purer than her? Why paint him as a shady gal in the office?

5. I doubled compensation of some developers, they came back with a request to switch them from fulltime to parttime.

This is based on early experience as a founder.


How is this comment by a startup founder who has made devastatingly good points being downvotes?


How long have you been a founder and how many have you fired?


Not being able to get 100% of the small edge cases the first time on complex algorithms problems.

--every large tech company


Maybe that's how it works at Amazon and Apple, but that wasn't my experience when I interviewed at Microsoft (twice!), Google, or Facebook. They weren't especially complex algorithm problems, either (how complex can it really get, when you're doing it on a whiteboard?). You just have to be able to think your way through a problem and explain what you're doing as you go; you should know what assumptions you're making about the limits of the problem, what you might do differently with different assumptions, and what kind of performance characteristics you should expect with those tradeoffs. There were definitely some complex design problems, especially during the Google interview, but I have really never experienced anything like the supposed "gotcha" coding interviews people stress out about so much.


This.

You can be a gold standard human who invented a distributed database. But at a large company, you're not going to be hired if you can't solve some string subsequence problem.


a million times this.


A few examples from actual interviewing experience:

- Treating anyone (be it the interviewer, the janitor, the intern, or people from a different background whom you've never met) as below you

- Treating the interview as a power struggle

- Failing to solve a fizzbuzz within half an hour despite claiming 15 years of software development experience ("well, I've mostly been managing people lately")

- From a developer with 18 months experience applying to a mid-level position: "I expect to have at least three people reporting to me within 12 months" [Even more ridiculous when you take into account that we're a tiny, slow-growing team that's unlikely to add 3 people total within 12 months.]

- More than 3 years out of school, never held a job for >9 months.

- "And then I told them we should put development on hold until we rewrite all seven services in $new_shiny"

- Shows up to the interview drunk or high


I once asked in a WebEx interview if the candidate had paired programming experience. The response I received was the Google definition of paired programming. After clarifying that I wanted the candidate to talk about their experience, and they continued reciting the Google definition, and the interview ended there.


Lack of humility. Over the course of a long career, you will (must) discover that many of the things you learned early on aren't so, or at least don't apply in some situations. Most tech problems are actually complex design problems, and one must be humble to have a chance of choosing a good solution.


Incuriosity.

If someone thinks: I have learned enough, and I don't need to learn more, I would never hire that person.


More than 2 years working and not knowing or having used any version control.


Deep character flaws that lead to Toxicity!

Negative people that are always saying "it can't be done", "refusal to experiment and try new things", "blaming", "refusing ownership", "whiners", "people that seem to be happy when a failure happens", "folks that reject collaboration and wish to be left alone, you know, the lone superstar programmer"


There's one thing that leads me to a no every time: if you use an acronym on your resume and you can't at least explain the abbreviation, I'm done. This is a specific case of a more general principle, but don't use words that you can't even define.


I've selected one candidate over another for some impression they were marginally more impressive, but the only reason I have ever given a hard no was arrogance.


Arrogance would do it for me as well.

I've worked with arrogant devs before (and anecdotally they've written some of the worst code I've ever seen - usually because they complicate the hell out of things because they think they are smarter than they are) and I loathed it.

Be confident in your abilities but don't be a dick about it and always accept the strong possibility that the other person may be right.

I saw a phrase I liked on here a while ago, "strong opinions weakly held" that summed it up nicely.


Attitude and being inflexible.

I'm probably guilty of both O:-)


Attitude.

Skills and knowledge can be developed.


My personal opinions follow:

Windows on a non-gaming, non-CAD box.

PHP.

Gentoo.

MCSE.

Being a hubristic jerk (common with sysadmin types)

People who homebrew crypto.

“Just install linux on a cheap PC and...” types. These people also usually vastly undervalue their time or overestimate the number of hours in the day available to do 90s sysadmin bullshit.

People who don’t realize that more running software is usually a liability.

People who treat other people as idiots for being yet ignorant of something - there is an xkcd about this one.

Joke ones that I wish were true:

emacs

javascript

android


I don't mean to be combative, but I think Gentoo and PHP both have their place. I can guess why you would think those things would make an engineer unhireable, but that didn't always mean trouble. I would assume the real problem would be when an engineer limits his/herself to those things and can't work outside them. An engineer that only knows how to work with PHP or refuses to use anything other than Gentoo can be a large problem.


I started with Gentoo and PHP. I know them both better than most. I have several commercial products that went into production written in PHP and deployed on Gentoo systems.

It was dumb then, but I was 20. It’s still dumb now, 15 years later. Those people had no business hiring me then but they were even dumber about technology than I was at 20.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: