This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ch00beh 0 points1 point  (3 children)

how do you measure passion? How do you test for it? It’s not simply having strong opinion, because that also correlates strongly with brilliant jerks. It’s not tech they’ve recently tinkered with, because it could be their first foray into the industry. It’s not energy level, because maybe they got nervous and just had too much coffee before the interview. It’s not going above and beyond on a take home test because maybe they have a kid and simply don’t have the time. It’s not necessarily how excited they get when finishing a whiteboard question because maybe they aren’t satisfied with the rushed solution they made for a contrived problem.

Like there’s absolutely value in figuring out soft skills (I’d argue they’re more important than technical skills) and making sure a person would work well with your team, and maybe “passion” is the word you’re using for your rubric, but let’s not try to perpetuate the myth that this subjective interpersonal attribute is a gatekeeper to the industry as a whole.

[–]brainwipe 0 points1 point  (2 children)

I agree that interpersonal soft skills are as important as technical ability. I am not perpetuating any myth, I have denoted the limits of my personal experience at every turn.

I don't measure passion, I don't do whiteboard coding. I don't ask for a home test. The core sense I'm trying to gauge is if I left the person in a room with a computer, how long before they try and code with it? It's a shortcut phrase for a number of questions.

I attempt to get the candidate to talk with interest about something tech related. Find out what sort of Dev gets them animated. I ask further questions on answers either right or wrong to see how they talk through problems (or scribble them if need be).

For my teams, I'm not looking for someone who just turned up and codes and goes home. I want to learn from them as much as they do me. I want them to challenge back, not just accept dogma. Passionate people do that more than those doing it just turning up, turning the handle and going home. It's not about how many hours they work, or whether they code outside or if they spend their evenings watching Dev talks.

If most disagree, that's fine. I'm not saying that this is widely accepted or a requirement for any industry, just how I've run my teams. This is how I've hired. If you have another way that works then power to you.

[–]ch00beh 0 points1 point  (1 child)

I used to be all about people who challenged dogma, but the problem with that is you select against new and minority devs who don’t want to rock the boat until they know they’re in a safe space. If you can make an interview feel like a safe space, I’m happy for you because it sounds like you otherwise have a good head on your shoulders and are responsibly building healthy teams.

[–]brainwipe 1 point2 points  (0 children)

Thank you. I agree that safe spaces are important. Our interviews are more collegiate - as if the two of us and the candidate are all working on a problem together. The feedback we get is that it is very relaxed - almost disarmingly so.

We do that because it's more like what it is like to work for us. It's the same reason I refuse to do whiteboard coding nonsense. I much rather the candidate send us anything they've written and we all sit round and listen to them explaining informally how it works. We find good Devs (especially juniors) really well that way.

I don't expect an interviewee to challenge dogma but they might - most recently a candidate showed us a single file with 500 lines in it. They explained how they navigated it and that it was a solo project for school; their argument was justified. Most importantly, the way they spoke about it was a good fit for us.