Hacker News new | ask | show | jobs
by mrazomor 904 days ago
I'd probably fail the author's interview. 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've also done 100s of interviews (small and large companies). What I learnt:

- CVs are useless except for leveling the candidate (which is done for me),

- CVs are dangerous because they create a bias ("looks like an amazing candidate!" -- an then you get someone who is good, but not amazing as you expected and then you rate them lower than you should -- I intentionally skip the CVs as much as possible),

- majority of the people will solve a simple problem at the algorithmic level, and then fail to code it up,

- the best value is to give the candidate a SIMPLE coding question which produces a decent amount of code (25-50 lines), and observe them while solving it (their approach, bugs, etc.),

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

2 comments

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

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

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.

> As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield)

I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate?

> I intentionally skip the CVs as much as possible),

That seems very odd. How do you comb through and make an initial choice of who to interview then? Also, seems unfair to not look at the work they’ve done over all the years.

Personally, I’m a GitHub person. Show me what you’ve written and how active you are.

>> As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield)

> I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate?

Easy :). Take me: I hate Go and think Java is the best programming language there is. (My daily drivers today are C++ and Python.) NodeJs should've never been invented. I'm pretty opinionated when it comes to this. I'd still accept the position where I have to code in Go (been there and it was OK for both sides), but I wouldn't keep my mouth shut during the interview -- I wonder how that would go with 80% interviewers.

> How do you comb through and make an initial choice of who to interview then?

Sorry, I didn't put it explicit enough. I don't do the initial selection or leveling. This is done for me. The CVs are useful for this. But if you can avoid reading the CV (e.g. assessing only the raw skills), then you should.

What do you do when you run into someone without a GitHub profile? Most of my work is either proprietary or in my private but bucket.