Sandglaz Blog

How to interview and hire junior developers

Agile Development Collaboration & Team Management

Today we are kicking off our hiring series! Stay tuned every Wednesday for more hiring tips for startups.

Hiring junior developers is becoming an increasingly attractive option as the technical talent drought continues. Actually, it’s a really good option, but only if you know how to hire the right junior developer.
Before I go into the how, let’s start with the when.

When should you hire a junior developer?

First off, you already have one or more senior technical people on your team. You also have the patience, willingness and time to train and mentor. I’ve met numerous business founders who hired recent graduates to build out their ideas, because they thought it was cheaper. Alas, it’s not. Junior developers need guidance, otherwise you’ll simply burn your money. If that’s you, you can stop reading this post now, and google how to hire senior talent.

Assuming you’re ready, your goal is to find a junior developer who will grow in the position and become an intermediate in no time. In addition to picking the right person, it’s your responsibility to offer them the right environment to grow.

Finding potential

What makes hiring a good junior developer much harder than hiring a good senior developer, is that they have no past to look at. Young talent is unproven. You need to be really good at (or get really good at) reading potential. You are looking for two main things.

  1. A problem-solving mind set, coupled with a strong foundation. Drill into how they think. What are their analytical and logical thinking skills like? How well do they understand the basics of computer science?
  2. Strong communication skills. You are going to need to communicate with them to mentor them. Do they understand what you say? If they have questions, do they know how to ask it? Do you understand their questions?

This is in addition to the soft skills you want in all your employees, like the right attitude, leadership potential…etc.

Now that I have done many interviews, I noticed a pattern between strong foundation and the kind of education the candidate went through. With the hiring crunch, coding bootcamps are springing up everywhere, but I personally don’t believe they’re a good alternatives to universities.

Junior developers ready to be hired

Don’t get me wrong, I do believe the university education system is far from perfect, and I look forward to that market being disrupted, but I haven’t seen a good alternative yet. It simply seems that those who haven’t gone through formal education tend to short-cut the basics. I’ve met with candidates who have developed nice web apps, but don’t know what a class or an object is. These people will be hard to mentor.

The Technical Interview

Here are the different types of questions you need to cover in your interview. Each of them tests a different set of skills, so be sure to include questions for all types. Prepare the questions before the interview. And before the interview, make sure to test the questions on people who are familiar with the knowledge level of your candidates. This is very important in order to gauge how hard or easy your questions are.

Architecture

A junior developer should be able to architect new small features for your product, and be able to understand the reasoning behind the architecture in place.

Devise a basic problem and build more on top of it. For example, you can start with something like “Imagine an app where users can follow/unfollow other users. Explain the relationship model that you would implement to support this.” Then you can add “Imagine you can sort your followers. How would you implement that?” And so on… The best place to create questions like this is from your own code base. It will be original and real.

The interviewee might not be able to come up with the most elegant solutions, or the most scalable ones. In most cases, they won’t realize the drawbacks of their own solutions. That’s okay. But they should be able to come up with something that does work (as in: no glaring problems with it).

When you point out ways to improve their solution, they should be able to understand you, and ask relevant questions. For example, if you explain how something is too coupled, or why it’s not scalable, you should feel like your interviewee is taking this in and communicating back with ease.

Algorithms

Algorithm questions can be very insightful. They test both their problem solving skills and how strong of a foundation they have. While the architecture question tests high-level thought process, the algorithm question tests step by step low-level analytical skills.

Again, you should ask the question and if they get it right, make it harder. If they don’t have an answer, give them a hint. The point here is to get a good idea of how they think, not to get a perfect answer on everything you ask.

An example of this would be asking:“Write an algorithm that divides one number by another, without using the division operator.”Once they give you an answer, ask them to make it better than O(n). If they don’t have an answer, hint “try a recursive function”.

Puzzles

While algorithms test the combination of analytical skills and computer science background, puzzles isolate the analytical skills. Choose puzzles that have a correct solution. You will not get a lot of insight about your candidate from asking ‘How many ping balls can you fit in a room?’. You can find some good examples here, although you might want to find less common questions.

UX/Product

You’re not looking for a UX expert, but you are expecting enough common sense to not build horrible solutions when they are not given an explicit design. You definitely need someone you can talk to about UX and reason with.

Pick a UX weakness in your product and discuss with them what you can do about it. This way you can also get a sense of your candidate’s knowledge of your product and the culture fit.

Fast Tech Questions

Discuss what is good and bad about the different programming languages they’re familiar with. Discuss the libraries they’ve used. What are the things they consider before choosing a library? You can ask questions on OOL, inheritance, duck typing, design patterns, etc.

This is where you get a general sense of their level of experience and the knowledge they acquired through school or side projects.

The Programming Test

Give them a small assignment they can do in a few hours, and have them do it in your offices. Simulate the real thing. You should allow them to use Google, because in the real world they can. Ask them to develop it the way they would if it is going to be deployed tomorrow, not as a throw-away prototype. They should TDD and all.

Do not ask the FizzBuzz question. It is stupid simple, and simply not a good filter.

I like to choose a language or framework they are not familiar with, because in the real world you get to use new frameworks all the time. E.g. If they are familiar with javascript, ask them to write it in coffeescript and TDD in jasmine.

