
Ask HN: What qualities do you look for in a junior developer? - kgraves
I am currently hiring developers for a junior position again for my startup.<p>I say &quot;again&quot;, 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.<p>Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.<p>I slogged it out for another 4 months and I&#x27;m giving it another go on hiring juniors. But would not like to make the same mistake.
======
BlackjackCF
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.

~~~
noir_lord
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.

~~~
Code_Blizzard
I can do those, but still learning how to program. Any recommendations on job
searches?

------
hluska
_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.

~~~
gregmac
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.

------
maxehmookau
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...)

------
seattle_spring
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.

------
lojack
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.

------
8draco8
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.

~~~
lgunsch
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.

------
talmand
>> 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.

------
patmcc
>>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.

------
Paul_S
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.

------
rubyn00bie
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.

~~~
dcole2929
>> 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

~~~
liquidise
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.

~~~
le-mark
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.

------
lukeqsee
\- 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.

~~~
rmetzler
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.

------
clavalle
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.

------
baku-fr
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" ;-)

------
franciscop
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.

~~~
earthtolazlo
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.

~~~
daddyo
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.

------
dcole2929
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.

------
jdavis703
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.

------
sevensor
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.

~~~
spicytunacone
What town, out of curiosity?

~~~
sevensor
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.

------
abrongersma
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.

------
kadabra9
Junior developers are just that - junior developers.

Sounds to me like what you really want are senior developers at a junior
developer salary.

------
askz
* 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

------
rovek
Sounds like your chosen solution (junior developers) doesn't meet your
requirement (time- and cost-efficient development).

------
njharman
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.

------
baron816
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.

~~~
Bahamut
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.

------
sploosh
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??

------
bjpbakker
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).

------
agentultra
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.

------
EnderMB
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.

------
kagali
I strongly suggest finding another field more suitable for you.

Perhaps something in the fast food industry.

------
alain94040
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.

------
gargarplex
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.

------
eksemplar
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.

~~~
le-mark
> 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!

~~~
eksemplar
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.

------
ditn
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...](https://proandroiddev.com/what-i-look-for-in-a-junior-android-
dev-3581ebd9f213)

tl;dr: I want someone who is excited by the platform and has shown a
willingness to learn, as well as some autodidactic tendencies.

------
cirgue
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.

------
muzani
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.

------
tyingq
>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.

------
user5994461
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.

------
allworknoplay
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.

------
rhodysurf
Look for applicants who have gotten involved in technical projects and clubs
in college. Thats always where we find our best interns.

------
vcanales
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.

------
torte
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.

------
jononor
Curiousity, willingness to get hands dirty and ability to be introspective.

------
hitgeek
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.

------
alex_raul
By far the best quality is being a quick learner.

------
forgottenacc57
Find a smaller number of experienced people.

------
Danihan
High SAT / ACT scores lol

With 400 apps you'll need to send them a quickie programming challenge to thin
the herd.

