Hacker News Reader

Comment by gt565k | Hacker News Reader

I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.

View on HN

I once got asked to spin off an ec2 instance from an image provided by the company I applied to, and then answer certain questions about the dataset on that thing. I had to write actual code to obtain the answers. All that had to happen within 24 hours. Then there was an on-site interview where they asked questions about stuff like JVM garbage collector fine-tuning and such. That was the best interview I had, ever.

Which is fine and dandy until you get that one person that cheats by getting help from someone else.

That is why you discuss the implementation in-person and ask questions about the design decisions...

As if people who interview for Google don't just look up the most common interview questions and memorize answers before the interview...

Still I think that would become obvious pretty quickly. I've actually had people start writing out a textbook algorithm that just solved the wrong problem. And then completely stumbled when trying to explain how the program would arrive at the intended result.

I usually ask questions until the person is out of his comfort zone, and if he is completely clueless on how to proceed at that point it's a red flag.

good thinking, very nice solution.

Reply on news.ycombinator.com