How not to hire a software engineer • Hacker News Board

Re: How not to hire a software engineer

#121

Post by metric10 » Mon, Apr 01, 2019, 4:03 PM UTC

LandR wrote: post #112

shapiro92 wrote: post #38

Earlier quoted context omitted.

> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. this is exactly the company/boss i would not want to work for. It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to ta…

Yes. Because if they don't have a deepish understand of the language and framework IME they tend to write crap code. If someone is being hired to write C# /.NET all day every day I don't want to have to spend time teaching them C# or .NET Especially not how to write good C# / .NET.

Wasn't part of the point of C#'s syntax was that it was easy for C++ and Java programmers to learn? Would any real C# advocate really tell me it would take months of manager supervised learning to pickup?

I've been writing code for a long time in many languages and I do my best to write "good" code. The principles that make code "good" in one language appear to apply equally to other languages...

Re: How not to hire a software engineer

#122

Post by metalgearsolid » Mon, Apr 01, 2019, 4:04 PM UTC

esturk wrote: post #117

metalgearsolid wrote: post #107

I've helped hire 3 software engineers to both work with me and mentor me and they were all failures. First two hires quit after only a few weeks. Third hire was temporarily successful. He eventually revealed himself to be both a jerk and not very technically skilled, so I spoke to higher-ups to get him removed. My hiring strategy was designed to be simple and respectful. A simple, 20 minute assignment completed betwe…

You didn't even mention what those 3 interview questions are like which is the whole point of this discussion. You made the conclusion with 3 data points. I could just as easily make a conclusion about the common denominator of all this which would t be fair to you.

I'm unsure why you think my anecdotes of failures hiring software engineers is not relevant to a discussion on how to not hire software engineers. I think you misread my comment, because drawing a conclusion on my hiring process from 3 data points is exactly what I'm not doing.

Re: How not to hire a software engineer

#123

Post by TallGuyShort » Mon, Apr 01, 2019, 4:08 PM UTC

moosey wrote: post #118

TallGuyShort wrote: post #84

Earlier quoted context omitted.

I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job…

I would think that anyone hiring a Ph.D. in Computer Science would be looking for a different kind of output than the knowledge of actually doing software development and the associated project management/time management work. I would imagine that such people, if placed optimally, would be doing largely self-directed work with an expectation of solving a very complicated problem, with work output that looked more lik…

Just to be clear, I neither have Ph.D. in CS myself nor am I looking for that in candidates. I agree with everything you say.

Re: How not to hire a software engineer

#124

Post by qudat » Mon, Apr 01, 2019, 4:12 PM UTC

nsb1 wrote: post #50

I don't ask brain-teasers during an interview, but time and time again the value of a simple coding assignment has proven its worth. It is simply amazing to me how many candidates seem to lack the basic ability to code a couple of nested for loops, and weeding those candidates out early streamlines the whole interview process. I will typically do this on a phone screen, having informed the candidate beforehand that t…

I think you're testing for someone who can think on the spot with a person watching every keystroke which would be rare in an actual work environment. For a lot of programmers, they spend most of their time in their own head thinking through a problem, trying things, removing things, etc. To accomplish what I think you are trying to select for would be a take-home assignment. The interviewee can work through problems in a more natural way without someone watching intently on every keystroke.

Re: How not to hire a software engineer

#125

Post by gwbas1c » Mon, Apr 01, 2019, 4:15 PM UTC

jrjarrett wrote: post #82

So these kinds of posts keep showing up. How are interviews for not-software-engineers conducted? ie. how do you interview for a business analyst role, or a sales and marketing role? I have to assume that those roles suffer from the same sorts of issues a SE job does -- that someone can talk a good game but not be able to perform in the role.

Doctors have to go through a rather grueling licensing process. The job interview is mostly about determining mutual interest.

Doctors also need to go through periodic re-credentialing.

To put it bluntly, when a doctor has credentials, you at least know that they're competent; and more competent than 2-4 1-hour quizzes.

