Ask HN: What qualities do you look for in a junior developer?
70 comments
I'm a little worried you're never going to find a junior developer that's satisfactory enough to qualify for what you want, explicitly because you're looking for a senior developer at junior developer pay.
Junior developers need to be given time to make mistakes and learn. I know a senior developer might seem too expensive for your budget, but hiring a junior developer might ultimately cost more for your project over time. The time that they're going to take to have to ramp up and learn everything is probably going to eat into the time to deliver any sort of product. What I'm saying is that a junior developer is a time and money investment, and sometimes it just pays to hire a senior developer/contractor and have them get the project out.
Anyway... what I would look for in a junior developer isn't whether or not they're amazing at data structures etc. I could really give a rats ass as to whether or not they're able to do something like Codility. What I need to see is that they know at least some basics on how to code, and that they have the aptitude and motivation to learn.
The two most important qualities to me in a software developer is the ability to communicate and the ability to learn. Why is communication necessary, particularly in a junior developer? I need to know that they're willing to swallow their egos and come to someone for help. It's the fastest way to learn.
Hell, I feel like I learned much faster because I was able to swallow my pride and ask someone with seniority for help. It didn't mean that I would run to them at the first sign of a struggle, but if I was burning most of my day doing something that I felt wasn't really going to teach me much, but was causing me to struggle with something - I would go and ask someone senior for help.
Junior developers need to be given time to make mistakes and learn. I know a senior developer might seem too expensive for your budget, but hiring a junior developer might ultimately cost more for your project over time. The time that they're going to take to have to ramp up and learn everything is probably going to eat into the time to deliver any sort of product. What I'm saying is that a junior developer is a time and money investment, and sometimes it just pays to hire a senior developer/contractor and have them get the project out.
Anyway... what I would look for in a junior developer isn't whether or not they're amazing at data structures etc. I could really give a rats ass as to whether or not they're able to do something like Codility. What I need to see is that they know at least some basics on how to code, and that they have the aptitude and motivation to learn.
The two most important qualities to me in a software developer is the ability to communicate and the ability to learn. Why is communication necessary, particularly in a junior developer? I need to know that they're willing to swallow their egos and come to someone for help. It's the fastest way to learn.
Hell, I feel like I learned much faster because I was able to swallow my pride and ask someone with seniority for help. It didn't mean that I would run to them at the first sign of a struggle, but if I was burning most of my day doing something that I felt wasn't really going to teach me much, but was causing me to struggle with something - I would go and ask someone senior for help.
Learn and communicate, I don't think anyone would argue with that, but how do you judge that from talking to someone, reading their resume, or viewing their portfolio? That's the question. For a junior developer these are some things I look for:
I want to see evidence they are familiar with the tools; since I hire for enterprise Java that is: eclipse (or other ide), maven, and git. I don't expect them to know much, just evidence they've used them and are familiar with some the concepts they mask (i.e. the class path) or why they're important (ie version control).
I ask them to tell me about a project they've done and the data structures they used, then drill down just enough to see if they understand why they used them, and how they're implemented.
Depending on the work, I'll drill down into data structures a bit more, but otherwise, I don't focus on anything but familiarity with the basics.
If they're straight out of school I ask them what they're favorite CS class was.
One of my favorites is to ask about a tricky bug they've solved recently. This one either gets people talking, or they don't have anything. If they don't have anything, I'll probe, but if a candidate can't talk about this it's a strong signal to not hire (imo).
As an exampe, I interviewed a self taught guy one time, very green. He had written a few simple android apps, but had used notepad and the command line, so didn't know anything about Eclipse. I asked him about any datastructures he'd used in his apps and why. He was at a loss, and had only used arrays apparently. The guy had some positives; he had shipped two apps, which is something, working with primitive tools. But he also hadn't taught himself the "standard" tools, which we all do to a point.
When it comes to someone that green, I just don't have the time to train them. I once worked with an architect who was really good at training green developers, and his management gave him a funnel. They developed a really great (and cheap) team. Most of their devs stayed long term, but some got training and left after 1-2 years.
I want to see evidence they are familiar with the tools; since I hire for enterprise Java that is: eclipse (or other ide), maven, and git. I don't expect them to know much, just evidence they've used them and are familiar with some the concepts they mask (i.e. the class path) or why they're important (ie version control).
I ask them to tell me about a project they've done and the data structures they used, then drill down just enough to see if they understand why they used them, and how they're implemented.
Depending on the work, I'll drill down into data structures a bit more, but otherwise, I don't focus on anything but familiarity with the basics.
If they're straight out of school I ask them what they're favorite CS class was.
One of my favorites is to ask about a tricky bug they've solved recently. This one either gets people talking, or they don't have anything. If they don't have anything, I'll probe, but if a candidate can't talk about this it's a strong signal to not hire (imo).
As an exampe, I interviewed a self taught guy one time, very green. He had written a few simple android apps, but had used notepad and the command line, so didn't know anything about Eclipse. I asked him about any datastructures he'd used in his apps and why. He was at a loss, and had only used arrays apparently. The guy had some positives; he had shipped two apps, which is something, working with primitive tools. But he also hadn't taught himself the "standard" tools, which we all do to a point.
When it comes to someone that green, I just don't have the time to train them. I once worked with an architect who was really good at training green developers, and his management gave him a funnel. They developed a really great (and cheap) team. Most of their devs stayed long term, but some got training and left after 1-2 years.
Ability to communicate and ability to think.
That's the core of what I look for in any (junior) developer.
Its the skeleton on which everything else hangs.
Its not the only qualities but the most important ones.
That's the core of what I look for in any (junior) developer.
Its the skeleton on which everything else hangs.
Its not the only qualities but the most important ones.
I can do those, but still learning how to program. Any recommendations on job searches?
The interviews were so bad that I ultimately rejected all of the applicants. I also withdrew the position because it was wasting my time.
Maybe you shouldn't hire juniors? Junior devs are an investment and we owe them respect and genuine mentorship. By definition, they will 'waste your time'.
And frankly, if you can't afford seniors, your company's mentorship opportunities will be weak enough that the smart play for truly capable, career minded juniors would be to work elsewhere.
Maybe you shouldn't hire juniors? Junior devs are an investment and we owe them respect and genuine mentorship. By definition, they will 'waste your time'.
And frankly, if you can't afford seniors, your company's mentorship opportunities will be weak enough that the smart play for truly capable, career minded juniors would be to work elsewhere.
And to add to this: Juniors are cheaper in salary, but that doesn't mean they're cheaper.
Hiring is not free -- in fact by the sounds of it the OP has already spend at least tens of hours unsuccessfully trying to hire someone.
Mentoring time is not free. You're also paying them to learn (read docs, rework code, etc) whether you realize it or not.
There's also a very non-zero chance you're incurring technical debt at a high rate, and that may not be apparent until you go to fix bugs (and cause 15 more every time you do) or add new features (and need to rebuild half the software to do so).
Knowing how to build good, maintainable and supportable software comes with experience and this is what you're paying a senior for.
Hiring is not free -- in fact by the sounds of it the OP has already spend at least tens of hours unsuccessfully trying to hire someone.
Mentoring time is not free. You're also paying them to learn (read docs, rework code, etc) whether you realize it or not.
There's also a very non-zero chance you're incurring technical debt at a high rate, and that may not be apparent until you go to fix bugs (and cause 15 more every time you do) or add new features (and need to rebuild half the software to do so).
Knowing how to build good, maintainable and supportable software comes with experience and this is what you're paying a senior for.
When hiring juniors hunger to learn should far outweigh qualifications and raw knowledge in a particular technology imo.
That said, I think there may be a deeper issue here. You want to hire seniors which suggests that your startup _needs_ seniors and the experience that they bring. But you're hiring juniors.
You're going to end up disappointed as you need senior developers at this point.
They're going to end up disappointed as they require senior developers in the team to learn from and grow.
(Perhaps unrelated, I think if you've interviewed 400 people and haven't found someone "good enough", the issue may not be with the candidates...)
That said, I think there may be a deeper issue here. You want to hire seniors which suggests that your startup _needs_ seniors and the experience that they bring. But you're hiring juniors.
You're going to end up disappointed as you need senior developers at this point.
They're going to end up disappointed as they require senior developers in the team to learn from and grow.
(Perhaps unrelated, I think if you've interviewed 400 people and haven't found someone "good enough", the issue may not be with the candidates...)
On the resume, I look for a mix of:
* Technical education (college degree, classes, etc.)
* Hands-on technical experience. This can range from an internship, to just building computers for friends and family. Something that shows initiative.
* Some other work experience, even if it's a cashier at Dominos or a volunteer position at a library.
I avoid resumes of candidates that have degrees but no measurable hands-on experience outside of school. I find students that have gone through high school and college with absolutely no work experience to be entitled and often spoiled. I understand that is not a universal truth, but I've observed it enough to not bother with those candidates.
In the interview itself, I look for candidates who:
* Are excited about the job, learning new stuff.
* Don't have a bad attitude. This can often be evident when talking about your stack. If you have, say, a Java stack, and the candidate makes some offhand comment about how Ruby is so much better, it's a hint about how they'll act on the job.
* Can answer basic questions about the stack they'll be working on. I'm not talking algorithms here. This is mostly to test if they give a shit about the job enough to read up on the details for 20 minutes before coming in for an interview.
* Technical education (college degree, classes, etc.)
* Hands-on technical experience. This can range from an internship, to just building computers for friends and family. Something that shows initiative.
* Some other work experience, even if it's a cashier at Dominos or a volunteer position at a library.
I avoid resumes of candidates that have degrees but no measurable hands-on experience outside of school. I find students that have gone through high school and college with absolutely no work experience to be entitled and often spoiled. I understand that is not a universal truth, but I've observed it enough to not bother with those candidates.
In the interview itself, I look for candidates who:
* Are excited about the job, learning new stuff.
* Don't have a bad attitude. This can often be evident when talking about your stack. If you have, say, a Java stack, and the candidate makes some offhand comment about how Ruby is so much better, it's a hint about how they'll act on the job.
* Can answer basic questions about the stack they'll be working on. I'm not talking algorithms here. This is mostly to test if they give a shit about the job enough to read up on the details for 20 minutes before coming in for an interview.
I would caution you against hiring junior developers.
Typically you hire junior developers for what they will become, and not where they currently are. That means the traits you're looking for is a desire to learn and genuine interest in technology.
If you only have junior developers, they will have a much tougher time learning. They'll never see how software should be built.
There are exceptions. Really simple prototypes is one of them. Some maintenance of existing projects might be another exception, depending on the quality of that project, and the type of work involved. Anything reasonably complicated, I wouldn't expect them to finish, and if they did finish, I'd expect it to need to be rewritten very early on.
If you want to do it right, hire a mid level or senior developer. It's better to have a single senior developer than 5 junior developers. If you're looking to hire multiple developers another choice would be to hire one senior developer and one junior developer. Just don't hire only junior developers.
Typically you hire junior developers for what they will become, and not where they currently are. That means the traits you're looking for is a desire to learn and genuine interest in technology.
If you only have junior developers, they will have a much tougher time learning. They'll never see how software should be built.
There are exceptions. Really simple prototypes is one of them. Some maintenance of existing projects might be another exception, depending on the quality of that project, and the type of work involved. Anything reasonably complicated, I wouldn't expect them to finish, and if they did finish, I'd expect it to need to be rewritten very early on.
If you want to do it right, hire a mid level or senior developer. It's better to have a single senior developer than 5 junior developers. If you're looking to hire multiple developers another choice would be to hire one senior developer and one junior developer. Just don't hire only junior developers.
First of all I can't believe that there was not even one decent junior dev among 400+. Last year I was in the same position as you but received far less applications (15-20). 3 of them was decent, one of them we employed and he turned out much better than on paper.
Main thing is to give them homework: not more than 2 hours project that they will solve at home and commit to private repo. Make it unique enough to avoid stackoverflow copy-pastes. Do not give them academic problems, ask them to create real world examples. For example: create CRUD that does something specific like file uploads with resize or similar; access unreliable API and do something with it; create calendar that allows multiple tasks per day (UI/UX); scrape data from the website and put it in to DB.
Those are just examples, but they are easy enough to do in under 2 hours and you can test results in under 2 minutes. Out of those 400+ applications, half of them will not even bother spending 2 hours on a task, then in a day or two you will restrict that remaining ones to about 50-60 just by checking results of the task. Rest are just personal interviews. Just remember to write a feedback email even to those unsuccessful applications.
Main thing is to give them homework: not more than 2 hours project that they will solve at home and commit to private repo. Make it unique enough to avoid stackoverflow copy-pastes. Do not give them academic problems, ask them to create real world examples. For example: create CRUD that does something specific like file uploads with resize or similar; access unreliable API and do something with it; create calendar that allows multiple tasks per day (UI/UX); scrape data from the website and put it in to DB.
Those are just examples, but they are easy enough to do in under 2 hours and you can test results in under 2 minutes. Out of those 400+ applications, half of them will not even bother spending 2 hours on a task, then in a day or two you will restrict that remaining ones to about 50-60 just by checking results of the task. Rest are just personal interviews. Just remember to write a feedback email even to those unsuccessful applications.
Very interesting approach. I've heard of an approach similar to this one, although it was not limited to junior devs. You can quickly find out if a possible final candidate is appropriate, and a good fit for the company, by simply working with them for a day on a small project.
>> Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.
I think you will find you will save money in the long run if you hire senior developers if you actually do require senior-level development skills instead of expecting junior developers to do the same work for lower pay.
I think you will find you will save money in the long run if you hire senior developers if you actually do require senior-level development skills instead of expecting junior developers to do the same work for lower pay.
>>Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.
It sounds like you're trying to hire cheap developers, not junior developers.
If you really want junior developers, you have to do a crazy thing; hire people that are actually junior (have very little experience) but have potential. If you'd done that 4 months ago you'd probably have some decent developers right now.
It sounds like you're trying to hire cheap developers, not junior developers.
If you really want junior developers, you have to do a crazy thing; hire people that are actually junior (have very little experience) but have potential. If you'd done that 4 months ago you'd probably have some decent developers right now.
Why waste time, buy a service like codility and only interview the best couple ones. I don't work for any of those online code tests btw, but they're pretty good for sorting applicants and cheaper than your own time.
Junior developers need to have high IQ and ability to code, everything else you will need to teach them anyway. Keep in mind that if you don't have time to teach them they will not be cheaper than seniors, unless all you need is bums on seats to fool investors or something nefarious like that.
Junior developers need to have high IQ and ability to code, everything else you will need to teach them anyway. Keep in mind that if you don't have time to teach them they will not be cheaper than seniors, unless all you need is bums on seats to fool investors or something nefarious like that.
I've been in this exact situation and had some real success (and failure)... I think hiring a junior developer who will be great and good for your organization comes down to one thing: how much passion do they have for programming?
If they don't do it on their own, and don't seem interested in programming for their own benefit outside of the job, then don't hire them.
People who are new but enthusiastic and spend a lot of time learning on their own are who you want.
Subsequently, hiring too many junior developers can be a hinderance because there aren't enough people to coach and guide them. It adds technical debt to your organization and makes for a shitty experience for the junior dev. They need help and they need people who have the time to help them. It's easy for junior devs to feel inadequate and suffer in silence.
Finally, ask yourself why don't have the funds to hire a more experienced engineer. It may be a sign of an unhealthy organization or goals which are way too big. I say this from experience and the pain I felt as a result of not listening to my gut and pushing back ferociously. You think firing someone "sucks," try laying off a room of people you know, who you care about, and who have been good to you and your organization... bad goal setting will cause it.
If they don't do it on their own, and don't seem interested in programming for their own benefit outside of the job, then don't hire them.
People who are new but enthusiastic and spend a lot of time learning on their own are who you want.
Subsequently, hiring too many junior developers can be a hinderance because there aren't enough people to coach and guide them. It adds technical debt to your organization and makes for a shitty experience for the junior dev. They need help and they need people who have the time to help them. It's easy for junior devs to feel inadequate and suffer in silence.
Finally, ask yourself why don't have the funds to hire a more experienced engineer. It may be a sign of an unhealthy organization or goals which are way too big. I say this from experience and the pain I felt as a result of not listening to my gut and pushing back ferociously. You think firing someone "sucks," try laying off a room of people you know, who you care about, and who have been good to you and your organization... bad goal setting will cause it.
>> If they don't do it on their own, and don't seem interested in programming for their own benefit outside of the job, then don't hire them.
I strongly disagree with this. We as an industry desperately need to stop propagating these myths about what makes a good developer. You're enthusiasm for programming outside of work has jack all to do with your ability to perform the job functions expected of a SWE. Is it a sign if you are into programming as a pass time? Sure, but it's by no means an indicator of the quality of said programming. We don't expect lawyers to be litigating cases in their free time and we would never tell an accounting firm to pass up any candidate who doesn't demonstrably love doing their taxes. People work 8+ hours a day in these jobs and otherwise have lives. One could even argue that other interests is better for the long term prospects of candidate because they are less likely to burn out. 8 hours a day is more than enough time to build up domain expertise given the ~260 days you can expect to spend doing this each day
I strongly disagree with this. We as an industry desperately need to stop propagating these myths about what makes a good developer. You're enthusiasm for programming outside of work has jack all to do with your ability to perform the job functions expected of a SWE. Is it a sign if you are into programming as a pass time? Sure, but it's by no means an indicator of the quality of said programming. We don't expect lawyers to be litigating cases in their free time and we would never tell an accounting firm to pass up any candidate who doesn't demonstrably love doing their taxes. People work 8+ hours a day in these jobs and otherwise have lives. One could even argue that other interests is better for the long term prospects of candidate because they are less likely to burn out. 8 hours a day is more than enough time to build up domain expertise given the ~260 days you can expect to spend doing this each day
Let me qualify the parent comment with my own feelings, as i knew the moment i read their comment what your reply would say.
Of the 30 or so engineers i have worked closely with over the last 6 years, nothing correlates better to the programmers ability than what i describe as "passion".
I do not share the stance that this requires someone to spend time outside of work on personal projects or burning the midnight oil on work. Instead, what i look for is a burning desire to be creative and solve problems, specifically with code. I give candidates a number of opportunities to express why coding is important to them, and what would they be doing in its absence. If i had to only ask a single interview question, it would be something to that effect.
While i don't mean to suggest every excellent programmer shares this passion, it has become the best single barometer i can find of gauging future ability. With midlevel and senior devs this task becomes a lot easier because you have so much experience to lean on. For juniors, passion is king.
Of the 30 or so engineers i have worked closely with over the last 6 years, nothing correlates better to the programmers ability than what i describe as "passion".
I do not share the stance that this requires someone to spend time outside of work on personal projects or burning the midnight oil on work. Instead, what i look for is a burning desire to be creative and solve problems, specifically with code. I give candidates a number of opportunities to express why coding is important to them, and what would they be doing in its absence. If i had to only ask a single interview question, it would be something to that effect.
While i don't mean to suggest every excellent programmer shares this passion, it has become the best single barometer i can find of gauging future ability. With midlevel and senior devs this task becomes a lot easier because you have so much experience to lean on. For juniors, passion is king.
I agree with the grandparent that relying on passion is toxic to our profession, almost exploitive. But as you say, it's a reliable indicator. Passionate juniors can be their own problem though, like monstrous object hierarchies for simple problems. But that's a separate issue.
I strongly disagree with you and I'm guessing you don't have much experience hiring.
You reference lawyers and doctors but they have already spent years in dedication of knowledge and experience. That's simply a bad comparison.
This is about a junior developer not mid-level or senior. At some point as another comment says you have enough experience to not focus on it outside of work. In the beginning if you don't have passion and a desire to learn which your time at work won't be sufficient for, it's probably a good indicator you won't be a good engineer.
Further your eight hours a day 260 days a year number is hogwash in the real world. No one gets eight hours of coding a day done unless they're prototyping in a cave isolated from the world. Communicating through pull requests, ticket systems, emails, slack, etc drive real productivity to somewhere between 3-6 hours a day depending on the company. So what it really means is you're talking 1.5x-2.25x the amount of time. That's assuming all learning is equal and the you're given tasks which linearly increase your knowledge (which is just nonsense). I for one would not want to hire someone who needs three or four years of work experience to overcome their "junior" title.
I'm also in no way advocating they work more than 40 hour weeks or donate their time to the company. They need to be passionate enough to push their knowledge over a series of plateaus.
A lot of people go to "code schools" now but lack passion. They want the pay thinking it'll be easy because of shitty and evil marketing campaigns that make false promises. That passion will prevent them from excelling at the work.
You reference lawyers and doctors but they have already spent years in dedication of knowledge and experience. That's simply a bad comparison.
This is about a junior developer not mid-level or senior. At some point as another comment says you have enough experience to not focus on it outside of work. In the beginning if you don't have passion and a desire to learn which your time at work won't be sufficient for, it's probably a good indicator you won't be a good engineer.
Further your eight hours a day 260 days a year number is hogwash in the real world. No one gets eight hours of coding a day done unless they're prototyping in a cave isolated from the world. Communicating through pull requests, ticket systems, emails, slack, etc drive real productivity to somewhere between 3-6 hours a day depending on the company. So what it really means is you're talking 1.5x-2.25x the amount of time. That's assuming all learning is equal and the you're given tasks which linearly increase your knowledge (which is just nonsense). I for one would not want to hire someone who needs three or four years of work experience to overcome their "junior" title.
I'm also in no way advocating they work more than 40 hour weeks or donate their time to the company. They need to be passionate enough to push their knowledge over a series of plateaus.
A lot of people go to "code schools" now but lack passion. They want the pay thinking it'll be easy because of shitty and evil marketing campaigns that make false promises. That passion will prevent them from excelling at the work.
- A voracious appetite for learning.
- A genuinely nice person.
If I have two things, I'm pretty sure the rest will work out in the end.
- A genuinely nice person.
If I have two things, I'm pretty sure the rest will work out in the end.
I second that.
I had a few students working with me. The one guy who asks questions when he doesn't understand something and who isn't afraid to say so, helps me the most.
I also like when I understand what skills a junior dev has (e.g. HTML, CSS, JavaScript vs Java), so I know what I can outsource to him and have a clue about how long it will take.
But I also learned, that the overhead of managing someone and helping them can eat up all my time. You need to balance it out and have a backlog of low priority tasks to throw at them.
I had a few students working with me. The one guy who asks questions when he doesn't understand something and who isn't afraid to say so, helps me the most.
I also like when I understand what skills a junior dev has (e.g. HTML, CSS, JavaScript vs Java), so I know what I can outsource to him and have a clue about how long it will take.
But I also learned, that the overhead of managing someone and helping them can eat up all my time. You need to balance it out and have a backlog of low priority tasks to throw at them.
For juniors I look for some background in the area I'm hiring in with some success in that area.
Mainly, though, I look for enthusiasm and eagerness to learn, the ability to communicate clearly, and intelligence. I also look for a balance of self-determination and the willingness to work through a problem on their own but also enough sense to know when and how the to ask the right questions when needed. Finally, honesty. If they've fluffed up their resume that is a red flag.
You are not going to be hiring senior level developers who've misclassified themselves. Juniors are going to take work; there is no avoiding that. Adjust your expectations to that reality and you will have a better chance of pulling in an employee that will do well for you over time.
Mainly, though, I look for enthusiasm and eagerness to learn, the ability to communicate clearly, and intelligence. I also look for a balance of self-determination and the willingness to work through a problem on their own but also enough sense to know when and how the to ask the right questions when needed. Finally, honesty. If they've fluffed up their resume that is a red flag.
You are not going to be hiring senior level developers who've misclassified themselves. Juniors are going to take work; there is no avoiding that. Adjust your expectations to that reality and you will have a better chance of pulling in an employee that will do well for you over time.
Don't forget that junior developers... are junior. They might not be the best devs in the world yet, but I'm pretty sure they can fit in any mold if you give them the right resources.
In your case, I'd say someone passionate enough to provide good value for the team. Just make sure you don't scare them away by making them feel they might "waste your time" ;-)
In your case, I'd say someone passionate enough to provide good value for the team. Just make sure you don't scare them away by making them feel they might "waste your time" ;-)
Maybe you should make the first step a small automated coding challenge? No longer than 1-2h and it's a simple filter.
Finishing the challenge on itself will be the first filter; then you can review the ones who finished it and interview the ones you like most.
BTW if you are looking for a remote web dev (front-end or back-end) drop me a line "public at francisco.io" <= my CV.
Finishing the challenge on itself will be the first filter; then you can review the ones who finished it and interview the ones you like most.
BTW if you are looking for a remote web dev (front-end or back-end) drop me a line "public at francisco.io" <= my CV.
Fog Creek does this for inexperienced roles, they have a simple challenge of extracting a string from a text file of garbage and then using that string as the subject line when applying. Took only a few minutes using sort piped into awk to finish it and I'm sure it probably weeds out a lot of applications.
I personally won't do any coding challenges without at least an initial technical phone screen. It's not really fair to ask for that kind of time investment from candidates without being willing to reciprocate.
We had over 400 applicants for a recent position.
Fairly giving them a time investment of 30 minutes (reading CV, tailoring technical interview, answering questions) would mean 200 hours of productivity loss. There is no way to defend this to a company, especially when hiring more than 1 a year.
If no coding challenge then it all comes down to the CV. You'll miss out on promising humble candidates who lack the CV buzzword bingo, and get burned on mediocre candidates whose parents paid for them to go through a top university. That's not fair to the talent either.
Of course if someone completes the coding challenge, you give them the time investment they deserve (8-16 hours spread over multiple employees). You save this time by declining those that do very poorly on the challenge, or refuse to do it out right.
You may not have an idea how awkward and depressing a technical phone interview is with a candidate that is not suited to the role. And delegating this to HR/Recruiters is a surefire way to increase noise and crash the hopes of people who pass the screen, but fail badly on future interviews.
Fairly giving them a time investment of 30 minutes (reading CV, tailoring technical interview, answering questions) would mean 200 hours of productivity loss. There is no way to defend this to a company, especially when hiring more than 1 a year.
If no coding challenge then it all comes down to the CV. You'll miss out on promising humble candidates who lack the CV buzzword bingo, and get burned on mediocre candidates whose parents paid for them to go through a top university. That's not fair to the talent either.
Of course if someone completes the coding challenge, you give them the time investment they deserve (8-16 hours spread over multiple employees). You save this time by declining those that do very poorly on the challenge, or refuse to do it out right.
You may not have an idea how awkward and depressing a technical phone interview is with a candidate that is not suited to the role. And delegating this to HR/Recruiters is a surefire way to increase noise and crash the hopes of people who pass the screen, but fail badly on future interviews.
I find it way easier (for me as a candidate) to do a quick test than finding/researching/applying to a new company, so if it 2x or 3x my chances it's totally worth it for me.
I'd say a small coding challenge/puzzle/fizzbuzz test is a must-have if you get over a 100 applicants.
I'll always look for curiosity, passion, intellectual honesty.
Depending on the job I'd further look at what they did to distinguish themselves (extra-curricular, self-study, Github projects, etc.)
I'll always look for curiosity, passion, intellectual honesty.
Depending on the job I'd further look at what they did to distinguish themselves (extra-curricular, self-study, Github projects, etc.)
My former company hired interns and junior level engineers regularly. If you are hiring jr devs because you can't afford sr people you are going to have a bad time. Jr Devs require constant attention early on if you want them to ever move pass the junior part. They need the ability to fall on their face occasionally and resources who can't point them in the right direction when they do. But if you can't afford to pay the Sr people your junior people are going to leave right around the point where they start really being a great value(that's 2-3 years in tops).
If you're looking for how to find hidden gems, my best advice is don't bother. Ask them fizz buzz (yes literally fizzbuzz), some basic OO vocab, and have them do an easy design problem. If they have a pulse and can do that, they're probably worth your time. For most devs of any level it's really hard to tell whether they will be valuable additions until you've actually worked with them. For a jr dev it's a pointless exercise. Find someone motivated, who seems like they can learn, and spend time putting in place a framework to make sure they have the tools to succeed.
If you're looking for how to find hidden gems, my best advice is don't bother. Ask them fizz buzz (yes literally fizzbuzz), some basic OO vocab, and have them do an easy design problem. If they have a pulse and can do that, they're probably worth your time. For most devs of any level it's really hard to tell whether they will be valuable additions until you've actually worked with them. For a jr dev it's a pointless exercise. Find someone motivated, who seems like they can learn, and spend time putting in place a framework to make sure they have the tools to succeed.
You need to find an edge. Maybe you can find the no. 3 university in your city and reach out to the top performing students there. You could also try the same strategy with a coding boot camp. What you can't do is just cast a net and expect to find talent. You have to actively recruit the people who fit the profile you need.
We're a small company in a small town. When we go to hire, we can't afford software developers, period. We can't pay relocation even if they were willing to move here. There's a local university, but we have yet to see a graduate of the C.S. program who was competent, willing to stay in town, and not already hired by one of the area's larger employers. We've made a couple of good hires, none of whom had significant programming experience.
We look for people with analytical backgrounds: engineering or the hard sciences. They have to be capable of independent thought and interested in solving hard problems. That's what we have to offer as an employer: you get to do interesting work and live in a really nice town.
We look for people with analytical backgrounds: engineering or the hard sciences. They have to be capable of independent thought and interested in solving hard problems. That's what we have to offer as an employer: you get to do interesting work and live in a really nice town.
What town, out of curiosity?
I'd prefer to remain pseudonymous, more or less, so I'll just say that we're in the same town as a big public university with a substantial ag program. I've lived in other towns like this, and I suspect my comment applies to any of them.
Some of the best engineers(junior/senior) I've found have come from community events. If you're on the hunt for some juniors then I recommend that you get our of your building and go to where the juniors are for the specific area of focus you're looking to hire for. These people have already shown the innovative that they're interested in learning more about that particular field and willing learn outside of the traditional 9-5. You can still run into bad apples, but it will help you look for key traits and behaviors that can increase the odds in your favor for attracting juniors that are coachable, self starters, or show an ability to grow.
Junior developers are just that - junior developers.
Sounds to me like what you really want are senior developers at a junior developer salary.
Sounds to me like what you really want are senior developers at a junior developer salary.
Find someone who codes for a hobby and have them show you a portfolio. Prove they can get things done. Who cares if they leveraged the internet for assistance? It's part of getting things done. Who cares if they don't know CS concepts? You're going to review all their code anyway.
Most importantly, find someone who you enjoy spending time with and will enjoy investing mentoring hours into.
Another approach: break your backlog into piecemeal tasks and hire senior freelancers to do fixed work for fixed costs.
Another approach: break your backlog into piecemeal tasks and hire senior freelancers to do fixed work for fixed costs.
* Curiosity
* Take initiatives
* Knows how to learn new things, +/- fast (and loves it)
* Knows when its the wrong way (even if its too late) and turn back
From my little experience, you don't have to do big technical challenges to detect those. But again I have very little experience in the business (5 interns and 1 junior hires) Social habilities are important too, but don't get fooled by those who talk too much
Good luck !
EDIT: formatting
* Take initiatives
* Knows how to learn new things, +/- fast (and loves it)
* Knows when its the wrong way (even if its too late) and turn back
From my little experience, you don't have to do big technical challenges to detect those. But again I have very little experience in the business (5 interns and 1 junior hires) Social habilities are important too, but don't get fooled by those who talk too much
Good luck !
EDIT: formatting
Sounds like your chosen solution (junior developers) doesn't meet your requirement (time- and cost-efficient development).
Ability to learn. Which means most of: eagerness, humility/humbleness/not believing they are knuths gift to the programming world, communication which at junior level means ability to listen and ask questions, confidence, that they derive Joy from programming/problem solving.
I really don't know.
But, some advice: if you get 400+ applicants again, just throw out all but ~50 without looking at them at all. That's too many to process, any you're wasting too much time trying for find the "best" ones. Randomly limiting your pool will make it easier to make a decision.
Also, I hope you don't go the traditional interview route (ie white boarding). I think more companies should do a "make your own interview process" where the candidates decide what to show off. Maybe that's walking you through a project, some live coding/pair programming, assessing your product, or a presentation on some aspect of technology (like functional programming, databases, security, etc). The one that impresses you the most wins.
But, some advice: if you get 400+ applicants again, just throw out all but ~50 without looking at them at all. That's too many to process, any you're wasting too much time trying for find the "best" ones. Randomly limiting your pool will make it easier to make a decision.
Also, I hope you don't go the traditional interview route (ie white boarding). I think more companies should do a "make your own interview process" where the candidates decide what to show off. Maybe that's walking you through a project, some live coding/pair programming, assessing your product, or a presentation on some aspect of technology (like functional programming, databases, security, etc). The one that impresses you the most wins.
That sounds more like you're screening for who can market themselves better, not really a skill-based assessment since there's no way to reasonably compare.
You get what you pay for! If you can't afford senior developers, get someone you can train that can listen and has an ability to hone coding chops. Take on an intern, or maybe a contractor... as a matter of fact, why do you look into having a recruiter do this for you??
What I want to see in junior developers is simply enthusiasm for programming and their ability to learn. Both are easy to spot by having a nice conversation with them and maybe pairing with them for a few hours.
> we had so many applicants (400+) that it was a tough challenge discerning the best candidates
You just want good candidates that fit your company. Then you /make/ them the best by teaching and mentoring them.
> I would like to hire senior developers instead, but they are too expensive for my budget
Sorry to say it but this sounds not like a good place for junior developers. You can't just put them in a senior position and expect results for cheaper payroll costs. They need to learn (experienced developers need to learn too, but juniors even more so).
> we had so many applicants (400+) that it was a tough challenge discerning the best candidates
You just want good candidates that fit your company. Then you /make/ them the best by teaching and mentoring them.
> I would like to hire senior developers instead, but they are too expensive for my budget
Sorry to say it but this sounds not like a good place for junior developers. You can't just put them in a senior position and expect results for cheaper payroll costs. They need to learn (experienced developers need to learn too, but juniors even more so).
You have to realize that hiring a junior developer means you will be spending a good portion of your time and energy on mentorship and compensating for their lack of skill and experience. This is an investment and one well worth making both for the mentee and mentor. You want your senior developers to be spending some portion of their time with the junior developers on your team. If you're not prepared to make this investment don't hire a junior developer: get a competent contractor instead.
If you are willing to proceed the next step is setting up your hiring process. I've used a loose, informal specification for a rather simple program as a take-home exercise. It takes around 3-4 hours to complete for a reasonably-experience programmer and can be completed in any language that the applicant is most comfortable with. When designing this specification I made sure that the language was clear and intentionally left some requirements vague. It is intended to be representative of a typical specification for a low-risk feature or system that you might encounter on the job: a few paragraphs detailing the problem, a description of the API, the inputs, the expected outputs, etc.
What's interesting about using this exercise with junior developers is seeing how they interpret the specification. Most developers out of school aren't trained to think in terms of specifications, requirements, etc. Your junior applicants will typically write some code to start solving the problem. They will skip translating requirements from the specification into tests. They won't think of the bounds on inputs or outputs. Often they will start writing code and implement the first thing that "works" (for some definition of "works").
This is wonderful! It gives you plenty of leading questions when you invite them in for a code review session. A good, naive solution is great. It gives you opportunities to talk about edge cases, tests, assumptions, invariants, performance, etc. The more you can get them to talk the better!
If they seem enthusiastic and are capable of taking a leading question and connecting the dots then you have a great candidate.
If you are willing to proceed the next step is setting up your hiring process. I've used a loose, informal specification for a rather simple program as a take-home exercise. It takes around 3-4 hours to complete for a reasonably-experience programmer and can be completed in any language that the applicant is most comfortable with. When designing this specification I made sure that the language was clear and intentionally left some requirements vague. It is intended to be representative of a typical specification for a low-risk feature or system that you might encounter on the job: a few paragraphs detailing the problem, a description of the API, the inputs, the expected outputs, etc.
What's interesting about using this exercise with junior developers is seeing how they interpret the specification. Most developers out of school aren't trained to think in terms of specifications, requirements, etc. Your junior applicants will typically write some code to start solving the problem. They will skip translating requirements from the specification into tests. They won't think of the bounds on inputs or outputs. Often they will start writing code and implement the first thing that "works" (for some definition of "works").
This is wonderful! It gives you plenty of leading questions when you invite them in for a code review session. A good, naive solution is great. It gives you opportunities to talk about edge cases, tests, assumptions, invariants, performance, etc. The more you can get them to talk the better!
If they seem enthusiastic and are capable of taking a leading question and connecting the dots then you have a great candidate.
I agree with the other comments, but in addition, interviewing ten people a day is far too many. Either the interview process was too short to truly gauge a persons ability, or you're stretching yourself so thin that someone would be to be a programming god to stand out.
As others have said, you should create a take-home test for someone to complete on GitHub. Have them fork a repo, pass some coding test, and submit a pull request into your repo. That will reduce the number significantly, and you'll know with some certainty that the person you're speaking to has some basic skill. The interview should purely be an exercise in seeing if they are a good fit, and to gauge where they are in their journey.
As others have said, you should create a take-home test for someone to complete on GitHub. Have them fork a repo, pass some coding test, and submit a pull request into your repo. That will reduce the number significantly, and you'll know with some certainty that the person you're speaking to has some basic skill. The interview should purely be an exercise in seeing if they are a good fit, and to gauge where they are in their journey.
I strongly suggest finding another field more suitable for you.
Perhaps something in the fast food industry.
Perhaps something in the fast food industry.
You want people who learn fast: you don't have to explain everything three times. It's not easy to detect this during an interview though.
The way I would do it is to focus on side-activities. If a hardware engineer built a website for a side-project, that's a good sign. Anything that shows success outside their expected space. Smart, fast learners tend to pick up random knowledge and apply it quickly and successfully.
People who need hand-holding tend to know their core topic well enough (they spent years in college refining those skills), but are having difficulty learning anything outside those core topics.
The way I would do it is to focus on side-activities. If a hardware engineer built a website for a side-project, that's a good sign. Anything that shows success outside their expected space. Smart, fast learners tend to pick up random knowledge and apply it quickly and successfully.
People who need hand-holding tend to know their core topic well enough (they spent years in college refining those skills), but are having difficulty learning anything outside those core topics.
I've hired quite a lot of programmers over the years, but I'm Danish, and around 95% of our junior applicants and 100% of the people we interview come with a relevant degree (2.5-5 years) because of our free education system. So it may be a tad different in the US where a lot of people are autodidact.
Basically I look for the following things.
* Do I think the candidate has the capacity to learn. Every hire we've taken straight out of college has been fairly useless for the first 3 months. They typically know how to write software, but they have no idea how to do it in an actual production setting. We've had hires who couldn't publish and deploy a simple asp mvc site to an IIS for instance. I typically judge this by what projects they've done during their education (and their free time) and what sort of roles they've filled in those projects.
* Does the person have the minimum technical skills required to learn. I don't care if you can write a double linked list on a whiteboard, but I do want you to be able to do simple things, know about best practices and preferably things like SOLID. We'll typically ask what people think about test-first-development as an example, and we'll try to provoke an answer that doesn't come from a text book to see whether or not they actually have an opinion and knowledge on the matter or they're just telling us what they think we want to hear.
* Do I think the candidate is capable of failing, accepting responsibility for the mistake and learning from it. It's perfectly fine to screw up, we all do it, but people who don't admit when they do it are dangerous.
* Communication skills. I need candidates to be able to explain what they are doing to their grandmothers without getting angry. Both because the business end won't understand otherwise but mainly because politeness and a well mannered temper is more valuable than gold.
* Do I think the person will be a strategically good fit in the team.
* Does the team think the person will be a good fit.
* Does it seem like the candidate wants to work for us. The best employees are the ones who value and take pride in their work. I don't want people to be blind zealots, but I want them to be able to tell their friends they're making a difference.
Often we end up with a few who are strong technically and a few who are strong in personality and willingness. We always go with the latter. Obviously I can't tell you about what we've missed out on, but I can tell you that we've always had successful hires which is pretty important, because the most expensive you can make as a manager is hiring someone who doesn't work out.
Basically I look for the following things.
* Do I think the candidate has the capacity to learn. Every hire we've taken straight out of college has been fairly useless for the first 3 months. They typically know how to write software, but they have no idea how to do it in an actual production setting. We've had hires who couldn't publish and deploy a simple asp mvc site to an IIS for instance. I typically judge this by what projects they've done during their education (and their free time) and what sort of roles they've filled in those projects.
* Does the person have the minimum technical skills required to learn. I don't care if you can write a double linked list on a whiteboard, but I do want you to be able to do simple things, know about best practices and preferably things like SOLID. We'll typically ask what people think about test-first-development as an example, and we'll try to provoke an answer that doesn't come from a text book to see whether or not they actually have an opinion and knowledge on the matter or they're just telling us what they think we want to hear.
* Do I think the candidate is capable of failing, accepting responsibility for the mistake and learning from it. It's perfectly fine to screw up, we all do it, but people who don't admit when they do it are dangerous.
* Communication skills. I need candidates to be able to explain what they are doing to their grandmothers without getting angry. Both because the business end won't understand otherwise but mainly because politeness and a well mannered temper is more valuable than gold.
* Do I think the person will be a strategically good fit in the team.
* Does the team think the person will be a good fit.
* Does it seem like the candidate wants to work for us. The best employees are the ones who value and take pride in their work. I don't want people to be blind zealots, but I want them to be able to tell their friends they're making a difference.
Often we end up with a few who are strong technically and a few who are strong in personality and willingness. We always go with the latter. Obviously I can't tell you about what we've missed out on, but I can tell you that we've always had successful hires which is pretty important, because the most expensive you can make as a manager is hiring someone who doesn't work out.
> Often we end up with a few who are strong technically and a few who are strong in personality and willingness. We always go with the latter.
Ever a candidate who's both? Great response, thanks!
Ever a candidate who's both? Great response, thanks!
Rarely. I'm from the public sector (a municipality) and the brutal truth is that we typically don't attract the best of the best. We don't pay enough and our reputation isn't great so we typically only attract the best of the best if they are having children (benefits) or come with some sort of ideology for wanting public service.
I actually wrote about this fairly recently, although it's aimed squarely at Android developers: https://proandroiddev.com/what-i-look-for-in-a-junior-androi...
tl;dr: I want someone who is excited by the platform and has shown a willingness to learn, as well as some autodidactic tendencies.
tl;dr: I want someone who is excited by the platform and has shown a willingness to learn, as well as some autodidactic tendencies.
Junior devs are a radically different value proposition than senior devs. You have to turn them into good developers, they will all look like garbage on paper if you are expecting someone who can walk in and do the job. Curiosity, tenacity, demonstrable coding experience (even if it's side projects), and interests/hobbies outside of tech seem to be the best predictors for us in hiring juniors.
Another approach is to hire freelancers and convert them into juniors if you like them enough. Juniors are an investment. Freelancers may secretly be seniors at junior salary.
Also when hiring programmers, you should be doing so from programmer communities (GitHub, SO) rather than job sites. Even FB groups will give you better odds. 400+ applicants sounds like you're hiring from the wrong places.
Also when hiring programmers, you should be doing so from programmer communities (GitHub, SO) rather than job sites. Even FB groups will give you better odds. 400+ applicants sounds like you're hiring from the wrong places.
>Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.
This feels like a red flag. Do you have existing, more senior, people that can oversee the work? If so, perhaps that's a valid trade-off. It won't reduce the overall cost though, just the monthly burn. More junior means slower delivery, or less quality. There's no free lunch.
This feels like a red flag. Do you have existing, more senior, people that can oversee the work? If so, perhaps that's a valid trade-off. It won't reduce the overall cost though, just the monthly burn. More junior means slower delivery, or less quality. There's no free lunch.
Use HackerRank. Make a test that require them to write a program to print numbers from 1 to 10 then from 10 to 1.
That should filter 2/3 of the candidates.
That should filter 2/3 of the candidates.
Smart, curious about code quality, no ego, hungry, and at least moderately experienced with the languages they'll need to use. You can't afford someone you need to spend months training and can't risk someone that has to break bad habits they learned cowboying shit. Vet that they're hungry to get good and smart enough to eventually be good.
[deleted]
[deleted]
Look for applicants who have gotten involved in technical projects and clubs in college. Thats always where we find our best interns.
TL;DR: Junior Developers != Cheaper Developers.
You have to put time and money into training them; it's a responsibility more than an easy buck.
You have to put time and money into training them; it's a responsibility more than an easy buck.
Most comments already get to the point. You can not hire a junior with senior or intermediate level skills.
It seems like you are in the same shoes as me at the moment. What I suggest you to do is to prepare a small test tasks they can do at home. This saves up time for you going through unnecessary extra interview processes and also shows some of their dedication and skills. I am not saying you should not have interviews, but it is hard to filter candidates just by resumes (and you can not have 400+ interviews).
Answering your question, I usually look out for the following:
1. After I sent the candidates the test task, but before they finish it (NOTE: I don't know they progress on it):
- Do they let me know when they have time to do the task (in case they are not able to it immediately) or do they just let time pass by.
- Do they come back with questions if they hit a wall somewhere.
- Do they let me know if they are not able to do the task (for whatever reason). At this point they are obviously out of the process, but they might re-apply at a later time.
- Communication is key at this level of the application process.
2. After I received the results of the test task
- Obviously did they finish the task in a reasonable quality. There are most likely mistakes in it, but this is irrelevant in case the general quality of the result is ok and the solution works as expected.
- The quality also reflects on how much time they spent testing their own solution.
- Did they finish all the sub-tasks (usually I also ask for documentation and tests) or did they just skip those.
- Did they try to find quick and dirty solutions or did they try to implement things properly (and most likely spent more time on it).
The best developer you can hire is somebody who does communicate pro-actively, is dedicated and develops maintainable solutions over "easy" ones. How much time they spent on the task and how proficient they were with the tools at hand (programming languages/frameworks) is not relevant in my opinion. If they were unfamiliar with the programming language for example and they spent the time during that task to learn part of it and delivered a proper solution with it, they got all my respect and I would be very likely to hire them.
You will also have to spent time reviewing the test task results, but I think this is less time-consuming than interviews. More than half of the candidates will probably jump off before you even see the results. For the other half you will learn how to distinguish a good from a bad solution quickly.
It seems like you are in the same shoes as me at the moment. What I suggest you to do is to prepare a small test tasks they can do at home. This saves up time for you going through unnecessary extra interview processes and also shows some of their dedication and skills. I am not saying you should not have interviews, but it is hard to filter candidates just by resumes (and you can not have 400+ interviews).
Answering your question, I usually look out for the following:
1. After I sent the candidates the test task, but before they finish it (NOTE: I don't know they progress on it):
- Do they let me know when they have time to do the task (in case they are not able to it immediately) or do they just let time pass by.
- Do they come back with questions if they hit a wall somewhere.
- Do they let me know if they are not able to do the task (for whatever reason). At this point they are obviously out of the process, but they might re-apply at a later time.
- Communication is key at this level of the application process.
2. After I received the results of the test task
- Obviously did they finish the task in a reasonable quality. There are most likely mistakes in it, but this is irrelevant in case the general quality of the result is ok and the solution works as expected.
- The quality also reflects on how much time they spent testing their own solution.
- Did they finish all the sub-tasks (usually I also ask for documentation and tests) or did they just skip those.
- Did they try to find quick and dirty solutions or did they try to implement things properly (and most likely spent more time on it).
The best developer you can hire is somebody who does communicate pro-actively, is dedicated and develops maintainable solutions over "easy" ones. How much time they spent on the task and how proficient they were with the tools at hand (programming languages/frameworks) is not relevant in my opinion. If they were unfamiliar with the programming language for example and they spent the time during that task to learn part of it and delivered a proper solution with it, they got all my respect and I would be very likely to hire them.
You will also have to spent time reviewing the test task results, but I think this is less time-consuming than interviews. More than half of the candidates will probably jump off before you even see the results. For the other half you will learn how to distinguish a good from a bad solution quickly.
Curiousity, willingness to get hands dirty and ability to be introspective.
ask them to do a small sample project. something that takes maybe 4 hours, and demonstrates the type of skills you are looking for. give them about a week.
By far the best quality is being a quick learner.
Find a smaller number of experienced people.
[deleted]
High SAT / ACT scores lol
With 400 apps you'll need to send them a quickie programming challenge to thin the herd.
With 400 apps you'll need to send them a quickie programming challenge to thin the herd.
I say "again", because the first time round we had so many applicants (400+) that it was a tough challenge discerning the best candidates from the pool and had allocated 10 interviews a day. The interviews were so bad that I ultimately rejected all of the applicants. I also withdrew the position because it was wasting my time.
Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.
I slogged it out for another 4 months and I'm giving it another go on hiring juniors. But would not like to make the same mistake.