I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.
> Most people's public code is of roughly equal quality (eg 'not great').
I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
> Building a great team is about hiring great people more that just great developers.
I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank?
> It's hard to trust someone's public code.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world. I had already accepted a position to basically create a development department, and he wants me to write a sort algorithm? Once he described how it worked, I wrote it without much difficulty but that was a turn off and I got an offer that was permanent (as opposed to contract to perm for the offer I accepted), making more money, with a signing bonus.
It was such a turn off, I declined the offer for a chance to build a department that would not expose developers to this foolishness and thought that the interview process tells you a lot about the company.
A year later. I'm glad I made the choice I did.
On the other hand, I've done quite a few pair programming type of interviews where there was a skeleton of a program with a lot of failing unit tests you had to make pass. I enjoy those.
Is there a DoctorRank or SecurityGuardRank or WaiterRank?*
Doctors have to go to school 8+ years and do a 2-4 year residency before they can practice without supervision. Lawyers have to go to school 7 years and pass an exam. Software Engineers only have to watch a couple of YouTube videos and they can call themselves "programmers". Doctors can't say they are qualified because they have been doing brain surgery since 6th grade in their bedroom.
At this stage in my career when I still get this type of bullshit from someone I just find it ridiculous.
I'm just left thinking, "Did you read my cover letter? Where I told you how I worked on a 3 million CLOC air flight cockpit software that runs in actual planes; so if there are bugs real people would die? How about the part where I discussed being the software lead on financial derivatives trading software; where bugs could lead to millions or even billions of dollars be lost? Did you see that software library I maintain in my free time that has over 1 million installs? And you still aren't sure I'm qualified? Well no sense wasting any more of your time; I'm clearly not qualified then."
Ironically what I would consider the two best interviews of my career went like this respectively.
1) I was called in for a technical interview. The VP of the IT department sat down with me and asked me to tell him about my work experience. I gave him an overview and then he started delving in deeper and deeper on the subjects that I said I had experience in to see what my level of knowledge was. This went on for about 1 1/2 hours at which point he stopped me and said, "Ok, how much money do you need?" I gave him a number to which he replied, "We could do that. Hold on a minute." The VP then went and brought in his top developer (turns out he's also the hiring director) and then we basically repeated the whole thing, but dove into even more technical details. That lasted somewhere between 2 and 3 hours. At the end of it this he says, "I can have an offer letter ready for you tomorrow. When can you start."
2) Preface - I was referred by someone already working with this company.
I get a phone call from the company CEO (small start-up). He asks me a few questions about my background, some soft skill type of questions, nothing real technical. After 20 or 30 minutes of conversation that is basically just a "can we get along with each other" check the CEO says, "Ok, I'll need you to do a technical interview with our team lead." A couple days later I get a call from the team lead.
The conversation goes basically like this.
Him, "Ok, so here's the deal. Steve says your really fucking smart and Steve is really fucking smart so it's probably true. Elijah (CEO) thinks we need to do technical interviews, but really they're all just bullshit anyway. If it turns out you can't do the job we'll fire you in less than three months; if you actually know what you're doing we won't. So do you want the job or not?"
Me, "Yeah"
It was a contract to perm position. I asked my now manager, why was this a contract to perm position? Was it because they wanted to see if the person was a good fit or were they under a budget constraint that might stop me from coming on permanently? He said the former.
I had to create the department from scratch with basically nothing but "database developers" who were just learning C# and no infrastructure. I laid out a 6 month plan. Six months in, i was able to negotiate a higher pay than I could have originally since it was my first official lead role and make extra money by being able to bill hourly. It was a major win.
When I was single without the skill set, network, or health benefits from my spouse, I would have never left a full time position for a contract to perm.
Even if there was, no one would trust it. Case in point: ABET will accredit CS programs like they do other engineering programs; not many schools bother because companies don't give a shit about it.
> You can have a CS degree without really being much of a programmer.
You can get a BSEE without being much of an engineer, too. BSEE new grads definitely get tested by hiring companies to make sure they know their shit, but it is nothing like what this industry does.
Last one I had was to implement QuickSort. Had a -huge- argument with the interviewer who insisted there was an off-by-one error and it would never work. Needless to say, he was thoroughly wrong once it was coded up and I didn't get the job. :)
> It was such a turn off
It's pretty much an automatic "no" for me now too.
After the contract was over, I was able to negotiate a higher pay to convert to perm than the job I declined offered even with the signing bonus.
In my experience, the best type of coding tests are based on creating a skeleton program with failing unit tests already written and pair program with the candidate and see how they code and make the unit tests pass.
Currently I have two phases in my unit test based interview.
Phase 1: simpler tests and requirements that they have to make pass.
Phase 2: more complicated requirements and a second set of unit tests they have to make pass without breaking the first set.
To me, that mirrors how we actually work - get an MVP out the door relatively fast and add features later on ensuring you don't get regressions.
I've (thankfully), never had to whiteboard. Think it's a US/SF thing.
That these interview techniques are determined so much by culture, fashion, and following what the successful companies do (I.e. Google), in itself shows how useless they are.
That said, I acknowledge I can't think of a perfect way to assess software engineers. We have a take home exercise, but ultimately gut feel drives the decision.
And that has spread all over the world now, because a lot of companies outside of SV, tend to view these BigWebCo's as something to emulate and imitate from, and are doing these whiteboard interview all the time.
In fact the whole point of these Hacker rank kind of sites is to basically provide the web equivalent of a white board. You are asked to submit code(Typically some question based on a exaggerated edge case of some algorithm) and see if it passes all test cases. You are in if it does, out otherwise.
The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help.
Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
Maybe Google is different but I usually need to do computer cine type stuff about one a year.I have used recursion on maybe 4 different occasions in my carreer, but that's the sort of thing that comes up regularly in coding tests. Why not test for things that are actually being used on the job?
A public code repo is more than just code.
* It's documentation
Is there a decent README or other background info on how to get setup? Sample data? Tests?
* It's activity
Was this a fork with one patch and nothing since then? Or is it a long-term project with regular/periodic activity?
* It's community
Is this project getting bug reports, feature requests? How is the owner dealing with them? Ignoring them? Being rude? Actively engaging? Delegating? Honestly admitting they don't have the time and asking for help?
There's a whole mess you can judge about someone that goes beyond "code" when looking at a repo. I know someone who was hired at a company a couple years back who was brought in because of a friendship but the "github" profile was referenced as justification. "This person has a lot of projects and stars - they're definitely active!". The person had starred other projects, and had cloned about 40 repos, and made (trivial) changes in about 5 of them. They had no original code. The person had been brought in to lead a team of about 6 developers, and left within 2 months because they had no experience working with actual production code or working with people on a team. That was quite apparent from their github profile.
1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant.
2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking.
Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers.
3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere.
Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really.
I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.