Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover someone's day-to-day personality when their guard is up.
With that said, my interview process basically is:
* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further
* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along
That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.
> * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great.
That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
Algorithm questions may be more “general” than doing something like the actual work being performed, but frankly most programmers aren’t writing optimized low level algorithms on a day to day basis. All you get is people who’ve memorized the algorithm tricks.
It's not as simple as just memorizing "algorithm tricks". There are too many possible questions to just memorize all the answers, you need reasonably strong CS fundamentals, and also to be fairly smart. I think that's part of why they're used: actual IQ tests are legally fraught, but giving someone what amounts to a programming IQ test is not.
It's certainly true that studying these kinds of questions helps, but if you're not too bright, I don't think that would take you very far.
Strong CS fundamentals is understanding all the various patterns and tricks in algorithms and data structures, and how they could be applied to problems outside of where you originally learned them. That is it, outside of actual CS research work, when applied to an actual software job. Ask any self taught person how much they need “CS fundamentals” to blow the pants of any business need for an app and they’ll tell you probably very little.
When you’re doing tools for programmers, it gets a lot more complicated. That is not most jobs.
My process is pretty much same as above, with the difference that I let them choose whatever framework/language they feel most comfortable with (with obvious caveat that I might not be able to help them if they get stuck).
If you are good dev, you will pick up any language/frameworks quite quickly if you want to (there are exceptions, like switching to completly different paradigm e.g. from JS to Haskell, but that is not our case).
Generally-speaking if we're hiring someone to work in React or, say, Kotlin for Android, they need to know at least a bit about the framework they're working with. The process would be different for co-op positions/new hires directly out of school, and obviously we'd tweak it for a clearly awesome developer who is in the process of retooling.
Is that really true? Learning a framework or language isn't especially arduous. My team works in C++. I have zero C++ requirement for hiring on my team because in my experience every good hire can pick it up very fast. If I restricted myself to people who can sit down and run with C++ then I'm winnowing my pool of candidates.
This seems like a reasonable process. However, for me personally, I have a big portfolio of side projects with open-source code. And it irks me if a company asks me to prove my programming skills by wasting my time doing some silly tests, where if they just read my code we would be able to skip it. From all the places I've worked, the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test.
I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.
One problem I have with this is that tons of people like to push the "GitHub is my resume" thing, but 75% of the time they have 25+ "forked" copies of major open source projects with maybe one or two extra commits on top.
It can be a real drag to try and suss out who actually has real contributions or real original work on their GitHub. Our approach for hiring is to actually have people cherry pick out one or two items they're really proud of and have them send a brief overview / sample.
That approach is also nice, because it gives you a great interview starting point to dig into a technical item that they (should be) comfortable with and passionate about.
Your cherry picking idea is fine, but your reasoning for it is bs. If someone wrote the code (or read it enough to grok it), asking them some questions on the internals will sift out who just copied some free repos.
I think that's reasonable too. I wasn't try to say "github is my resume" because in my site I point out specifically projects that I made, and link them to the repo.
Making the person pick out projects they are proud of is a great idea.
A great portfolio is a huge plus (and I've hired people purely based on their open source contributions, usually remote), but as mentioned elsewhere your previous code tells me very little about what you're like to work with day-to-day. We usually do something like "here's our mobile app, let's start the process of building it in React - walk me through the process as you go".
We all know devs who write beautiful code but are impossible to work with ;-)
the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test.
I don't do side projects. I work 40+ hours a week on a computer, when I get home, I'm spending time exercising, with family and friends are just doing nothing.
If a company doesn't think I'm "passionate" because I don't have a Github account so be it.
Also, I'm not going to do a dog and pony algorithm white board coding test. I'll draw out architecture on a white board but if you want me to code, sit me behind a computer and test whether I can solve a real world business problem.
I'm most likely being interviewed to either write/architect a bespoke internal app or yet another software as a service CRUD app. I'm not being interviewed to create software to put a man on the moon.
Sorry for the misunderstanding. I didn't mean that everyone should have side projects. But if you do, why not judge some of it based on that? And if you don't have open-source code to show, then some kind of test seems appropriate.
That code may be the result of months of polishing and cooperation.
An hour of pair programming lets you know what it's like to work with someone. Are they reasonable to discuss things with, etc. On top of learning about their programming and problem solving skills.
It's also a result of me calmly working instead of nervously taken part of an interview. The one thing that I've noticed is that it's very hard to judge someone's personality in these kinds of situations.
Yeah, that's a fair point. Interviews are a little insane however you do them, and still you need to figure out some way to hire people.
I do like this "homework" interview variation: You get to work on a task at home before the interview at your own pace for a few days. Then you come in and talk about your design choices, and are asked to add a feature or two to your code.
> the companies with the better programmers were the ones where they actually looked at your past code
How common is it to actually be able to do this? I've worked at Google and Amazon and Goldman Sachs; I can't show any of that code. I've occasionally dabbled in coding little scripts or projects at home, but nothing terribly challenging or complicated.
I'm not sure how common it is. But if someone does have open-source code that you can review and they'd like to showcase, why not do that? I guess that's all I was trying to imply.
Usually my suspicion is that the code is just a cloned repo or similar.
I have however dug into github code that seemed legit, with the candidate claiming to be one of the primary developers of a popular Xbox360 emulator. I surprised him by quickly finding obscure bugs, including a couple buffer overflows and a way to cause a math exception in the host process.
It does feel kind of unfair to those whose code is locked away under NDA.
A pairing exercise isn’t only testing your programming skills, it also tests your ability to work with other people and get on with them, which is not only important but much harder to train than the technical side of things.
Which I understand, but I also see this as flawed since the person being interviewed will have their guard up and be nervous. This will skew what their personality is really like.
If interviewer has any clue, then they will know that and will account for that in their judgment. Almost everyone is nervous and will not perform at their best.
With that said, my interview process basically is:
* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further
* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along
That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.