5 ms·
I was in the "on-site loop" for a company you've likely heard about. When we were smaller, I was tasked with writing an interview question for JS devs. I crea
by h8_interviews 4y ago
I was in the "on-site loop" for a company you've likely heard about.
When we were smaller, I was tasked with writing an interview question for JS devs.
I created a handful of unit tests that were all really easy questions technically, though maybe a little obscure, because they were designed to spark dialogue. Think "escape room", solve one test, move to the next. Google was allowed and actively encouraged.
But it wasn't really about the tests (they had to pass, of course, and shockingly some didn't). A not-very-good candidate would still make it to the end and solve all the puzzles and get a rejection.
The goal was to create a lot of jumping off points to sort of "break the 4th wall" and see what the candidate actually does to solve a problem. If I could get someone to search the web as the fastest way to solve something, that was almost always a great sign.
Sometimes I can see them building an inefficient answer and ask them if they'd like to search online for an easier algorithm, and remind them to treat this how they would actually treat their job. Some people stubbornly refused.
If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors. Do you hate vim? Great, tell me why. Do you love emacs? Show me a lisp snippet or whatever you think is cool.
I'd see a lot of `console.log({ foo, bar })` but also some `console.log("foo: " + foo + "\nbar: " + bar)`. I'm not judging harshly on any one particular thing, but I just want to see some level of craftsmanship about something. If you're from the java world, cool, show me some intellij tricks as you're working in webstorm.
Do you reach for the repl/debugger to try out ideas by default? Good sign.
To me it's simple: would I want to work with this person? could I recommend the company hire them based on how they work? I can't actually work with you, so I want the closest thing I can do in an hour that feels like we're on the same team.
I think the question is now retired because it didn't scale, or maybe it's still there with a rubric that invalidates the point of it.
If anyone's trying to do ML in this space, try softball questions that require more search and discussion than code, then NLP the discussion and ignore the code. Use internal mock interviews to train it to match your target culture. I think that would make this approach scale.
I personally found pretty good success with the people I interviewed this way as peers, but I wasn't in a position to find out if they were really successful or not by internal metrics.
- baskethead 4y agoYour technique has already been proven to create unconscious bias, because you are more likely to hire people that are like you. You even said it yourself, you want to work with people that you like and that you get along with. Here's one of hundreds of articles that talk about this: https://www.forbes.com/sites/forbescoachescouncil/2018/05/01/why-you-mistakenly-hire-people-just-like-you/?sh=16de3b683827 https://www.forbes.com/sites/forbescoachescouncil/2018/05/01... Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.
- adenozine 4y agoThe other alternative is soullessness via standardized tests. Why? Isn’t it better for people to hire people?
- deleted 4y ago[deleted]
- h8_interviews 4y ago> You even said it yourself, you want to work with people that you like and that you get along with. And you.. don't? > Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry. I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts, especially interviews. At some point, you have to trust your team to build your team. Not everything can be blindly metrics driven. You're hiring humans to work with other humans.
- Jensson 4y agoThe point is to hire people who mastered skills different than what you have. You see interest in text editing as a major factor, but there are probably many software engineers who have no interest in text editing and just writes stuff manually with no focus on tricks, and are still very productive since really writing 100 lines of code is just a few minutes of typing but still plenty for a days worth of work.