Interviewing is broken. Nagging the current interviewing standards has been a hot topic over the years. Ok, everyone’s expressing their discontent, but where’s the ultimate alternative solution? Well, It’s not exactly easy to fix, because interviewing apart from being broken is also… very hard 😐
Why Is Interviewing Hard?
The answer to that is pretty easy for a change: Software Developers life consists of many different responsibilities. The easiest skills to test are:
- Computer Science — A great developer should be able to solve algorithmic challenges in a reasonable time performance. Should know the difference between deep copy and shallow copy. Know how to manage the computer’s resources optimally. Nothing that can’t be tested with a good set of technical questions, algorithmic challenges.
- Domain Knowledge — Language knowledge, runtime knowledge, memory management, frameworks, best practices, design patterns, tools, IDE, testing. Again, simply solved by asking the candidate some technical questions.
Ok, we’ve asked all the questions. Now what? If they weren’t very good, should we fail them? Definitely no. If they were good, should we hire them? How do we know how do they perform at their day to day tasks?
- Soft Skills — How does the candidate approach solving a problem? Does the candidate understand the problem? Does the candidate give up too quickly? Are they good at communicating, asking questions? Do they focus on the problem, instead of lashing out on people? Are they a good mentor? Are they humble?
- Picking The Right Tool For The Job — A good developer knows the line between bad code and overengineering. Knows how to pick the right algorithm, the right design, the right tool. This is very, very important.
- Work Process/Hygiene — Does the candidate know how to create readable pull requests? Does the candidate QA their work to ensure that it’s of highest quality? Does the candidate strictly adhere to requirements and designs or is sloppy?
- Working with the codebase — Does the candidate know how to read the code, documentation? Does the candidate refactor things he/she doesn’t like? Does the candidate follow the already set standards in the project?
There’s probably much more, but you get the picture. These skills describe the way of a feature/problem from the technical outline and design phase to the end user. So basically it describes the main responsibility of a software developer. How do we test that 🤔 ?
Open-Source-Driven Interviews
The idea behind Open-Source-Driven Interviews is pretty simple. Your company maintains an open source project. It can be a fresh project, or a fork of some other project — Hey! It’s open source, you can do whatever you want 😀 Most ideally, the project would mirror all the guidelines, standards, approaches from your production code. That project is the playground that your candidates are going to play with. Remember to keep it tidy, documented, modular and easy to read — just like a real, serious project.
So, you want to test a candidate. What do you do? It’s a playground! The number of possibilities is infinite. You can give them a new feature to create in the project, a problem to fix, a module to refactor, a pull request to review. Does that remind you of something? Yeah, it’s those things that every developer does on day to day basis. Or was it reversing binary trees ? I don’t remember 😅
The project is a technological mirror of your real production code. It’s a serious project not some half-baked in-the-void “demo-app”- like in most take-home assignments. It’s a living, breathing codebase that needs to be refactored, tested, maintained, discussed. It’s as close to simulating a real task in your company environment as it can get. It tests everything you need in a software developer and it does so in a community-friendly way! Who doesn’t love open source? 😍
After the candidate is finished with the task, you can get to know them even better with discussing their solution. Remember, do not expect the candidate to solve the problem in one specific way! Interviewing should be about getting as much of interesting knowledge from the candidate as you can, not forcing them to solve problems in a specific way.
What if the project feels too big, or finished? You just start another! It shouldn’t happen very often though. Remember, the task shouldn’t take the candidates longer than 2–4 hours — It’s their free time after all.
What if the candidates want to remain anonymous? They can create an anonymous account or just send you a zip file with the changes. A small inconvenience but definitely not a big problem.
Isn’t it unfair that all candidates will be given different tasks? On the contrary: you can custom-tailor the task to the candidate’s experience so he has a chance to show off. Besides, this is not a “who’ll find a better solution” contest. It’s a test that should supplement your assessment of the candidate.
The project should be as close as possible technologically, but thematically it should something completely different— you don’t want to be accused of getting free labor. Preferably it should be something useful for the community. It doesn’t even have to be your project, it can be any arbitrary OSS out there. It’s open source — it’s all about having fun!
What are the other advantages of Open-Source-Driven Interviews?
- Free Marketing — Just imagine how much developers are going to love you for such an amazing, useful and open way of interviewing. Finally, they can prepare for an interview. They know what to expect. Even if you don’t hire a candidate, they end up with +1 contribution in open source!
- Applying through Pull Requests — CVs are boring**.** Let the candidates apply to your company through pull requests!
- Doing something useful — You’re maintaining an open-source project! Just imagine if it was something useful like a charity app for dog shelters around the world.
That wraps it up. I didn’t have a chance to test that approach yet, but I definitely will! Let me know if you have any ideas, comments or concerns! 🤘
Edit:
Redditor burntsushi pointed that I missed to mention the possible disadvantages of this approach. Here are some potential problems that I can see:
- It’s still a “take-home” assignment, so people with more free time theoretically have a bigger advantage.
- It takes a lot of effort to maintain such a project, but what sort of interviewing doesn’t?
I would definitely say that advantages weigh over the small disadvantages. Let me know in the comments below if you see any more problems that we can discuss.