Hacker News Reader

Comment by rolltiide | Hacker News Reader

> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.”

Yes the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do.

Indeed I interview my candidate's ability to find resources, to know what considerations are needed, how to deal with IDEs, collaborative tools, the git protocol. I will fire someone on the spot for implementing an academic algorithm if there was a library and potentially peer reviewed library they should have used instead.

View on HN

> the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do

The process for successful interviewing at places that use whiteboard testing for interviewing involves digging in and putting in a lot of hard work studying previously unknown concepts-- work that most people don't consider very fun.

To me, this sounds like exactly the kind of thing that a person will need to do to be successful in their first few months in a big company. Learning about their particular systems, authentication and authorization methods, security audit procedures, deployment methods, how they do dependency injection, logging, diagnostics, troubleshooting...

And I think those “maker” types of roles don’t need a hard C.S. screen. But algorithms aren’t just about reimplementing the classics. There are points even in ordinary “DB front end” type of work where understanding algos will affect how you scale. You may find you’ve just been getting away with brute force approaches because that data sets were small. You can go very far like that but there may come a day when it matters and then it will really matter.

...and when that day comes you call a specialist to handle the case and let your "ordinary" worker get back to work on the 99% of the job space she's qualified for?

I find this very ironic: Hiring for suitability to handle edge cases is also a brute force approach that doesn't scale.

A good algorithm optimizes for expe ted inputs and farms out cache misses and unexpected behavior to some other system.

I don't disagree with you, and it all comes up after the 20 second standup and in the code reviews, not in the interview, and not in a two week long orientation

Overfitting for the possibility that it might be necessary in a design choice is not the way to gatekeep candidates

Are you hiring?

No, but I hope other organizations can adopt my approach.

Reply on news.ycombinator.com