Comment by throwaway42668 | Hacker News Reader

Comment by throwaway42668 | Hacker News Reader

The "nano" questions are silly and tell you nothing useful about the candidate other than I guess their level of candor in being subordinate to obsequious lines of questioning.

However, the rest of the questions are just as pointless too.

As a hiring manager and product owner, the level of familiarity that an engineer has with using debugging and diagnosis tools (e.g. as simple as how to attach and effeciently use a debugger) is 100x more valuable to the predictable delivery and quality of the things they're building than Programming 101 trivia.

Writing code is quite possibly the easiest, least fraught time-sucking milestone-missing part of software development. The morass of the entire rest of the SDLC is where ambitions and dreams go to die. Version control expertise, build system esoteria, correct configuration & setup of dependencies, understanding how to test, being able to do more than printf'ing your way out of a Russian nesting doll inspired paper bag. That sort of thing.

Then a good nano question would be if they know what a debugger is or how they use it. Or any of those very generic questions that any half decent programmer will know, but others won’t.

These questions are made to filter out the pure frauds. People who claim to have 10 years experience but have none. Those who claim to have a CS degree but it’s a fake diploma, etc. They aren’t meant to tell the good developers from the bad.

As said in the article, these questions are risky because they annoy experienced developers. But it’s also a waste of time having a person who never programmed in their life go through a deep interview about api design or architecture.

Sure, though I'd ask more open ended questions about a problem to see where they go with it.

Maybe they land on using something like a debugger or wireshark or strace or whatever makes sense to dig into whatever horrible voodoo is plaguing them. The important thing is that they are creative and experienced at questioning or confirming their priors and eliminating thousands of paper cuts and yak barber shops for themselves, their team, and their organization, so that collectively everyone is enabled to operate at a high-level instead of everyone constantly bushwhacking their way toward eventual failure.

That’s the recruiter’s job, not the interviewing engineer’s. Once a candidate gets time with an engineer, the assumption should be that they are at least kind of good, and not an outright fraud. A good enough fraud might get through this, but a genuinely good engineer might not get through the nano questions.

I never had any success working with recruiters. I have only had success when doing everything from screening CV’s to the end. I think having a ”chain” with HR, Recruiters etc is an antipattern.

We can't be friends. Printf is literally the best.

Reply on news.ycombinator.com