Re: How not to hire a software engineer

#126

Post by Retra » Mon, Apr 01, 2019, 4:16 PM UTC

mawburn wrote: post #105

nsb1 wrote: post #50

I don't ask brain-teasers during an interview, but time and time again the value of a simple coding assignment has proven its worth. It is simply amazing to me how many candidates seem to lack the basic ability to code a couple of nested for loops, and weeding those candidates out early streamlines the whole interview process. I will typically do this on a phone screen, having informed the candidate beforehand that t…

Is it amazing that they can't do them at all, or they can't do them in the spotlight in a totally unfamiliar? I have a strong feeling that most of the people you think fall in the former are actually in the latter. Yes, the solution might be a couple nested for loops. But if it's a new question to the interviewee, then they don't know the solution yet.

If you can't find the solution, and you can't work in a slightly unfamiliar situation which is undoubtedly supposed to be your core competency, then I don't see why that's a job you should get.

If you're bad at taking tests, being able to make a vague excuse for why you failed one is not an acceptable substitution for passing it.

Re: How not to hire a software engineer

#127

Post by qudat » Mon, Apr 01, 2019, 4:16 PM UTC

etxm wrote: post #106

I like giving coding “tests” but I prefer to let the candidate pick an issue from an open source project ahead of time. I want to be on as close to the same footing as the interviewee. I like to see them work in as comfortable and nerve free environment as possible. And in the event that the person doesn’t get hired, they have a commit on their GitHub and maybe added some value to a project.

> they have a commit on their GitHub

Maybe I'm applying to the wrong places but virtually no one cares about my Github. It's really sad to see so many potential employers ignore one of the best pieces of information for a candidate. For reference, my github is filled with maintained projects and OSS with people using them, submitting issues, prs, etc. It's like the employer's process is set in stone and since a lot of people don't have active githubs, it cannot be used as a comparison.

I think the places that do look at github profiles are great, but then I fear they end up looking for massive OSS projects for it to bear any weight.

Re: How not to hire a software engineer

#128

Post by Egraveline » Mon, Apr 01, 2019, 4:17 PM UTC

kristopolous wrote: post #10

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…

In your opinion are there any common signs you see that indicate someone is good at dynamically applying new skills? or even better is there any signs that clearly idcated they aren;t good?

you talked about paying attention to their attitude but I mean more specific things like, if they said they use Emacs and write bash scripts would you take that as arrogance or that they are competent?

Re: How not to hire a software engineer

#129

Post by [deleted] » Mon, Apr 01, 2019, 4:24 PM UTC

mawburn wrote: post #105

nsb1 wrote: post #50

I don't ask brain-teasers during an interview, but time and time again the value of a simple coding assignment has proven its worth. It is simply amazing to me how many candidates seem to lack the basic ability to code a couple of nested for loops, and weeding those candidates out early streamlines the whole interview process. I will typically do this on a phone screen, having informed the candidate beforehand that t…

Is it amazing that they can't do them at all, or they can't do them in the spotlight in a totally unfamiliar? I have a strong feeling that most of the people you think fall in the former are actually in the latter. Yes, the solution might be a couple nested for loops. But if it's a new question to the interviewee, then they don't know the solution yet.

[deleted]

Re: How not to hire a software engineer

#130

Post by pmiller2 » Mon, Apr 01, 2019, 4:24 PM UTC

yitianjian wrote: post #108

jimbokun wrote: post #90

Earlier quoted context omitted.

Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.

If you're recruiting with a specific company and specific team that you love, sure. But I can't imagine committing multiple hours of my time to each random company's take-homes. As a rule I don't really do any take-homes - the couple I've done haven't been very useful in terms of my own time investment into the problems themselves, and the companies have not been worth it to go above and beyond.

This is my exact issue with take-home tasks: I can get to an onsite or a rejection with most other companies after a 15 minute recruiter call and a 45-60 minute technical phone screen. So, why do I want to do a 2+ hour homework assignment? Most of the time, there simply is no compelling reason to do so.