Hacker News new | ask | show | jobs
by ashwinaj 3012 days ago
I've thought a lot about this (and I'm sure others have to); I think candidates generally fall in two buckets:

1. Can code:

    a. Gifted: 
These have a natural talent for coding and can crank out code at the drop of a hat

    b. Persistent: 
Have moderate-good talent for coding, they make up the gap with gifted coders with sheer persistence and relentless pursuit for making themselves better

2. Cannot code/haven't coded in a long time

How can you test for coding? In my view it's certainly not some academic question or the in-vogue programming interviews book. This is clearly proven to be red herring. Also at least in the bay area, there are set questions that FANG and other companies have which are shared all over the internet and amongst friends who work there. So an interview becomes a casting process for a role, where the script is the questions you have "rehearsed". This is an absolute facade and needs to stop!

I ask simple programming questions and look for "naturalness" in the way they answer and talk through the solutions. No complicated brain teasers or the smug "look at me, I know this obscure/complicated algorithm invented before I was born" questions.

Coding is one facet, the other one is design. No matter how good a coder you are if you have bad design skills it doesn't matter. How do you test for design?

1. Resume experience: Talk through technical issues/challenges, pros/cons etc. of projects they've done before

2. A simple-moderate design question: If someone lists distributed systems as one of their skills, ask them a question on it. A decent amount of determination can be made about a candidate they way he/she answers.

I'm refining my process after each interview I take and would love feedback.

1 comments

I create a sample project based on real world coding problems we face everyday. The actual class is a skeleton with non working methods and comments describing what the methods should do.

I then have another test class with simple failing unit tests. They have to write the code to make the tests pass.

Then I give them more complicated failing unit tests that they also have to make pass without causing the first set of test fail.

We do pair coding and they can ask me any business question they have if they don't understand a requirement.

They can use Google if they need to during coding.

Thanks, that sounds like a good way to screen someone.