| > As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield), the interviewer has to be a mental Hulk to proceed without bias. Goodbye diversity. I think this is unavoidable. Teams have cultures (I don't mean ethnicities, though of course there is some overlap), and ill-fitting candidates will struggle even if they are hired. Or they'll change the team and stress someone else out. As un-PC as it sounds, probably small, values-aligned teams are the easiest/most comfortable to work in, even if that means individuals aren't exposed to more diversity. > the signals I'm looking for: (1) can the candidate code fluently, (2) do they approach the problem in a systematic way, (3) can I communicate with them without friction. Isn't this a sort of cultural preference on its own? You're looking for (and prioritizing) people who can code a certain way and communicate with you a certain way. A brilliant programmer from a different code style background, who's maybe an introverted poor communicator (or just have a different communication style) and codes in nonstandard (to you) way might not pass such an interview. That's fine... they probably wouldn't work well with your team anyway. But IMO that's the point of cultural fit interviews, to respect both your team and the candidate's time upfront by evaluating not just their technical ability but how well they'll fit into your team. The "signals" you're using are just a masked variant of that. Maybe (as an example, just an extrapolation) you prefer async communications with clear, simple assignments -- like self-contained Jira tickets -- rather than group architecting, pair programming, or whatever. But those are cultural values. If you ignore all those signs and forcibly include someone, sure, you might increase diversity on your team... and stress for everyone, including the new hire who finds themselves alienated from the rest. |
> Isn't this a sort of cultural preference on its own? You're looking for (and prioritizing) people who can code a certain way and communicate with you a certain way.
Fluent coding doesn't imply style or something non-measurable. You can say if someone is fluent or not even if they are using a programming language that you don't know. I interpret it as: do they struggle while converting their idea to code, or not. Not how they structure the code, etc.
Same for the systematic approach to the problem. If their explanation is all over the place, or failing to uncover the important bits of the problem[1], bias doesn't kick in here. We can argue about the appropriate layering of the solution (the level of detail). That's where different people are different. But you can see if their strategy works or not once they put it in code (i.e. maybe they should have put more structure in their approach).
[1] (I: "Code me a string invertor". C: "Yes Sir! Here you are." I: "That's not what I had in mind.").
> A brilliant programmer from a different code style background, who's maybe an introverted poor communicator (or just have a different communication style)
Well, if I can't communicate with them (there's high friction), I shouldn't work with them. This is a bad fit by definition. They might find a better fit at another company.