Hacker News new | past | comments | ask | show | jobs | submit login

> It's not like we were asking candidates "hey, how did you enjoy your last software security job?". We were doing something closer to "here's a piece of code with a heap overflow in it; talk us through how you'd write an exploit". It didn't work: there were people who could answer those questions indistinguishably from an exploit developer who nevertheless couldn't write a 1995-era stack overflow exploit if their life depended on it.

Something about this example is not registering for me. I can't imagine how this situation is possible. Going from a detailed, step-by-step description to a code implementation is a trivial rote task in my mind. I must be missing something.

I mean, I've seen very technically proficient devs fail to deliver because there's too many cooks in the kitchen, or because they drown themselves in tooling or bikeshed their project to death. Maybe something like that happened?

There's definitely tons of senior devs out there that care way more about linting and unit testing than they do about writing the code that implements the spec.

Nothing hit quite as hard as the punch to the gut from the bit about linting and unit testing... spot on. I've already decided to move on and such, but my current company is so this that it hurts.

I don't have a perfect theory for it! It's just something I've repeatedly seen happen.

Happened to me. I hired someone onto my team who did great during the interview. The questions weren't puzzles, but live coding sessions. He got all the way to the point at which he had written a semi-functional web server.

This guy couldn't deliver a single project and would spend days debugging issues before he asked for help and I or someone else on the team would solve it in a couple of hours or less. I have no idea why this happens, but I've seen it twice.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact