At CrowdRiff, one of our core values is building a culture of learning and mentorship. As a result, we tend to hire a lot of Junior Developers.
In fact, most of the developers we’ve hired would be considered by most places to be “junior”.
We’ve developed a partnership with HackerYou (a technical college/bootcamp close by) that has provided a great pipeline for Junior Developers. They’re driven, quick to learn, and are usually starting a second career, so they come from varied backgrounds.
Our interview process consists of two main steps:
First: A more typical style job interview with two members of the team, usually our CTO and our scrum master. We make sure that there’s gender diversity among the interviewers — it can help reveal some not-so-great personality traits.
Second: A 45–60 minute pair programming exercise with me. We’ve created a tiny little web app that searches Giphy, and we ask the candidate to enhance it in some way while they talk through their process.
Whether it’s adding a fullscreen modal, or a load more button, or the ability to favourite gifs — what they build isn’t as important as how they approach the problem.
So here’s the 4 things we look for: Core Skills, Problem solving, Learning, and Attitude.
1 | Core Skills
Do they have the foundational skills necessary to build websites and web apps?
We try not to base our decisions on fluency. After all, someone coming out of a bootcamp may have first touched JS 6 weeks ago. That’s okay.
.filter. Can they can look at something and have a general idea of what’s going on? And if some things are unclear, do they ask questions or play with the code to figure it out?
React is similar. Our whole codebase is built in it, and HackerYou (and almost every other bootcamp) teaches it, so we expect most candidates to have an understanding of it. When we’re testing on React, we’re looking for the basics: An understanding of state and props, how they work together, and an ability to look at a component and have a basic idea of how it functions.
If you’ve got a handle on the concepts in the quick start section of the React docs, that’s enough to build on.
For CSS, we look at what they’ve already built — both the code and the site itself. CSS is hard to fake, so we look for little visual hiccups, like some wonky padding, or an element that looks like it should be centered but isn’t.
We also look at the cleanliness of the code, and how it complies with best practices. Is it free of
!important tags (unless there’s a good reason)? Is the SCSS nested 8 deep? Maintainable, flexible code is important and if your CSS is clean, it’s a good sign.
In short, they can do what they say they can do.
2 | Problem Solving
Web development is problem solving.
Good junior developers aren’t afraid to break things, because that’s how you can fix things and learn. They know that console errors are not a dead end, but part of the solution.
When some candidates hit an error, they get paralyzed — scanning their code, wondering what went wrong. Others use that message to start finding out where the error is happening, and start throwing in
console.log to start figuring out what broke and how to fix it.
It doesn’t have to be a complete solo effort. They ask questions, but after trying to answer the question themselves.
3 | Learning
One of the biggest strengths of junior developers is a desire to learn.
These are folks that have probably quit their jobs to learn how to code. They want to learn new things.
We’re a relatively small dev team, so anyone coming in will learn how to work with GraphQL, React, Redux, and how to navigate our codebase. We give them time to learn it and provide mentorship, but as a small team, the quicker a new dev can pick up new skills, the better.
Evaluating this is tricky. Sometimes it’s just about whether they’ve used an unfamiliar technology or incorporated a specific plugin/package in a recent project. Sometimes, it comes up in the tech interview, when they see how the code is laid out, they’re processing things and taking it in — and learning from it.
Or, I will introduce some concepts like different ways to conditionally render JSX, or using
.map instead of a
.forEach, and see how well they absorb that.
4 | Attitude
This is the toughest one. It’s basically what many would call “culture fit”, which can be a useless buzzword if you don’t figure out what that actually means.
A lot of this ends up being a gut decision, which can get wildly subjective, so we try to bring it back to a few key values to keep us grounded — and focused on.
A good junior dev has confidence in their abilities, and that even with their base skills, have the ability to build awesome things. Even with that, things will break, but they’re okay with that. While they’re still learning, they can have opinions they can defend — and are encouraged to.
Even though they’re confident, they know they’re still growing as developers. While their code isn’t perfect, it’s getting better. Same with mine.
They’re not too precious about their code, and know it could be improved. Their opinions can be challenged, and it’s not personal. They can ask for help, and that’s okay. They also acknowledge when a project in their portfolio wasn’t just their doing, and they give credit to people they worked with.
They’re not an asshole. In the interview, they talk to everyone interviewing them. They’re going to be a good teammate because they can communicate well and with empathy, bringing up concerns and issues without making it personal. Oh yeah, and they’re not an asshole.
Junior devs are great!
We like hiring Junior devs because in the right environment, they can grow really strong, really fast.
If all this sounds like you, let us know. We’re usually hiring. Send an email to matt [@] crowdriff [.] com, and be sure to use the password “I made it to the end of the blog post, what more do you want from me”.
Originally published in Building CrowdRiff on Medium.