People lie, people embellish.
If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
Otherwise there is no reason an interviewer can or should trust whatever story you tell of past successes.
If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
Otherwise there is no reason an interviewer can or should trust whatever story you tell of past successes.
It's been done, still doesn't get you a job.
So there is a conflicting case.
No company is going to be perfect at hiring just the same way as no person is going to perfectly crush every interview. But there is no world where having contributed quality code to an open source project will hurt your chances.
Instead it's usually "Huh, you seem like you just might not be a complete dullard. Would you mind proving it to us by taking this 3-hour HackerRank test? 'Coz we know you've got nothing but time. And you'll go through just about any number of hoops to get us to pay attention to you."
† Even the ones who ask for it.
†† Even when we patiently and politely point out the gaps and ambiguities, sometimes quite glaring, in their cute little "challenge" problems. Which, again, many to occur in at least around half of these exercises.
Would be interesting to see which companies actually look at your github profile like they claim they do.
It doesn't sound like you fully disagree, because writing OSS isn't that curated path, but sadly none of the devs I know who focus heavily on algorithmic whiteboard question performance look at open source projects. And they could justify this with the same one you give: people lie, people copy/paste code...
I've pushed my team quite a bit away from where they were when they hired me in terms of whiteboarding focus, and we're better able to hire senior candidates now than they were back then. The BS detection is a big part of this: ok, you were on a team that did [really cool sounding thing]. What part of it did you do? What specifically did you learn from it? Even in aggressively paced interviewer loops you probably have at least 45 minutes to get them to answer those questions, if they're ducking and dodging, or answer back with wrong information, or with stuff that makes it clear they used the wrong tool for the job and didn't know how to find the right one, then there you go.
It's easy to present code, but it's also easy to copy or memorize code. Some of the most impressive candidates I've seen are the ones where the "let me ask you this stuff about your past experience" discussion expands to fill the whole time slot and we never actually look at any code, because we're too busy talking about how you took a service from a single database to a multi-master geo-distributed easy-failover alerted and monitored system, or how your random side project to look for Hidden Markov Models in baseball player's batting results went (how'd you store the data? what libraries did you use? did you implement your own versions of algorithms? what made it hard to draw conclusions? etc).
Exactly this.
The memorable example for me was someone that worked on a military helicopter training simulator, and specifically, they worked on connecting the physical radios (used for internal communications between the crew) to the simulator. Sounds cool, involved network experience that was entirely applicable to what we were hiring for, and personally, I have a fascination with and have done a lot of interfacing of physical human-interface hardware to software.
However, the candidate was unable to explain details. What type of I/O hardware was used? Did you have to poll or did it push/stream changes? Did you run into anything weird with bad signals or missed state changes or restarts that posed a big challenge? No answers to this, because apparently they "just worked on the protocol".. but then couldn't remember anything about the details of the protocol (HTTP or something custom? Text-based or binary? TCP or UDP?). It was frustrating, because I remember otherwise liking this person.
They had similar responses for their most recent job (that they were at literally a few weeks prior).
I have a terrible memory, but even I can remember some of the biggest challenge highlights of my career. If I start talking about them, especially when asked probing questions, I will remember all the little details and could go on for hours.
I don't get it. Were they just coasting in the background, not really contributing anything meaningful, doing just enough to not be fired? Did the interview make them so anxious that they literally couldn't remember any details (it didn't seem that way)? Were they outright lying about what they did?
(S)he spends so much time playing translator that there's no time to sweat the details. That falls to the team.
Problem is, the skills you need to be a good interviewer don't necessarily overlap so well with the skill set of a good software engineer. It's much easier to get people to ask about what they know, irrespective of whether or not that will be an accurate indicator of technical skill.
If you're a Google or HFT firm working on massive scale or optimizing super low latency systems, sure it very well may be critical knowledge. If you're some random company with a CRUD app, this kind of hiring process isn't going to optimize for the most qualified candidates for the job.
Not good enough for me. My engineers need to be able to collaborate with customers, management, and each other. They need to come up with ideas and explain them, advocate for their ideas. They need to be able to think, code, and collaborate.
Writing code is the easiest part of software engineering. In the environment I work, our engineers can't sit in isolation and submit pull requests. So while open source contributions are nice, being able to interview successfully is still required.
The hardest project I've worked on so far was a CubeSat project where I had to collaborate with Electrical/Computer and Mechanical engineers with specialized knowledge (orbital mechanics, the design of the custom boards, etc.) to develop the software. I had to communicate why certain hardware elements are absolutely needed in their design, why certain elements of the Attitude Determination and Control System need to be optimized, and so on. As well as why we needed many of software engineerings best practices, which when you step back and look at them from the outside some do seem fairly odd.
But on the other hand, it is not always needed. Also, I'm confident I could prove my capability without a whiteboard because I could probably talk about the problems and collaboration to resolve them on that project for well over 30 minutes.
Except that its pretty easy to see if someone is telling the truth about their area of expertise with a few open ended questions.
I'm saying that you can't complain that an interview doesn't show you are good coder if there is no other way for somebody to look at a project you've done.
Saying you did X/Y/Z at your last company but can't share the code since it belongs to them isn't a valid excuse for why you have no code out in the world to show off.
Also, some people have enough flexibility to learn new languages, technologies, frameworks, and such within the context of their day jobs.
Can't exactly contribute to open source if my contract says my employer owns everything that I do, and even if you think that can get tossed out, you'd better have a good legal fund.