4 ms·
I'd say "work they've done for previous employers" is something that nearly every candidate with industry experience has. The problem is that when I ask about i
by lhorie 6y ago
I'd say "work they've done for previous employers" is something that nearly every candidate with industry experience has. The problem is that when I ask about it, candidates often are terrible at communicating what the work consisted of: often they focus on microscopic minutiae that appears disconnected from the big picture (e.g. gloating about gluing some trivial library as if that's a big accomplishment, when the position is for a senior engineer) or they demonstrate apathy/lack of proactiveness (e.g. some variation of "I just did what I was told") or they ramble incoherently, etc.
And this is supposed to be one of those bog-standard question that interviewees are always told by job interview guides to be prepared for!
I agree that people that have OSS work to show are much rarer to come by, and FWIW, they tend to do better in interviews IME. My theory is that it's not that the OSS resume bullet point itself sets them apart, but rather that they polished their skills more through the hard work they put into their OSS projects.
- autarch 6y agoJust to clarify, I thought the author of the linked piece was suggesting that people could share actual code from previous employers somehow. Of course it's reasonable to ask people about their past work in an interview and to expect them to speak about it coherently.
- lhorie 6y agoI think OP did suggest sharing actual work, which would make sense if said work consists of e.g. semantic html that can be looked at in a publicly accessible site. Obviously sharing backend trade secrets would be a big no-no. I've had people say they can't talk about their work due to NDAs, and that's completely fine in my books. We just move on to another topic. FWIW, even when a candidate mentions having an OSS project, I refrain from looking at the actual code, and especially doing code review. I don't consider an interview setting the appropriate place to be grilling people on why they used a while loop instead of a for loop or whatever, since a) nearly everyone writes "bad" code occasionally and b) often things are done in certain ways for some good reason that isn't really relevant to my goal of evaluating the candidate. At the end of the day, the interviewer's goal IMHO should be to get as many signals they can from the conversation and make a determination about whether the candidate meets/exceeds a minimum threshold of competence
- juped 6y agoInterviewers react badly if you try to describe the high-level thought processes you go through, because that's not "technical" or "coding". So you end up reaching for dumb bullshit like gluing some library or whatever the fuck, because coding is actually boring grind work that you want to do as little of as possible, as stupidly as possible, and there actually isn't anything interesting to say to these people if you did the engineering right. If that's not you, then you need to be painfully, painfully explicit about it, and some people still won't believe you because interviewers just lie all the time.