What Your Job Descriptions Are Saying to Developers About Your Company

Every week I get a fairly steady stream of emails from recruiters, announcing an opportunity for some software development related job: engineer, programmer, senior developer, architect, and so on and so forth. These emails come in all shapes and sizes and, probably owing to my eclectic, polyglot background, they cover a range of different technologies and programming languages. One relatively common characteristic is that below the actual text of the email is pasted a job description. More often than not, I read this (or at least start to) out of general curiosity as to the state of the market. Some of them are reasonable and straightforward, making me think that the company in question would be a good, or at least decent, place to work. But others contain things that I’d call red flags.

Extrapolating beyond what gets sent to me via secondhand emails and generalizing to job boards and sites and other places where companies solicit talent (I can’t speak directly to these since I haven’t looked at them in quite a while), I think companies would be well served to consider what their job descriptions say to developers about them. It may not always be what’s intended. Consider some of the following characteristics of a job description and what they imply about the job.

Alphabet Soup of Technologies

“We favor and value superficial exposure and grandstanding over depth of knowledge and thoughtfulness.”

If your job description lists ten, twenty, even thirty (they get pretty ridiculous) different acronyms covering a smattering of programming languages, markup types, development methodologies, design patterns, and things that may not even actually exist, you’re sending the message that you value prospects that engage in a kind of bedpost-notching gamificiation when it comes to programming. If you stop and think about it, how would a developer acquire experience with all of those different technologies? Would you prefer he cram them all into a single project? Would you prefer that he pick or lobby for two to three new ones for each project he does and do a lot of projects? Would you prefer he never work on the same thing twice?

If the answer to any of these questions is “yes,” then you’re actively putting on the front porch light for people more concerned with playing with new toys than getting work done (like Fashionista). If the answer is “oh, well that’s not what we’re saying” then you’re asking the impossible. And you’re apparently targeting the sort of people who consider “I think I read a blog post about that once” a qualification for adding it to their resume. That leads to the hire of General Custer. So with this kind of ad, you’re targeting a group dynamic where people value breadth over depth of knowledge and are willing to exaggerate or even lie about either.

Emphasis on Years Spent on Particular Technologies

“We work harder, not smarter.”

Do you need someone that’s been banging out Java code for at least seven years? It has to be seven? Not six? If I’m at six and a half, should I follow the “always round up” method or the “round to even” method? I need to know so that I’ll know whether or not I’m qualified to program for you. I can round up? Great! Oh, wait. It says need four years of XML (whatever that means) and I only have three. I feel so inadequate. Unless… can I count non-contiguous years? I’m pretty sure that I “did XML” for a while about eight years back. Yessiree–I came into the office, day after day, and did XML. In fact, I think it was the same file, even. I did nothing but create the same XML file by hand every day for months, so that’s got to count for a lot, right?


Here’s the thing. You don’t actually want people who have “done Java” or “done XML” or “done whatever” for X years. What you actually want is people who are good at Java, XML, or whatever, and you mistakenly think that a good measure (or at least indicator) of that is how many years they’ve spent doing it. The problem is that this assumes that people acquire skill at the same rate, which is demonstrably false. It also assumes that they are spending all of that time improving, which, I would argue, becomes increasingly improbable with each additional year of experience. Certainly there are people who simply like working with a technology and wouldn’t have it any other way, but if you find someone who has been banging out Java code day in and day out for a decade, it might occur to you to ask them things like, “why aren’t you a lead or manager or architect or something?” The answer might be that they love having their hands on the keyboard, but it also might be (not said, of course) “I’m just not good enough at it to achieve anything besides not being fired.”

Are those the people that you want to hire? Probably not, but are you that confident that you can cull them out in an interview when the stakes are pretty high? As an awesome saying goes, you run the risk of hiring not a Java developer with ten years experience but a Java developer with the same one year of experience ten times. If you want talent and achievement, what you should actually want is people who are good at programming and design in general. It really doesn’t even matter what language(s) the developer knows if she’s good, and it certainly doesn’t matter how many years she’s been cranking out code in it. But if you start focusing on years/tech metrics, you’re going to get candidates optimized for that–you’re going to have a department dominated by worker bees who’ve been churning out innovation-free code for decades.

Applicants will Take a Forty-Five Question Test

“However extensive your previous experience, you’ll always be junior to us.”

What you ask candidates to do resonates with them beyond the interview process and into their employment; it sets the tone for what their tenure will be like. And what do you think it says to them when you give them something reminiscent of an SAT subject test? It says, “alright young student, if you can pass this standardized aptitude test, you are deemed worthy of learning at the feet of our esteemed senior developers.” Standardized tests and the hiring process are both necessarily reductionist activities, since they involve culling a very large percentage of potential applicants down to a much smaller percentage, but there the similarities end. Standardized tests are administered by nameless teachers, graded by faceless graders, and judged by admissions officers the students will never know.

Standardized job application quizzes are administered by internet or hiring authority, graded by the same, and judged by the same. If the applicant doesn’t score an 80% or whatever is necessary to move on, then no big deal. But if they do wind up hiring on, it will be with people to whom they’ve submitted to a student-professor/grader/administrator/gatekeeper relationship. That person can always point out at any time during your tenure that you didn’t know when filling out your scantron that the C# compiler will not choke on “virtual public void MethodName.” I recognize that this could be claimed to some degree with any method of candidate evaluation, but nothing says, “you’re no different than an entry level kid” like simulating the kinds of standardized testing that most people haven’t done in years or decades.



