21 ms·

The problem with looking at OSS and publications is that this penalizes a lot of people with real lives outside of work. Especially problematic if you’re into e

by Swizec 5y ago

The problem with looking at OSS and publications is that this penalizes a lot of people with real lives outside of work. Especially problematic if you’re into equitable hiring processes aiming to hire people who aren’t in their 20’s anymore. Looking at past work penalizes people who primarily have experience in large systems where their work is NDA’d, impossible to understand without a loooot of background, or simply unshareable for any number of reasons. Also really bad for new entrants into the industry. They don’t have past work. The take-home exam penalizes people who have lives. The “do smol thing together so we can talk about it” interview penalizes people with performance anxiety. There is no silver bullet. But if I’d have to choose, I’d pick the least bad typical interview approach that judges everyone based on their performance on a small job-relevant task. At least you avoid a lot of bias. source: I’ve interviewed over 100 engineers over the past 18 months as we scaled the engineering org roughly 3x. I honestly don’t even look at candidates’ resumes anymore (this is after initial screens have been made) because it always leads to bias.

pthread_t 5y ago
> The “do smol thing together so we can talk about it” interview penalizes people with performance anxiety. Does this apply to the Leetcode style interviews?
- Swizec 5y ago
  If they’re any good. But really, it depends what people think of when they say “Leetcode style interview”. There’s a lot of coding interviews that superficially look like stupid leetcode, but the job really does benefit from that. A basic example: I ask you to model some toy problem as a state machine. Is that a stupid leetcode challenge? Maybe. But many if not most complex UI interactions really are state machines and if you’re the kind of person who intuitively thinks in state machines, you’re going to write more maintainable code. My personal blind spot is that thinking in graphs is difficult for me. I just fail to see ”Oh, this is a graph problem!”. A lot of times the code I write would be much easier to maintain and write had I realized I’m solving a graph problem. Better performance too. edit: if you mean the performance anxiety party, yes. Several research papers have shown that anxiety induced by the interview context impacts people’s performance.

by Swizec 5y ago

pthread_t 5y ago

> The “do smol thing together so we can talk about it” interview penalizes people with performance anxiety. Does this apply to the Leetcode style interviews?

Swizec 5y ago
If they’re any good. But really, it depends what people think of when they say “Leetcode style interview”. There’s a lot of coding interviews that superficially look like stupid leetcode, but the job really does benefit from that. A basic example: I ask you to model some toy problem as a state machine. Is that a stupid leetcode challenge? Maybe. But many if not most complex UI interactions really are state machines and if you’re the kind of person who intuitively thinks in state machines, you’re going to write more maintainable code. My personal blind spot is that thinking in graphs is difficult for me. I just fail to see ”Oh, this is a graph problem!”. A lot of times the code I write would be much easier to maintain and write had I realized I’m solving a graph problem. Better performance too. edit: if you mean the performance anxiety party, yes. Several research papers have shown that anxiety induced by the interview context impacts people’s performance.