Live data from Hacker News

How to Interview Engineers When You're Not Technical – Part II

greghausheer.com

71–80 of 94 posts

Re: How to Interview Engineers When You're Not Technical – Part II

#71
post #49

Or get two candidates and ask them to ask each other questions. Ask them to score themselves and "opponent". Infer score yourself. Promote winner to next level to interview other winners, until final battle. Brutal, but what can you do when you're not technical?

Jesus Christ. Somewhere a hiring manager is explaining the benefits of this to human resources. Step 1 - regular interviews. Step 2 - group interviews including memory check with coding task Step 3 - this thunderdome you just created.

We never did group interviews but did try panel interviews as we noticed the order of interviews ended up skewing how we felt about a candidate.

Re: How to Interview Engineers When You're Not Technical – Part II

#72

Earlier quoted context omitted.

Please read the article further down. The author explicitly says: > It's OK too if an engineer doesn't have any side projects. I always ask about side projects to give candidates an opportunity to highlight their side projects, not because we require candidates to have side projects. I'm sure some hiring managers out there have side projects listed under their "must have" criteria, but in my experience the good hirin…

One thing that I've never disliked about hiring managers asking for side projects, is that when I work on one, I do what interests me. I like trying new things, experimenting on stuff that I don't know how it will turn out. When I get bored or I hit a dead end, I stop. A lot of it is unfinished and messy. It's for me, not anyone else. My time is valuable, especially outside of work.

Not only that, but when you are programming for yourself, you can take on practically infinite risk. There is no downside. When you are programming for the company, you have to err on the side of conservatism. Sometimes the only way to break through to another level is to take on that risk and see how it turns out. It says a lot about a programmer that their portfolios consist of lots of efforts that don't end up with a "product". They have tried a lot of stuff that you can't reasonably try in a work setting.

Re: How to Interview Engineers When You're Not Technical – Part II

#73
post #61

Earlier quoted context omitted.

Exactly. When I was a junior I had plenty of side projects that I rotated through. Then that got old, I developed deep passions for other non-computer things, have a family, enjoy knowing people, and what do you know? Not many side projects that involve programming. I haven't updated my blog in 15 years. I'd rather go fishing with my kid, rock climbing with my bud, or banging together a garden with my wife.

Seems to me it still makes sense to only hire people who program in their free time... if your real goal is to hire people willing to do a lot of overtime work. (I am not saying this is a good thing to do.) Things that prevent you from programming in your free time are more or less the things that would prevent you from working overtime. Or it could simply be thinly disguised ageism. "Hey, I am not saying we shouldn'…

As someone who specifically chose not to have kids because I want to spend more time programming (crazy, I know)... I'm not that interested in working overtime for the company. I'll do it in emergencies, but my time is my time. I only have so much of it and there are things I want to do. No amount of money, or recognition, or pride in helping someone else get rich will give me that time back. Just because I want to spend my time programming, does not mean I want to give it to someone else.

Re: How to Interview Engineers When You're Not Technical – Part II

#74

Or get two candidates and ask them to ask each other questions. Ask them to score themselves and "opponent". Infer score yourself. Promote winner to next level to interview other winners, until final battle. Brutal, but what can you do when you're not technical?

You joke, but an interview for a Australian government agency I did (can't name it for fear of assassination) I was asked by interviewers which other candidates in the group interview I would work with and why. They were not at all technical.

Re: How to Interview Engineers When You're Not Technical – Part II

#75

Or get two candidates and ask them to ask each other questions. Ask them to score themselves and "opponent". Infer score yourself. Promote winner to next level to interview other winners, until final battle. Brutal, but what can you do when you're not technical?

Ha. If I got paired with some loser by a manager that pulled this, I'd make sure that said loser got the job.

Re: How to Interview Engineers When You're Not Technical – Part II

#76
post #33

Earlier quoted context omitted.

We also should not propagate the caricature of the developer. You know, the all I need is gallons of coffee and I’m off grokking code all day in a hoodie. I’m off to my Kubernetes meetup! Whoops, just dropped my giant math is fun textbook.

/me looks at a pile of empty coffee capsules, /me looks at the hoodie, /me looks at the (unread) giant math is fun book, I hide in shame. I do agree though, especially in hiring I find it weird to expect people to have their hobby being the same as their job. I'm quite curions if there is another profession where this is the case. Photographers maybe?

I'd say anyone who is a maker. Someone who creates things creatively.

There is a good chance your carpenter has a workshop at home. If you have the kind of mechanic who likes will modify your car, they probably do their own car too.

Re: How to Interview Engineers When You're Not Technical – Part II

#77
post #54

> What's the one thing you would not compromise on as you write code? Code that works. I'll take a gordian knot that works over an over-engineered system that fails or never ships. Some of the worst code I've seen comes from engineers who focus on "unit tests, documentation, and refactoring code." Those are all good things, but they aren't #1. The "done" question is a very good one.

I completely agree about the unit test point. I'm not arguing that it's useless - quite the opposite. But it's damn hard to write useful unit tests. I've seen a case where an internal IT team took ownership of code I delivered. A few months later I was asked to make some enhancements, and I found that they've added a lot of unit test code. It was absolutely useless. Essentially, they were testing the compiler, not my code. Complete waste of time.

Re: How to Interview Engineers When You're Not Technical – Part II

#78

Or get two candidates and ask them to ask each other questions. Ask them to score themselves and "opponent". Infer score yourself. Promote winner to next level to interview other winners, until final battle. Brutal, but what can you do when you're not technical?

Ha. If I got paired with some loser by a manager that pulled this, I'd make sure that said loser got the job.

Devious, but delicious. The punishment fits the crime.

Re: How to Interview Engineers When You're Not Technical – Part II

#79
I really like problem solving and estimation questions during interviews, and I favor them over coding skills, etc. A question that I frequently use is how long would it take to evacuate a city like Phoenix, if there was a 24 hour warning that some dictator du jour is going to drop a nuke. It boils down to assessing a throughput of various modes of transportation: cars, buses, trains, airplanes, and yes walking. One candidate responded "by helicopters" at which point the interview was pretty much over.

Re: How to Interview Engineers When You're Not Technical – Part II

#80
post #20

Earlier quoted context omitted.

"What's the one thing you would not compromise on as you write code?" Its not hard to figure out the right answer to that one: "I never compromise. Must be perfect." But of course that's not true. There are always pathological conditions that can reasonably ignored especially in the first release.

> "What's the one thing you would not compromise on as you write code?" Its not hard to figure out the right answer to that one: "I never compromise. Must be perfect. That is actually the worst possible answer I can think of. Pretty much any answer would be better than that. It demonstrates that the person either: 1. isn't honest or 2. doesn't understand basic engineering concepts

3. will be a dangerous, pain in the ass to work with
Post reply on HN