Developer: Why we didn’t hire you.

Photo by striatic (Creative Commons)

In the last year, I’ve interviewed around 30 candidates. These were for mid to senior level positions at three different companies. Sadly, I’ve only recommended hiring two. Each case is unique, but here are some common reasons for a thumbs-down vote.

You don’t know JavaScript:

Depressingly, none of the candidates had a strong background in JavaScript.

You want a web development job, but can’t code in the only language web browsers can run? Tell me more!

Ten years ago we mostly avoided JavaScript, and just did everything on the server. You could scrape by without knowing much JavaScript. Five years ago, I would have been worried about your lack of commitment amid the rising popularity of *.js frameworks, but if you were otherwise qualified I would still risk it –hoping you could learn enough javascript on the job to keep up.

Today, JavaScript is everywhere. It’s in the browser. It’s on the server. Some of your developer tools and utilities use JavaScript. JavaScript is the native language in many enterprise-grade database systems. JavaScript has become a basic requirement for just about any kind of development, and it isn’t an easy language to work with. Mastering the techniques, patterns, and frameworks needed for production quality code takes a lot of time and practice.

So, if you walk into my interview without a solid grasp of JavaScript, you aren’t going to get the job. You simply aren’t qualified to code for the web.

Never used distributed source control:

I get that your skills with DVCS are thin. Most business employers aren’t using a DVCS yet. Some don’t use formal source control at all (which is terrifying). Most candidates had a little experience with SVN or TFS, but a full third had no source control experience at all. Only a handful had used Mercurial or Git, and several hadn’t even heard of either.

I can teach the basics of DVCS to any competent user, even a non-developer, in just few hours. I’m not worried about the lack of the skill itself –a PluralSight video and a copy of SourceTree and you’ll be good to go. But the fact that you don’t already have significant experience with at least one popular DVCS is a major red-flag.

The entire stack, most of the popular 3rd party libraries, and even most of the developer tools are open source projects, hosted on the web in public Git or Mercurial repositories. Most build systems, package managers, and continuous integration systems rely on DVCS technologies. The fact that you aren’t comfortable with at least one such system tells me that you aren’t keeping up with your profession, and aren’t participating in the general developer community.

You don’t know anything about design patterns.

When you list MVC on your resume, I absolutely will ask about design patterns. My expectations are low, but I will still be disappointed if you have no clue what I’m talking about.

I’m fine that you don’t know Martin Fowler’s name, or about the Gang of Four. If I ask you to name an example of an abstract singleton factory in, I won’t be surprised when you to look at me like I just broke out in interpretive dance. But I do expect you to know what the term “design pattern” means. You should know that “MVC” is the name a design pattern — even better if you can explain a little about the pattern itself.

I’m not an academic design pattern guru myself, but some patterns are so common that it is difficult to discuss code with someone who doesn’t know the basic terminology –singleton, factory, repository, observer, etc. development in particular revolves around a very specific set of design patterns; IoC, MVC, Repository, and Unit of Work being the most relevant. If you aren’t at least vaguely aware of these patterns, then you can’t possibly be proficient with the MVC framework.

You don’t have to be able to debate the merits of domain driven design vs. onion architecture. You don’t have to be able to tell me the distinction between transaction script and unit of work. But if I ask you if a C# static class is a singleton, you should at least understand the words coming out of my mouth… even if you can’t give me a good answer to the question itself.

Day laborer:

You only know technologies your former employers used, but nothing else. Your last company still used ADO.NET Datasets, but you haven’t even bothered to read up on LINQ to SQL, Entity Framework, or NHibernate?

Congratulations, you did the bare minimum necessary to earn a paycheck!

I want candidates that take responsibility for developing their own professional skills beyond just the minimum. It’s great that you can meet today’s challenges, but I need people who will be ready for tomorrow’s projects too.

Needs training wheels:

You’ve only coded modules for existing applications, and maybe a few stand-alone tools or utilities for the server room. What you’ve done sounds impressive, but it doesn’t seem like you’ve ever built an application from the ground up. I’m not expecting that you’ve architected your own custom enterprise, multi-tenant ERP solution. But nowhere in the interview did you give me the impression that you’d ever even clicked “file –> new project” either.

So you can follow someone else’s patterns and conventions, and you can plug code into someone else’s framework. But I can’t trust you to code for problems beyond those that some pre-built framework anticipated.

If I give you a blank Visual Studio solution and a list of requirements, can you deliver a complete and high-quality product? Will it be coded to standards? Will the code be organized and maintainable?

Closed shop:

You’ve never build software for users outside your employer’s firewall, much less for the general public. The quality, reliability and usability needs of software for non-technical end-users is different. It requires a more disciplined approach, and involves skills that aren’t heavily used with purely internal projects.

If you can code for the public end-user, I am confident that you can easily code for my company’s internal users. The reverse is not true.

Line of business developers are particularly prone to this problem, since most LOBS are internal only. Internal users are more tolerant to errors, poor design can be offset by specialized user training, and reliability is bolstered by your control of both the server and client environments.

I need to know that you can code to higher standards when it is necessary.

Doesn’t know why:

You have a firm grasp of the tools and technologies your employers have used in the past, but when I ask, “why did your company choose to use X instead of Y?” I get nothing. You told me about that amazing widget you wrote — I liked that story — but when I ask you why you didn’t use a 3rd party widget instead, you can’t give me a valid business justification for the extra time and effort you spent on a custom solution.

You don’t have to be an expert in cost analysis or anything, but I need to know that you can make sound decisions about the technologies, platforms, and coding techniques that you’ll use to solve the challenges my company is facing. Choosing a technology just because it’s cool or popular isn’t always the best bet for business applications.

2 Replies to “ Developer: Why we didn’t hire you.”

Leave a Reply

Your email address will not be published. Required fields are marked *