What I look for in a junior developer

Bill Gathen

December 11, 2014

Company Size: 50 total, 5 developers
Field/Industry: Online Advertising
Dev Responsibilities: Build internal tools to support the sales staff and account managers.
Stack: Several dozen apps using Ruby, Rails/Sinatra with an increasing amount of jQuery and AngularJS on the front-end. Git for source control and RSpec for TDD.
What We Do: Some number-crunching and supply performance reports to clients, but mostly large-scale optimization of client advertising campaigns via third-party APIs (Google and Yahoo) using SOAP and REST

Don’t worry: you don’t need to know all those buzzwords

A working knowledge of some of those buzzwords is a clear plus, but anyone with real-world experience in all those areas would be a rare find and certainly not someone I’d call a “junior” developer. In fact, anyone who can check every box on any application is probably too good to be true.

A few years ago we had a candidate who used all the right words at the right times, and we took them at face value. But in six months on the job, he demonstrated no actual coding ability, took no notes, retained no knowledge, accepted no responsibility, and actively resisted learning. It ended badly.

In contrast, one of our best developers came from a print design background with only a few months of basic PHP experience at a previous job. We collaborated on his first project, gradually shifting more and more responsibility onto his shoulders. I pointed him to online resources, books and videos to help him grasp the new concepts that came at him daily. Two years later, he’s self-sufficient and in charge of projects that drive the entire company.

“Soft” skills trump tech skills

If the “buzzword-compliant” candidate actually had the skillset he said he did, would he be our best employee today? Not necessarily.

Developers evolve. We grow, we shrink, we become easier or harder to deal with as time goes on. This is why the "soft" skills trump the hard skills for me every time. If you have those characteristics, I don't care if you know Python instead of Ruby, because in a month you'll know both. I don't care if you don't understand how online advertising works, because in a week you will. Development doesn’t stand still: even the expert needs to be constantly-learning or they’ll be left behind.

So what are these “soft” skills and how do you demonstrate them before you’re hired?

It's ironic that things like interpersonal skills are referred to as "soft" skills, since some people find them terribly-hard or even impossible to learn. The ones I consider most important are: enthusiasm, attention to detail, a hunger for learning, and thirst to contribute.

Enthusiasm

If you can't muster a reasonable amount of enthusiasm for the tasks delegated to you, every day will seem like an eternity: for you and anyone you talk to. The best way to show enthusiasm in an interview is to ask questions! Ask about the job, the company as a whole, the users, the size and shape of the team. You are interviewing them, too: be an active participant. If you hear an answer you like, say so! I've worked with developers who seemed pathologically unable to ask questions and that's a recipe for missed deadlines and stagnation. Make it clear from the start that if you don’t know something, you will dig until you get the answer.

Attention To Detail

Attention to detail is critical to problem-solving, especially debugging. A “bug” is simply an unintended behavior. The more precisely you diagnose what the app is doing, why it’s doing it becomes obvious, and fixing it becomes trivial. As trivial as possible, anyway. If you’re asked to do a coding exercise, align your brackets, indent properly, use standard naming conventions for the language. When they ask a question, answer as precisely as you can. And when you ask them a question, insist on precise answers. You are an investigative journalist and quotes like “pretty well”, “it varies” and “some of the time” don’t sell newspapers.

Hunger for Learning

I'm less-interested in what you know than in how quickly and effectively you learn new things. If I ask "what are some interesting tech things you've learned recently?" I want to hear about new languages, libraries that do cool things, etc. If you can demo it, terrific! Tell me about tutorials you've worked through, books you've read, conference talks that blew your mind and expanded your world.

Thirst To Contribute

Too many people figure out the minimum work they can do before saying "I'm done". I call this "checkbox thinking". I asked for an input field and you gave me one. Check! But it's not styled like the rest of the page, is in a poor location for usability, and has no label to make it obvious what it's for.... Don't be that person. If you always do your best to add the maximum value time and money will allow, you'll be the one I come to when something has to be done right. If you have a story that demonstrates this -- from a previous job, open-source or class project -- find a way to work it into the conversation.

What have you built?

GitHub is a great reality-check. Get a complete project out there, make sure it's the best you can do and make me aware of it a few days in advance of the interview, so I can play around with it and see where you're currently at with your skills. Be warned: if it's a generic "to-do" app, I'll presume you typed it in directly from some tutorial, so try and find something that’s at least a bit off the beaten path.

On an interview a few years ago, the candidate had several apps he’d built to play with new technologies. Twitter had just opened up its API, and he wrote a scraper to show his timeline. The api changed constantly and by the time he interviewed with us the code was broken, but he articulately explained the challenges he’d faced and I was still impressed because he’d pushed his boundaries and hadn’t given up when it got tough.

Code that works flawlessly is definitely better than code that doesn’t, but the key feature of good code is that it communicates. Can I open your project and figure out what it’s for, how to build it, how to run a local copy, just from the README? Do your objects follow convention and demonstrate program flow in an orderly, clear fashion? If you start a project and I take it over, I don’t want to sit with you for hours while you explain what you meant: your code should do that for you. Use clear, intention-revealing names (http://billgathen.com/2014/05/25/intention_reveali... and when that’s not enough, don’t be afraid to leave comments.

How Do You Get Unstuck?

I'm not a fan of live-coding puzzles, but if you said you were familiar with RSpec, I'd reply "Excellent. Here's a laptop with RSpec installed: can you give me a little demo?" If you flow through it with polished ease, fantastic. But I'm just as interested in how you handle getting stuck. Development is about problem-solving: do you fully-leverage all the tools at your disposal, such as Google, Stack Overflow and the standard docs for your toolset? No one knows everything out of their head. The Internet is our external brain: using it and your colleagues effectively means no problem will stop you for long.

Learn the technologies that move the world. Learn to test and debug. But in the end, I believe in potential. If you were fully-formed and perfect in every way, you wouldn't be trying for "junior" developer jobs: you'd be raising your sights and doubling your salary requirements.

And I wouldn’t be able to afford you.