A related skill is being strategic about what really needs to be done right now. If you hit a roadblock, some people will just stop. Some will ask around and stop if there are no easy answers. Some will persevere until they hit their head so hard against the wall that the wall gives way.

Some people will check if this is really a critical thing to accomplish right now, and just work around it when it makes sense. This can be the difference between 100% done, six weeks late, and 95% done on time, with a small outstanding improvement left to complete. It may even be easier to do when other work is done first.

Sometimes you can't go around it -- then the honey badger does surely take the day! But I've found (and seen) a lot of success in asking yourself / a Product Owner if a feature can be delayed, or even cut.

Well, its the age old pragmatism versus idealism dichotomy. One isn't better than the other, except sometimes.

I don't feel "agile" is the same as being smart about scope cuts, or about shaving yaks that aren't in the way, so I'm left feeling that your comment was ...a bit of a shitty place to drag the discourse. :)

In other words then, I'm more inclined to think of what I was saying as that it may be better to hold off on shitting at all if you're having a hard time, than to decisively shit your pants long after you've left the toilet.

I always thought that "agile" was "you're doing it wrong".

It's a useful skill, but not a good career move. Early in my career, I used to fix bugs in a mainframe operating system. When I took a new job, I was given two stacks of paper crash dumps, each six feet high. I had to figure out what had caused each crash with paper and pencil, then fix the assembly code. It took me about a year to get the mean time to failure of the OS from a day to a month.

Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause.

I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom.

(This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)

I developed this skill because of a combination of social anxiety and wanting to keep my first job.

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.

Great skill, but a far better skill is knowing when to give up and move on from the problem instead of wasting days on something while other backlog work piles up.

Well that applies to every task, not just to problem solving. "Work hard" doesn't imply "neglect your wife and kids".

That's a good way to only be assigned easy tasks.

This is basically my only skill. I just don't stop google'ing for answers. If i run into something I just keep working until it works.

I think most of the problems a honey badger solves aren't google-able.

Parent comment could refer to self study in a domain until they know enough about what's in front of them to better tackle the problem.

As someone who is an alt student, working as SFE while going to school at a traditional University, I've noticed the opposite of this mentality a lot. Expectations of being told how to do everything and literally getting upset when the prof doesn't give them enough. Will note though the guys who are also alt students, surprisingly higher than I remember/noticed when doing my first undergraduate, tend to not have this mentality and are usually the people I talk to when I am really having issues. Feel like this is something that took me entirely too long to learn or at least too long to realize that I needed to learn it. I'm sure I was the same way when I was 19-22. Just thought this comment stood out don't care to get into the failings of academia.

I think my relative success comes down to one basic thing: When I learn new things, I focus on essentials first, and always. I gain normal skill like anyone, but I do feel like I retain the essentials better than the next hacker. I can't recall a time I've ever said, "oh, I used to know _____ but it's been too long." I've always been able to get back into old saddles. It's been like this most of my 25 years in the industry.

Relevance: retaining essentials confers ability to honey-badger more things in more ways.

I came in here to post exactly this. It's hard to demonstrate but I will take time to listen to a candidate if they have a horror story about debugging something painful.

Occasionally there will be a post on HN about someone who debugged a compiler bug or a even a hardware bug, and it lifts my spirits.

The danger here is that you have to make sure Honey Badger's manager doesn't see him/her seemingly making no progress toward a solution. Honey Badgers might be solitary animals, but software engineers are social creatures.

I agree that these are useful ways of solving problem, but its rarely that anyone asks about that sort of skill in an interview.