“We’re embarrassingly waterfall and we don’t know how to fix it.”

Companies that are proud of waterfall development methodologies come right out and tout it as their way of doing things (or they call it something like “Rational Unified Process”). That’s not going to be ideal for a lot of top talent, and it might even be a deal-breaker for some of them, but at least it seems self-aware. If you swap this frank assessment for the rather meaningless term “SDLC” (short for “Software Development Lifecycle”), it says that you don’t actually want people to know your software development methodology is. Be honest–if this is on your job description, and a candidate asks whether or not your process is agile as part of the “questions from the candidate” section, how are you going to respond? My money is on hem, haw, and make a comment about how you’re “in the process of getting a little more agile but we kind of *ahem*, that is, ah, we’re kind of still somewhat, er mostly waterfall.” Why do I say that? Well your “SDLC” says, “kinda-sorta-maybe-something-other-than-waterfall,” but your “phases” says, “really, really waterfall.”


The reason that I say this is more of a bad sign for candidates than “waterfall and proud” is that “waterfall and proud” indicates that there is purpose and belief in that process, making it somewhat more likely that things are stable and sane. In smaller shops or places that do small fixed bid types of projects, for instance, you can probably have some success with a waterfall approach. Candidates recognize that (or else they’re simply unaware that there’s an alternative to the waterfall “procrastinate-rush” way of doing things). But if you hide your waterfall behind vague acronyms, it tells candidates that you’re aware that your process is far from ideal but you haven’t done anything about it. From this, candidates can only infer that you’re lazy/sloppy when it comes to process or else that you’re not competent when it comes to process. Neither one exactly rolls out the welcome mat for top-notch talent.

If you want to describe your development methodology and it isn’t something simple like “Scrum” or “XP,” I’d suggest asking for experience with exactly what you want: probably design, implementation, and stabilizing/sustaining. Whether your approach has “phases” or “sprints” or whatever, it’s going to have those activities, so you may as well list them by name. Rightly or wrongly, SDLC has drifted from being a way to describe software in different states of development and has come instead to describe a process that’s hard to pin down and even harder to follow. You don’t want to broadcast that, true or not.

Be Prepared to Answer Some Real Brain Teasers!

“We think we’re MENSA” or “We think we’re Google” (which thinks it’s MENSA)

Applicants get it. You want to hire clever people. You want to hire people that think outside the box. Literally. And not only that, but you want to demonstrate that you think outside the box by asking non-programming or heavily algorithm-related questions when gauging whether candidates think outside of the box. It would be so in the box to ask programmers questions about programming or to have them program. You’re looking for some kind of box-thinking-outside synergy where everyone has their secret puzzle decoder ring and the cliches flow like box wine.


To you, it looks selective. To most people, it just looks gratuitously self-congratulatory. If you actually are a Google or another respected tech titan and you have the rep to back it up, applicants will prostrate themselves and tolerate this silliness for a chance to punch their ticket with your name on their resume. But if you’re Acme Inc. and you specialize in making shoelaces, you’re threatening to drive away serious talent and be left with goofballs, word-game enthusiasts, and trivia experts more interested in standing behind metaphorical velvet ropes as VIPs than doing high quality work. Unless your business model is this, you’d be better served to hire people who can write code than people who know how to measure exactly four gallons using three and five gallon jugs.

So Then What To Say?

If it seems as though I’m impossible to please, I’m really not. In fact, just having these things in your job description in no way means that what I’ve said is true about your company–it just means that this is the vibe you’re giving off. But if you want to give off a better vibe, I’d suggest a simple description of what the job’s responsibilities are and what would be necessary in order to do that job successfully. There’s no number of years or soup of technologies that do that–what does it is something like this: “we’re looking for Java web developers who are familiar with IoC containers and can meet deadlines with minimal supervision.” No gimmicks, no window-dressing on potentially unfavorable realities, and no weird, degrading exams.

So then how do you go about separating the wheat from the chaff during the interview process? Without exception, the places I’ve found that seem best at doing this are the ones that dole out actual programming assignments. It’s one of those things that is apparently so blindingly obvious that most don’t think of it; if you want to determine whether someone can complete programming assignments, give them one to complete. If you try to interview developers the way you would project managers, middle management, salespeople, etc., it’s kind of crapshoot. A developer that’s very good at memorizing trivia about the compiler or reciting the benefits of object-oriented programming may not actually be able to program. A standard, two hour interview with the trivia lightning round, followed by classic tradeoff-type questions, will not uncover this nearly so well as asking the person to spend five to twenty hours coding up some sample assignment.

If that’s not practical for logistical reasons or because of hiring particulars at your institution, you might at least ask for code samples to evaluate. Or perhaps you could spend a few hours pair programming with the candidate or doing a code review of open source code. Whatever you do, though, the important thing to remember is that you want to send the message to developers that you’re looking for people who are competent and demonstrate as much when asked to do so. By all means, evaluate and select based on other important criteria–personability, communication skills, organization, etc. But what you’re looking for, at the core of it, are people who are going to be efficient and competent developers. So when you roll out the welcome mat for them in the form of a job description, consider the first impression that you’re making. Ask yourself if you think it’s one that will intrigue those efficient and competent developers.