Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

greghausheer.com

Post reply on HN
Print view View original

41–50 of 94 posts

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

#41

Post by supernova87a »

You know, one of the things I found most amazing about interviews and the hiring process was that to a large degree, the things that a person says in an hour session determine whether they will get hired.

Yes, not their references or resume (at a certain stage) or what they're able to prove that they coded, but the things that they are able to come up with to say. Doesn't that strike you as sometimes amazing?

Now, that may be a crazy notion and flawed in many ways, but I came to realize the following. The reason that that is often acceptable is that it frequently is a good proxy for weeding out the unqualified. In this sense:

If someone doesn't even know to say that something is important, or that they solved a problem a certain way (regardless of whether you have proof the actually did it), they probably have never even thought about those things being important.

If someone tells you (just offhandedly) that they solved something by jumping right in to doing x,y,z at the detailed level and coming up with the technical solution (the algorithm), but not the project planning or scoping part of it -- they probably have no idea or experience about what's necessary to plan out a project. They may not be good at estimating or communicating. They may be someone who gets lost in the details. If they have no pitfalls to warn against, probably they haven't even seen how a project has gone wrong before. They are probably not a good candidate for a senior developer role.

Whereas, if someone knows to say that they had to do some top level estimating or quick pass of which solutions would be the best from a cost/resource standpoint, consider the timelines to implement and risk of doing so, how to decide who on the team would be put on the project and in what sequence, etc... Then I know that they at least realize these things are important.

(Yes of course you should probe deeper. And I know that this applies to some kinds of roles and not others, but since the article is about interviewing for non-technical people and is often about hiring for a role requiring a higher-level hiring decision)

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

#42

Post by FalconSensei »

slg wrote: post #37
dominotw wrote: post #27

Earlier quoted context omitted.

yea ofcourse, if someone is better at skills you are looking for then by all means coding hobby is irrelvant. But what if all else being equal, why would you not choose coding hobby candidate.

If we are going the "all else being equal" route, one could argue the hobbyist is a worse candidate because they have spent more time working and thinking about programming but still haven't been able to demonstrate their skills are superior to someone who has spent much less time refining them. Give me the person who is able to get the same thing accomplished with less effort and time.

Also I would imagine that the person who also code as a hobby is more likely to have a burnout later on. Just a guess though

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

#43

Post by sfkdjf9j3j »

dominotw wrote: post #10
FalconSensei wrote: post #5

Earlier quoted context omitted.

> Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.

but don't you think its a fair guess that someone who hobby is X might be better at X than someone whose hobby is Y.

This seems to be a pretty sensitive claim, but it also seems completely reasonable to me that people who practice something more are better at it than people who practice something less. Even if it's a completely different domain than your work, it's still developing your intuition and exposing you to new abstract concepts.

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

#44

Post by spacechild1 »

yoz-y wrote: post #33
runawaybottle wrote: post #8

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'm quite curions if there is another profession where this is the case.

Any artist, really. The line between work and leisure are blurry at best.

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

#45

Post by hinkley »

lxe wrote: post #32

How do you calibrate yourself on these open-ended questions? How can you compare one good answer to another completely different good answer and figure out which one is better overall? You can't rely on a "The very best engineers have a checklist they apply depending on the type of bug." type of framework here -- each "very best" engineer might have a completely different way of doing things. You have to have at leas…

> The very best engineers have a checklist they apply depending on the type of bug.

This is misleading at best.

Masters do less work than beginners. They have years of intuition built up that let them apply heuristics extremely cheaply and save their energy for solving the novel parts of the problem. There is no 'list'. There is only the verbal part of the brain trying to introspect on what just happened. Sometimes accurately, but quite often not. The ones who get it even close to right become mentors, instructors.

I can spend as long as you like explaining my debugging process and the first time we sit in a war room you'll call me out for not following my own 'list'. Every situation is either unique or the result of a lack of self-reflection (why do we keep solving the same problem over and over? Are we not programmers?)

The biggest danger to people who can't explain at all is when advances in their field arrive and they can't introspect enough to adjust their behavior. There are limits to how much you need to address this in an interview process. For many of these people, they'll already be in that space when you meet them and easy enough to spot.

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

#46

Post by SilasX »

There's also a general technique for filtering experts when you don't know their domain well: ask them do something known to be impossible. [1]

Very bad answer: "Sure, no problem." [2]

Bad but tolerable answer: "Not possible but it's too hard to explain why."

Good answer: best attempt to explain why it's not possible, and the nearest solvable version or what you would need to change to make it solvable.

There's a great Better Call Saul episode (s4e5) where an expert is idenified as a unsuitable (in part) because he insists a project could have a firm maximum duration without caveats about what could go wrong, and he could do it without something it obviously needs.

[1] That's arguably what the unnamed MP was doing when he asked Babbage if he'd get the right answer if he put the wrong numbers in the machine:

https://en.wikiquote.org/wiki/Charles_Babbage#Passages_from_...

[2] At best they might silently replace it with the possible version, but that's still hiding the tradeoffs from you and means they could be misrepresenting other answers.

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

#47

Post by mirekrusin »

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?

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

#48

Post by strken »

dominotw wrote: post #10
FalconSensei wrote: post #5

Earlier quoted context omitted.

> Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.

but don't you think its a fair guess that someone who hobby is X might be better at X than someone whose hobby is Y.

As someone who runs interviews occasionally, when you're sitting in an interview room, you're not making an immediate decision whether the candidate is better or worse - that comes after the interview. During the interview itself, your job is to learn as much as you can about the candidate. The biggest problem for both you and the candidate is that you might get to the end of the interview and still not be sure whether they're a good candidate, and therefore have to reject them.

You've got two probabilities to work out, "how likely is this person to succeed in the role we're hiring them to do?" and "how confident am I in the previous number?" Side projects usually don't change whether you think the candidate is a good fit (at least for me), but they usually do increase your confidence in your prediction, and turn some no-hires into hires.

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

#49

Post by Loughla »

mirekrusin wrote: post #47

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.

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

#50

Post by j45 »

pdonis wrote: post #35
j45 wrote: post #17

There are some good questions here. Still, if you're non technical when interviewing, how would you know the right answers to technical questions? Eliciting underlying thoughts about problem solving is important, but is more than just saying the right keywords. If interviewing is not much more than a game of keyword DDR, it makes successful outcomes even more challenging. Maybe hiring is broken because it is designed…

> if you're non technical when interviewing, how would you know the right answers to technical questions? My reaction to the article was similar. My answer to the title question would be: "Find a technical cofounder you can trust."

Absolutely. Don’t take advice from someone who doesn’t have relevant experience.

I find a much better success rate in not hiring he traditional HR ways. Tech folks are not linear workers with floors and ceilings, they are growing much faster and on multiple layers at the same time.

It’s humorous when non technical ppl try to manage things they don’t understand.

That table seems to be currently being turning in society because of covid, if you ask me.

Technologists will have to move into each area of management, because maybe it’s technologists turn to learn and manage business after such a long time of business trying to manage tech.

Post reply on HN