How not to hire a software engineer • Hacker News Board

Re: How not to hire a software engineer

#141

Post by llamataboot » Mon, Apr 01, 2019, 4:55 PM UTC

pmiller2 wrote: post #130

yitianjian wrote: post #108

Earlier quoted context omitted.

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.

I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy.

Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps. I'm sorry, but a full week's of unpaid work that I have to fit around my actual day job is just not practical, I know you want to make a good decision, but really...????

The best I've seen recently is a company that paid an hourly wage for 2 days worth of take-homes. Not consulting wages, but a good wage. It gives them incentives not to invite everyone in the world to do their test, and gives the interviewee something for their time.

Re: How not to hire a software engineer

#142

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

jrochkind1 wrote: post #135

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 think that would be kinder to the applicants if you told them that there were going to be things you didn't expect them to know required for a good solution and you didn't necessarily expect a good solution but were interested in how they approached it. You'd still be able to tell nearly as much by what questions they asked, and it would be less testing for "How well do they do under unrealistic/unrepresentatives k…

I generally do tell them it's a complex problem and I'm looking more for how they approach it than any specific solution. I don't tell them everything I'm looking for because then they'll just pretend to be the way I want them to be. But I disagree that it's unrealistic. I've had far too many employees and coworkers who don't understand what is being asked of them or don't know what they're doing, and try to fake it as long as they can. And if I tell them they need to tell me if there's a problem, they almost always haven't until the pattern continues and becomes a worse problem. If the way they deal with pressure in an interview is to bullshit me, I need to know that long before they're under pressure at work.

Re: How not to hire a software engineer

#143

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

Retra wrote: post #126

mawburn wrote: post #105

Earlier quoted context omitted.

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.

[deleted]

Re: How not to hire a software engineer

#144

Post by diminoten » Mon, Apr 01, 2019, 5:13 PM UTC

theelous3 wrote: post #42

techterrier wrote: post #9

Earlier quoted context omitted.

Try not to judge the individuals too harshly in this circumstance - their lawyers have probably forbid them from saying much if anything at all.

I'll judge them all the same because it's not illegal to give someone feedback. Unless you have discriminatory hiring practices in which case the judgement holds true, or your legal team is so far up their own and everybody else's ass, the judgement still holds true.

Yes, it basically is illegal to let a non-lawyer give someone feedback. Not literally, but negligent of a company to allow.

Re: How not to hire a software engineer

#145

Post by jondubois » Mon, Apr 01, 2019, 5:19 PM UTC

I think the point is that big corporations don't believe in the value and depth of talent. They're not trying to find the world's top software engineers; they just want to find enough good engineers to fill their quota. What that means is that they don't care about depth. They don't care if the candidate is a genius in their domain; they just want to hire people who can reliably solve coding problems; that's it.

It's quantitative, not qualitative; it's not about how well the candidate can solve problems - The 'if' is much more important to them than the 'how'. Unfortunately, not many people have the ability to objectively measure the quality of a technical solution, that's why they don't bother at all with the 'how'.

Re: How not to hire a software engineer

#146

Post by bitL » Mon, Apr 01, 2019, 5:24 PM UTC

externalreality wrote: post #78

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…

I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.

8 hour code test - you are an optimist! :D Recent trend in Silicon Valley is 1 week to 1 month (MVP) coding test in a hot area (e.g. Deep Learning), preferably coming with unique world-class solutions during that time :DDD And you get a phone interview only when you went to a Top 10 school.

Re: How not to hire a software engineer

#147

Post by emilecantin » Mon, Apr 01, 2019, 5:28 PM UTC

metric10 wrote: post #121

LandR wrote: post #112

Earlier quoted context omitted.

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...

There _are_ differences in good code between language. For exmaple, I've recently worked with a very good Java dev who wrote some code for a React frontend. While his code was very good, it definitely had that "java" feel to it, and I actually fixed a few bugs by removing some of it, mostly around state vs props synchronization.

Re: How not to hire a software engineer

#148

Post by cr0sh » Mon, Apr 01, 2019, 5:35 PM UTC

mitchitized wrote: post #111

morkfromork wrote: post #3

Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.

I despise the "legal risk/threat" aspects of this process, which is most likely the reason nobody can actually tell you something useful. In many large companies you can't even provide critical feedback to your own employees, and if you end up letting them go as a result, you are unable to tell them what really went wrong. I understand an aversion to legal risk, but IMHO this is going to an extreme that hurts all of…

That has always got me about interviews; I've tried emailing back the company, calling them, etc - trying to get some kind of feedback.

I consider it lucky if I even get an email or voicemail saying they've decided to pass. Honestly, most of the time, I don't even get that.

If you're a recruiter, or interviewing someone for a position, it's my opinion that you should be able to give the candidate feedback on what they did right, and what they did wrong, so that they can improve themselves for their next interview.

So often, as a candidate, I've been left to guess at what I did wrong, or why things didn't turn out well. Sometimes, you can figure it out. Other times, it's not very clear what it is you did or answered wrong. Maybe you have a nervous tic or other habit that you are totally unconscious of that nobody has pointed out - and that put them off? Or maybe you need to work on your delivery, or who knows what?

I can understand why companies don't do it; I can see it from their side. I'm sure they (well, their recruiters) can see it from the candidate's side as well. I wish there were a way around this impasse.

I tend to wonder if it has become this way, in part, due to candidates getting honest feedback, and then they in turn went off the rails against the employer or employees? Pure speculation, but it wouldn't surprise me to find out this was the case for some of this.

Re: How not to hire a software engineer

#149

Post by vips7L » Mon, Apr 01, 2019, 5:38 PM UTC

ozzyman700 wrote: post #96

falsedan wrote: post #31

Earlier quoted context omitted.

Unless the IDE you use everyday is the whiteboard, these are all fine and valid criticisms of your hiring tests. If you want to see real-world results, give candidates real-world conditions (including their preferred OS/IDE/workspace environment). > under pressure is this a common occurrence in your company? people expected to code well under direct supervision and a strict short time limit?

Hackerrank interviews done with video chat literally have a person's face watching their screen which updates as you type. I had an hour to write a few functions and the person interviewing had the ability to run the tests

I hate hackerrank. The experience writing the code is terrible. You have to scroll up and down the page to remember what they want you to do. It's barely a text editor and slows down how fast you can actually write the code they want under the timelimit.

Re: How not to hire a software engineer

#150

Post by cr0sh » Mon, Apr 01, 2019, 5:44 PM UTC

rightbyte wrote: post #71

jahrule wrote: post #64

Earlier quoted context omitted.

wtf. what you are describing is something that i would say is suable. and should be. you basically said dont hire that person to someone. because of your bad experience with that ex-colleague ?. you are denying that person a chance. how come ? what are you going to do next time someone calls for reference ? the same ? immature, questionable, discriminating practices...

Strange. Where I live it's common practice to ask former employers about a persons performance. I you have no prior work experience they would want to call your math theacher or army drill instructor. In the US it's illegal? It's discrimation yes but isn't that the whole point of a recruitment process?

It's illegal in the US for the company or anyone representing the company to say anything more than that they worked for the company, and what they worked on.

They can't tell the person that the employee was fired, or anything like that.

But as noted - there are ways used to get around such things (that is, the laws of our country). Those laws exist because people were wrongly discriminated against by using such "references".

But if you have a reference to someone you worked with, and they are no longer employed by that company - then I'm pretty sure they can answer anything they wanted too (unless there's some kind of NDA they are still under after leaving the company). Because they don't represent the employer any longer, and are a personal reference - things become more casual.