For getting a job at Google/Facebook/Amazon/X cool startup, it's a lot more important to do some narrow-minded rote-memorization of algorithms and data structures and hone the skills talked about in a small set of books like Cracking the Coding Interview than to learn something really interesting, or become good at a certain thing, or build some cool shit.
Most interviewers aren't really interested in figuring out "is it worthwhile that you built this thing / did you do it right / why do you think this was something worth learning?" when it's so much easier to evaluate your whiteboard code on a narrow problem against some ideal standard solution.
You can tell them about how you were able to learn enough about a particular database in a couple weeks to be able to cut 90% of the runtime out of a hot query in your first few months at a job, since that was an area that wasn't scaling well and it was something your boss asked if you could take a look at, and they'll be like "ok that's nice, now implement a trie." What's the point of even having experience building and running real systems if that's the process?
If you'd rather be building than practicing whiteboard questions, your best path to success is probably going to be a less predictable one where you need to come across one of the right companies willing to work harder at interviewing because they have to find the best candidates who fall through the cracks at the places with the name recognition.
That is one case. I've specifically hired somebody before who was so/so in the interviews but was the main contributor to a wonderfully written open source project. And was and is a great developer and great hire.
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.
There isn't data available on the general case, of course. But data from personal experience indicates: (1) many companies -- I'd say at least half of 'em-- still never look at portfolio code† (which -- even it's just a small personal project or two -- should provide plenty of conversational material for a perfectly decent and rigorous phone screen), or (2) if they do give you a take-home, they never attempt to use that as discussion fodder, either.††
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.
Are you still hiring by any chance? I am looking for a new gig and I have bunch of open source work but no one is actually looking at it all, one interviewer even admitted 'oh we don't look at that much, maybe towards the end'. Even though they asked for it in their hiring page.
You are definitely an exception.
Would be interesting to see which companies actually look at your github profile like they claim they do.
I'm not involved in any package manager development, but this strikes me as extremely arrogant. Successful package managers are most definitely not a dime a dozen, and the skills required to make one and maintain it over years are something which the majority of engineers at Google (or anywhere) do not possess. There's a lot more to software engineering than working on the hardest of the hard tech problems, and being very successful on the social side is a huge asset that no company should discount based on the theoretical difficulty of the problem being solved.
Yeah right. Most developers wouldn't be able to even start writing a package manager, let alone maintain it for years as it becomes the most used one for a particular platform.
While that was true 10 years ago; I don't think it still holds. Google is more big generic enterprise now with all trouble innovating that comes with that. Hence, why they must buy to be able to push innovation forward. This is just part of the natural life cycle of a company as it gets big and successful.
That's why the interviewer needs to be competent enough to be able to sniff out BS. Falling back on algorithm questions instead is a form of laziness. That's what the "curated golden path" comment is all about - there's a known standard way to get a job at one of these companies, and following it is not a very intellectually interesting exercise.
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).
> 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?
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?
There's a trap that some small subset of seniors fall into where there's a lot of projects going on and their role becomes to play architect, provided minimal directions and manage expectations. Nobody tells them they're a manager and everyone thinks they're responsible for the development work that gets completed. Nobody else wants to manage the developers (the good ones ask tough questions about spec. they're "hard to manage"), but nobody respects this guy enough to treat him like a real manager.
(S)he spends so much time playing translator that there's no time to sweat the details. That falls to the team.
Exactly. Making a good hire is a management skill. Is it acceptable for managers to measure the productivity of their team by counting the # of line of code the team produce? or # of bugs the team fix? If not, why is whiteboarding with algorithm questions acceptable?
Eh, I disagree. A good interviewer can dig into past experiences and pretty quickly get a sense of a candidate. Interviewing is a skill that can be acquired and developed.
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.
For most software engineering jobs, the implementation of tries and whatnot is completely divorced from the actual day-to-day work, work that's generally on a much higher level of abstraction to the interview questions. It's the equivalent of interviewing a chemist based on his knowledge of physics.
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.
> If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
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.
I completely agree that this is sometimes the case.
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.
Have you tried it? You might be surprised at how easy to tell when someone is lying, once you learn to ask the right follow-up questions. It's difficult to fabricate experience for an entire 8 hour interview loop.
Err.. I'm not a prolific developer or something, but most of my interviewers refuse/don't look at the github profile links I put in my resume. Instead they want me to spend time on whatever custom problem they've pre-decided and solve it (and worse not put it public..duh..)
I'm not saying you have to write open source code on your own time.
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.
Maybe in California, where contract terms around owning your products outside work aren't honored, but in most of the rest of the US and the world, this is still a valid excuse.
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.
Yeah, you do. You can't rely on your employer to continuously retrain you through your whole career. Show me an engineer with 10+ years of experience who refuses to ever learn anything away from work, and I'll show you somebody working on old tech.
"Can't be standardized" is something of a red-herring, as I've encountered a huge variety in how even algorithmic questions are presented and judged.
[More] prone to biases and opinions? Let's assume this is true (I'm not convinced that it's such a slam dunk - someone who wants to say no to a candidate can find a way, especially if they aren't being shadowed or recorded (which would feel pretty draconian for the interviewee too)). Isn't it still just a way of making a lazy complaint, "but that's harder!" You as hiring manager are responsible for knowing yourself, knowing your interviewers, knowing their strengths and weaknesses, and knowing your own.
That makes it hard to assembly-line interview fresh graduates, but maybe you should have a separate process there anyway because they won't have much in the way of useful experience yet anyway.
Most interviewers aren't really interested in figuring out "is it worthwhile that you built this thing / did you do it right / why do you think this was something worth learning?" when it's so much easier to evaluate your whiteboard code on a narrow problem against some ideal standard solution.
You can tell them about how you were able to learn enough about a particular database in a couple weeks to be able to cut 90% of the runtime out of a hot query in your first few months at a job, since that was an area that wasn't scaling well and it was something your boss asked if you could take a look at, and they'll be like "ok that's nice, now implement a trie." What's the point of even having experience building and running real systems if that's the process?
If you'd rather be building than practicing whiteboard questions, your best path to success is probably going to be a less predictable one where you need to come across one of the right companies willing to work harder at interviewing because they have to find the best candidates who fall through the cracks at the places with the name recognition.