This covers the technical part of the interview, including the necessary communication skills to be able to mentor the new hire. For the non-technical part, stay tuned for tips on hiring the right people for your startup or small business in our hiring series.

Are you currently hiring a junior developer? What kind of experience/skills are you looking for and how are you testing for those skills? Let us know in the comments below!

Sandglaz is the easiest way to collaborate with your team. Learn More


  • Pingback: A guide to hiring the right people for your startup or small business Sandglaz blog()

  • Pingback: 8 Factors to Consider When Hiring a Junior Developer()

  • ikaruga

    Jesus. You just described the most convoluted and complex technical interview. If I were a junior dev and interviewed for you, I would turn down the job offer!

    • It has worked quite well for us. The process can be intimidating as some of our hires have mentioned. However, everyone in the Sandglaz team will be working on challenging problems and finding elegant solutions to problems, and the interview process makes sure that the candidate is the right fit.

      What would you do differently and why?

      • ikaruga

        Intimidation is not the problem.

        First, it’s not practical in a competitive environment. Any good developer will have multiple offers on her plate at the same time. All things being equal (and this is the case in a competitive environment), most people will pick the job with the shorter interview process. Another way of looking at it, you’re making potential candidates work for *FREE*. Again, time is money, and its a no-brainer to interview at places requiring less time investment. A possible workaround we’ve considered is actually PAYING candidates to interview. (Instead, we opted to make the interview process shorter.)

        Secondly, you don’t really need such a long interview process. I’m assuming you’re looking for “smarts” and an “intuition” plus communication skills. You can do that with a “cultural fit” interview plus some kind of coding challenge. Really, the whole process can take no more than 2 days.

        • The process described is actually 1 day for the assignment, 1.5 hours in-person interview, and a half hour screening phone call. The preparation time for designing the interview is actually 2 days including designing the assignment, and coding it ourselves to make sure it can be accomplished in 3-4 hours.

          It is actually a much shorter time investment than you describe. It might seem like a lot because it requires the interviewer to put more effort in advance.

          • ikaruga

            We haven’t had a bad hire either. You’re trying to automate what is fundamentally an “art” — all you’ve achieved is a bulky interview process but haven’t really guaranteed that you’ve weeded out bad hires.

            Going out on a limb here but I’m willing to bet the rest of your company is the same way — lots of red tape and bulky processes. The interview also says a lot about the company.

            I can tell you though that if a recruiter asked me to interview at your company, I would ask him if he thought I was crazy 🙂

          • Nowhere in the article or in my comments does it talk about automating the hiring process.

            I consider twisting of words and inability to see making bad assumptions as a red flag in an interview process, so I wouldn’t hire you anyway :).

          • ikaruga

            A better word is “formalize” — in case you haven’t noticed but that’s what you’re really doing. (And “automate” isn’t a bad description because that’s the end game of processes.)

            Either way, the whole point of this is (ignoring the fact that I wouldn’t fit in at your company), you’re excluding potential candidates by making an unnecessary lengthy interview process.

          • It’s possible that some candidates could get excluded, but most tech companies I’ve talked to or interviewed with had an interview that’s a lot longer than than (some even have 5 separate interviews over 5 separate days!).

            I definitely wouldn’t want to spend more time than necessary vetting candidates, as I have lots of other work to attend to. Hiring the right candidate is important, and I personally wouldn’t cut corners with it.

            It is also a very iterative process, you get better at interviewing and gauging candidates the more you do it.

          • Justus Danny Eapen

            Formalizing an interview process is a very good idea. I would never hire a candidate who equated “shorter interviews” with “better company”.

            That is a fundamentally flawed judgment. Better companies have more discerning interview processes and want to hire developers who appreciate the rigors of a formal process.

            I don’t want to work with lazy people who find challenge unappealing. I want to work with disciplined individuals who REALLY want to work with me.

            Zaid is totally right in this case and I’d be surprised if Ikaruga works for a company worth their fighting words.

        • I would also add, making no hire at all is often better than making a bad hire. A bad hire will cost you a lot of time, and create unnecessary problems.

  • Leo Ortiz

    I think the programming test should come first, not last. The whole reason most companies use it is to filter out applicants immediately. That’s how automated testing platforms market themselves as well, for example: “Ask candidates to write real code, before calling them for an interview.”
    That quote is from TestDome, just one of the many coding test services online. That’s the reason they exist. To evaluate the skill level of the applicant and see if they’re even worth calling in and talking to. Maybe things are different when hiring junior developers… but I don’t think they should be. If you don’t expect them to have that much experience, give them an easier test. Or even just a general aptitude test. Don’t waste your time with unsuitable applicants, and don’t waste their time either.

  • Adam Rawst

    FizzBuzz still makes sense. Just not ask to do this at home, because it will be easily Googled. Ask to do this on paper in your office on interview. It will show you how programmer thinks of the resolving the problem and what decisions does he/she make. And you will be surprised how a lot of developers still did not hear about FizzBuzz, so it will be new task for them. Even they do this already you lose nothing.
    The only one problem is that you may lose so much time on live interviews. I think you can use programming tests like Tests4Geeks, but do it before inviting guys to interview.