How not to hire a software engineer • Hacker News Board

Re: How not to hire a software engineer

#211

Post by drugme » Mon, Apr 01, 2019, 10:41 PM UTC

kristopolous wrote: post #188

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…

If I smell any bs then I immediately change tactics and make sure I put them deep over their head. For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?" There's 3 ways to answer these kinds of questions and it exposes you as either a genius (or in this case a linguist), a non-genius (real geniuses are as common as 7.5 ft tall people) or a bullshitter trying to look li…

For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?"

What's the point of grandstanding like this? To make yourself feel smarter than they are?

My way of dealing with bullshitters (who in general are surprisingly eager to reveal themselves as such -- there's no need to lay special traps for them) is simply to say "Hmm - okay" and politely end the interview at the nearest reasonable opportunity.

Re: How not to hire a software engineer

#212

Post by drugme » Mon, Apr 01, 2019, 10:44 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.

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.

Nor is the above argument an acceptable substitution for a sound argument that these kinds of tests have some kind of validity.

Re: How not to hire a software engineer

#213

Post by kristopolous » Mon, Apr 01, 2019, 10:48 PM UTC

drugme wrote: post #211

kristopolous wrote: post #188

Earlier quoted context omitted.

If I smell any bs then I immediately change tactics and make sure I put them deep over their head. For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?" There's 3 ways to answer these kinds of questions and it exposes you as either a genius (or in this case a linguist), a non-genius (real geniuses are as common as 7.5 ft tall people) or a bullshitter trying to look li…

For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?" What's the point of grandstanding like this? To make yourself feel smarter than they are? My way of dealing with bullshitters (who in general are surprisingly eager to reveal themselves as such -- there's no need to lay special traps for them) is simply to say "Hmm - okay" and politely end the interview at the near…

It's a 1-on-1 interview (not in front of others). Ultimately the point is to help the person.

When interviewing and I didn't get a job I always desperately wanted to know how to improve things next time and nobody would tell me. Instead there was this little canned BS email from HR "after much consideration blah blah blah" stop that ... tell why!

This goes one step beyond telling. Show people why. Show them what they are doing, when they are doing it, how you can see it, why it's bad, why it hurts them and help them not do it in the future.

Give them an offer to correct it after you've made it clear (this is like throwing an exception in programming versus silent failure). Reset the clock and try again if you want. Maybe they're actually great and you read them wrong (they might be a "good program" with your bad input). The interviewer isn't some flawless executioner.

Most interviewers don't act like characters out of an Ayn Rand book. At the end of the day they care about others and know they have bills to pay. Doing this shows "this is why this job can't happen". Try to be their best interview for a job they didn't get.

The candidate doesn't walk out the door with ambiguity or false pretense or the illusion of doing well. Nor do the decisions come across as arbitrary and indiscriminate. They know exactly what action they need to take for their next opportunity.

If they don't get the job on offer, the best you can do for them is help make sure they can get the next one.

Re: How not to hire a software engineer

#214

Post by drugme » Mon, Apr 01, 2019, 11:00 PM UTC

kristopolous wrote: post #213

drugme wrote: post #211

Earlier quoted context omitted.

For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?" What's the point of grandstanding like this? To make yourself feel smarter than they are? My way of dealing with bullshitters (who in general are surprisingly eager to reveal themselves as such -- there's no need to lay special traps for them) is simply to say "Hmm - okay" and politely end the interview at the near…

It's a 1-on-1 interview (not in front of others). Ultimately the point is to help the person. When interviewing and I didn't get a job I always desperately wanted to know how to improve things next time and nobody would tell me. Instead there was this little canned BS email from HR "after much consideration blah blah blah" stop that ... tell why! This goes one step beyond telling. Show people why. Show them what they…

Fair enough - thanks for clarifying.

Re: How not to hire a software engineer

#215

Post by sk0g » Mon, Apr 01, 2019, 11:03 PM UTC

jahrule wrote: post #80

sk0g wrote: post #70

Earlier quoted context omitted.

When asked for an assessment of a co-worker, providing said assessment is immature and somehow discriminatory? What do you even think is the point of references? Not everyone's great to work with, I'm sure you have had a few co-workers you would rather not work with again, right?

yes, doing what the previous poster did - giving vague "bad signals" even against company's policies - is what i consider immature and discriminatory. references in form of background check - worked years a, b, c, on projects x, y,z - yes, sure. references about performance, likability, etc - why ? how are you going to judge that ? are the references legit ? are you going to get references on the reference giving peo…

Reference = "A letter from a previous employer testifying to someone's ability or reliability, used when applying for a new job." [0]

What even is your rant about? Managers especially can easily tell your performance, how you get along with everyone, etc. That's the whole fucking POINT of a reference.

https://en.oxforddictionaries.com/definition/reference

Re: How not to hire a software engineer

#216

Post by dennisgorelik » Mon, Apr 01, 2019, 11:10 PM UTC

tombert wrote: post #154

Years ago, I was interviewing, and they asked me a fairly typical "Design Twitter" question. I always hate these kinds of questions because it took Twitter 10 years to get to where it is, and I'm certain they didn't design all of it in 15 minutes on a whiteboard. Anyway, I'm drawing little boxes and arrows, and when the subject of a DB comes up, I ask "do you want availability or consistency", because I figured that…

Did that interviewer hire you after admitting that you were right in pointing out his mistake?

Re: How not to hire a software engineer

#217

Post by drugme » Mon, Apr 01, 2019, 11:14 PM UTC

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.

Another fun aspect is that, surprisingly often, these "tests" are poorly (and in some cases, plainly wrongly) articulated and/or simply not do-able as articulated.

Or do-able, but they end up requiring 2-4x the "just a couple of hours" they asked for to be done reasonably well.

After which at some point one starts asking one's self: "Do I need this industry actually?"

Re: How not to hire a software engineer

#218

Post by geomark » Mon, Apr 01, 2019, 11:48 PM UTC

jahrule wrote: post #64

geomark wrote: post #49

Earlier quoted context omitted.

Mostly this. I was a hiring manager at a big company where HR made it very clear we cannot give specific feedback to applicants. We also could not give references for the same reason; fear of being sued. But after a while you learn to speak in code for those cases where you really feel you need to provide meaningful information. The last time I was asked for a reference I was contacted by a hiring manager who said th…

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

I wonder how that is actionable. I did not say anything about the candidate. Just the opposite, I was clear that I cannot say anything about him. What I said was very generic and sound advice for any hiring manager. Any negative information concerning the candidate came from somewhere else after the hiring manager did more digging. So any legal action would have to target my intent, not what I said. And my intent was for the hiring manager do a complete assessment before making a decision, which is of course sound advice, and the same advice I would give for any candidate. Good luck suing me. If the candidate wanted to sue someone they would go after whoever provided negative information, which was not me.

Re: How not to hire a software engineer

#219

Post by hinkley » Tue, Apr 02, 2019, 1:13 AM 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.

This has become more worrisome of late since the number of workable toolchains seems to be increasing. The fraction of jobs in this town I could be eligible for (without a lot of tapdancing) is much smaller than it used to be, despite the fact that we aren't really doing all that much that's different than ten years ago.

Re: How not to hire a software engineer

#220

Post by hinkley » Tue, Apr 02, 2019, 1:15 AM UTC

systemspeed wrote: post #180

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…

My experience has been that interviewers like you are rare. I may have reflected on my observations incorrectly, but it seems to me that depending on a newcomer to quickly learn a language and adapt is seen as a high-risk investment. I consider myself an adaptable person, and while I was able to make this impression upon prospective employers in my early days, they would always weigh this against the cost of training…

Yeah, too often I've had interviewers who were far too eager to go and go all the way down to the minor corner cases of a problem (even if I try to beg off of them) and in the end I have no time to ask interesting questions. Questions that might reveal more about my skills than the last two corner cases.