Hacker News Reader

Comment by jbryson3 | Hacker News Reader

I agree with this wholeheartedly.

As an engineering candidate, how do I display these traits?

As an interviewer, how can I test for these traits?

As a candidate, when there are companies I'm interested in working at I research the hell out of them. A lot of companies will put employees on their website and I will research the profile of every person on it. If they don't, I find all the employees I can other ways. If they have an engineering blog I read everything I can, then I research the authors. I research the investors, the market, including competitors and any analyst commentary I can find. I look for past employees and try and calculate a rough idea of churn rate. I basically build as perfect a model of the company as I can as an outsider, and then I test the model throughout the interview process, updating as I go. I make it clear to people that I've done this through ways both subtle and obvious. "I noticed on your profile you were at X last, did you work with Y?" "From my research it seems like your CTO left earlier this year, can you tell me the story behind that?" "This journalist says you're doomed, which is funny because you don't look doomed, but what would you say to them if you could talk to them directly?" Etc.

Yes, this involves a lot of online stalking people. Honey badger doesn't care.

> As an interviewer, how can I test for these traits?

This is one trick I haven't figured out.

I can ask problems that require tenaciousness to dig all the way to the bottom. BUT motivations and incentives in a 45min interview and an ongoing job are very different. There's a higher reward in the job interview, and you know an upper bound to how much time it'll take.

I've hired people who aced that, but then were pretty lazy day to day, even for looking up trivial stuff like "you submitted a python code review that wouldn't even run because you made a typo in the method name."

Stories can help, but stories are (even assuming true and not borrowed) from a past version of the candidate which may not be the same as the present version.

So I just do the best I can, but also recognize that I won't necessarily get a 100% perfect employee no matter what questions that I ask. But "pretty good" is about all you can realistically hope for, I think.

You need to be your own honey-badger. :)

There are two very important tests to consider hiring someone:

- how a candidate handles feedback and negative situations like disapproval and rejection

- whether they delegate thinking or take ownership of solving hard problems

If they fail either, that’s a deal-breaker. Also, make the candidate pipeline as uniform, fair and repeatable as possible.

- anonymizing resumes by masking pedigree, names, addresses, etc.

- ask generally the same questions, while branching differently based on their responses

- perform social and skills tests as similarly as possible

”Be the change you seek”

In my experience, a lot of interviewers will ask questions along the lines of "What's the trickiest problem you've had to deal with?" I feel like those kinds of questions are excellent for bringing up this sort of thing if the candidate is so inclined. If they go in a different but still not disappointing direction (e.g. coming up with a process for stable development an environment where requirements are constantly changing), you might re-ask with the focus more on problems encountered while coding.

And, to paraphrase another poster, be a honey badger about it. "And then what happened? And then? Why did you do it this way? Why did that fail? Why did <cause of failure> happen?" until you get to the bottom of the story or hit a wall ("dunno. My boss took care of that"). If the candidate can explain what the root cause of the problem was, how they identified that root cause and then proceeded to fix it, that gives you a pretty good idea of how tenacious they are.

Well, if you have such a trait then you can figure it out yourself.

Reply on news.ycombinator.com