h8_interviews

If I could get you to express that in an interview, I'd say something like "do you have any tools you find value in customizing?" and try to lead the direction in whatever you think of as "custom" in your world, so I can hear how it helps you be effective, so I can understand what you think it means to be effective.

I probably shouldn't have picked text editor as the example, it's really not about that.

> The point is to hire people who mastered skills different than what you have.

That's the job of the other engineers. I only know how to screen for the skills I do have.

Most engineers spend all day in their text editor and on Google, debugging code and searching for solutions.

I have never met a good craftsman that doesn't customize their tools.

I'm not saying everyone has to customize their editor. But if you move quickly and intuitively through the chrome debugger, the only way you got that skill was by doing it every day for way too many hours.

Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

> 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.

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.