Hire a Great Web Developer: 10 Things You Need to Know
Article by Christopher McCulloh
The role of “web master” or “web programmer” has come a long way in the last 20 years. Finding good candidates for a client-side or front-end software engineer position is hard – especially if you don’t know the difference between client-side, middle-tier, back-end, Java, JavaScript, ECMAScript, jQuery, Angular, ReactJS, MongoDB, SQL, TypeScript, CoffeeScript, LESS, SASS, CSS, HTML, XHTML, DHTML, LOL, ROFL, and WTF.
“I log onto LinkedIn with the full expectation that I will find a sad, third-rate Facebook and an inbox full of recruiter spam.”
No one wants that. Not hiring managers, not recruiters, not developers – not even LinkedIn, for that matter! Let’s fix it.
Peppered throughout this article are actual quotes (like the one above) taken from the numerous developers I spoke to while writing this article. Special thanks to the Salesforce User Experience Advocates (a team of 10 front-end developers) for their invaluable suggestions, feedback, and quotes for this article. It would not have been possible without them.
“[I look for] calm, reasonable, polite [communications] mostly talking about their companies and asking if they can set up a totally reasonable amount of time for a phone call with specifics about their calendars, etc. No lists of tech. Nothing about CRM or WordPress or PHP or .Net.”
Bring on the list!
1. Make Sure the Person Doesn’t Already Work for the Company You’re Hunting for
It makes me sad to even have to say this, but just about every developer I talked to for this article had, at least once, been contacted by a recruiter recruiting for the company they already worked for. Not only is this a tacky move that kills your chances of ever recruiting that developer in the future, but you also might accidentally be spilling the beans about an impending involuntary job change.
2. Don’t Contact Me at Work. Ever. For Any Reason. Ever.
“I don’t expect my work email inbox to be polluted with that noise. I’m trying to use it to, you know, work. They should only use LinkedIn.”
Don’t email me at my job. Don’t call me at my job. Especially don’t leave a voicemail at my job.
“At [my previous employer], we moved around a bunch, and anyone could have gotten my voicemail.”
3. We’re Mostly Introverts
If you are at a recruiting event, have clear, concise signage and pamphlets.
Don’t be pushy. Don’t get up in our face. You will scare us away.
“Most of these recruiters just remind me of the ‘cool kids’ at my high school or Greek life jerks from my college days. I feel awkward and self-conscious around them, and I wonder if they’re silently judging me in their heads the way the people they remind me of did loudly in our younger days.”
You’re safer assuming this is what your candidate is feeling than not. Yes, this is a generalization. Yes, many web developers were the frat boys and sorority girls. Yes, you are actually totally nice and would never say or think anything mean about your candidates.
4. Be Professional
“Unless you’re warning me about something, never use exclamation points!!!!! OR ALL CAPS.
We don’t know you. Don’t attempt to sound like a friend. This is a professional correspondence with someone who is probably well educated, most likely extremely pedantic, and knows the difference between ‘your’ and ‘you’re'”
Use proper spelling and punctuation. You are representing the company you are recruiting for, but we also know you will potentially be representing us to that company. If you can’t bother to use proper spelling, punctuation, and grammar with me in your introductory email, why would I trust you to give any sort of good impression of me to the company that I’m going to potentially be negotiating with through you for something as important as my salary.
5. Don’t Speak the Slang Unless You’re Part of the Group Who Makes the Slang
It might seem unfair, but this is actually good advice for life in general. You sound like a completely out-of-touch parent trying to be relevant to their teenage kids. And you may well accidentally offend someone.
“When I see ‘We want a real rock star with a passion for …’ I just read ‘We are going to expect at least 70-hour weeks from you and make asinine, unreasonable demands. This job will suuuuuuuuuuuuuuuuck.”
Don’t say ‘rock star ‘ or ‘ninja’ unless we are going on tour to Kyoto dressed in black and carrying guitars.
This could easily have been part of point No. 4, but it happens so often that I’ve made it its own point. So many developers immediately delete these emails with “cool slang” language in them.
And while we are talking about vernacular, it’s a good time to sort out what some terms actually mean:
6. ‘Web Developer’ Is the Least of the Acceptable Terms
Never “web master.” You’re either from 1999 or 16 years old if you’re a “web master.”
“A ‘web master’ is something your condescending boss tells you his 14-year-old nephew is while he’s mentally calculating how little he can pay you and how loudly he can scream at you and his secretary buys pre-ground GreatValue coffee in bulk that you have to make yourself in the backroom where the sales guys come and drink it all before you notice it’s done brewing and then you have to make another pot. I’m speaking straight from experience here.”
Not a “web designer,” either. that’s a different thing. They design. They usually don’t program. If they did, they’d be “web programmers”!
“Web developer” is a base-level descriptive term we probably use with our friends. It’s like calling yourself “Mike” when your name is really “Michael.” Most “client-side engineers” probably think of themselves as “web developers” but wouldn’t put that in business correspondence or on their resumes.
“Front-end developer ” is nearly synonymous with “web developer,” but we put a bow tie on it by replacing “web” with “front-end.”
“Client-side engineer” is probably the most formal option.
Really, any combination of either “front-end”, “client-side”, or maybe even “JavaScript” with “engineer” or “developer” – and you can even throw “software” or “web” in there if you’d like – will do. But never “web engineer”; that’s just weird.
All the acceptable permutations I can think of right now, ordered from least to most serious, are:
– Front-end [web] developer
– Client-side [web] developer
– JavaScript [web] developer
– Front-end [software] engineer
– Client-side [software] engineer
– JavaScript [software] engineer
If the position you are recruiting for isn’t listed here, there’s probably something “off” about it (as of this writing).
“[T]itles are [mostly] irrelevant. The important part is to express what the actual work will be, what the team environment will be like, and why the company is a solid place to invest your career . [You can] give me the title ‘walrus-in-training’ and as long as those things line up, I’ll be happy.”
7. Java I Not Related to JavaScript
If you don’t know the difference between these two, it leaves me little confidence that you are accurately describing the position to me or that you even understand what the company is hiring for. So, let’s take a crash course.
First of all, Java and JavaScript are two completely different and unrelated programming languages. The creators of JavaScript unfortunately named it that to glom on to Java’s popularity. They also gave JavaScript a superficially similar syntax. The languages are, however, two completely different things.
“In my early days as a developer, I showed up for a job interview where it very quickly became obvious that the company was looking to hire a brain surgeon, and I was merely a nurse practitioner. Even if I had been a long-time experienced general practitioner, I still wouldn’t have qualified. Shame on that recruiter.”
There are three “tiers” in programming: front, mid, back, and mobile. (I know, that’s four. Mobile is its own world and generally unrelated to web development but often shunted into the same category.)
What you need to understand here is that this code is generally delivered to the web browser from the web server. The browser on the user’s computer executes (runs) this code. It is everything the user sees and interacts with. It decides how everything looks and acts. It decides what happens when they click or drag or hover.
For reference, the tag soup for client-side is: JavaScript, ECMAScript, ES6, ES2015, CSS, HTML, JS, TypeScript, CoffeeScript, Babel, BabelJS, Webpack, Browserify, React, ReactJS, Angular, Backbone, Marionette, Node, Node.js, CSS, LESS, SASS, SCSS, XHTML, DHTML, jQuery, Bootstrap, Grunt, Gulp, NPM, Heroku, UI, UX, Firebase, and D3.js. (See point No. 5 for more.)
Middle-tier: Also known as “MT” – but don’t you call it that! It is often wrongly referred to as “back-end” Middle-tier is loosely described as any code that executes on the server. The server is the computer that sits “in the cloud” (a.k.a., “someone else’s computer”) and responds to your requests.
For example, when you type in http://www.salesforce.com, there’s a server somewhere that eventually receives that request, processes the request, and responds accordingly. Processing the request is what the middle-tier does: “Oh, you want the Salesforce homepage? Okay, let me see: Are you logged in? Yes? Okay, let me grab your account. Yeah, here we go, you get the Dreamforce attendee promo splash (image) with the links to your most visited pages in the header.”
In essence, the middle-tier typically decides what page you see and what goes on that page, and then it hands your browser all of the code needed to make that happen. Front-end developers are encroaching on this space due to Node.js, but in the coming years, a brave middle-tier developer could feasibly market themselves as a Node.js developer.
For reference, the tag soup for middle-tier is: PHP, .NET, Java, Ruby, Python, Node.js, Rails, Ruby-on-Rails, REST, API, Groovy, and Scala.
Back-end: Also known as “database admin”, “DBA”, “sysadmin”, or “network admin.” Back-end developers are typically those who maintain the servers themselves or work on the actual database. I’m lumping several disparate disciplines together here because they’re often shoved into the background and marginalized (even though they tackle some of the hardest tasks!. However, a great DBA and a great network admin are two very different things.
These are generally the people who either maintain the machines on which the code runs or are in charge of where the actual data is stored. Often, this is more of an area than an actual position, unless the company deals with big data. Usually the middle-tier or front-end developer will deal with this area as an additional responsibility, but it won’t be their area of expertise. Any company with a serious web presence is going to have at least two or three people in this area doing very different things.
“The ‘back end’ is a very diverse group. Someone who manages Linux and Apache – or the AWS servers – may be completely isolated from DBA knowledge, and a DBA [who] works in the relational world may be completely insulated from the NoSQL world of things like Hadoop and MongoDB.
For reference, the tag soup for back-end is: SQLServer, Oracle, MySQL, MongoDB, NoSQL, SQL, Hadoop, Apache, Tomcat, Microsoft/Windows Server, AWS, Amazon [insert anything here], CDN (content delivery network), Akamai, and data integration.
Mobile developer: People wrongly conflate them with web developers, although the lines between the two are becoming more blurred thanks to thinks like React Native. There is also some surface level overlap with back-end and/or middle-tier developers, especially where the technologies used are concerned. You’ll sometimes find middle-tier or front-end developers doing “hybrid” mobile applications development because they have to. Typically “native” is preferred, much in the same way that native applications are typically preferable to web applications.
For reference, the tag soup for mobile developer is: iOS, Android, SDK, Java, PhoneGap, Unity, Objective-C, C#, Cordova, XCode, VisualStudio, VB.NET, Swift, and React Native.
It is very important that you understand the differences between these roles, because sometimes – especially with smaller clients – the company may not be very clear on what it actually needs. It’s up to you to make sure you are getting the right candidates to the right positions and the right positions to the right candidates.
8. Be Specific, Concise, Accurate, and Realistic
The relevant technologies for client-side are JavaScript (a.k.a. ECMAScript), CSS, and HTML. There are also tools, libraries, and frameworks that let you write those three things in much more robust or specific ways. These tools are LESS, SASS, CoffeeScript, TypeScript, ES6, ES2015, ES(insert numbers/years here; ES stands for “ECMAScript” and the numbers/years are different models, basically], Angular, React (a.k.a. ReactJS), Backbone, jQuery, and Marionette.
“Don’t list every unrelated skill under the sun. When I see a long list of technologies, I feel like a recruiter is throwing out a dragnet and, at the same time, making improbably picky demands. [They’ll end up] throwing 95 percent of the fish they caught back. Plus, these lists are often completely laughable; no one has 3+ years of experience in ES6. It hasn’t even been around that long!”
Listing tools and frameworks can be okay, but try to limit yourself to just one. Best to pick one of the three top-level technologies, with preference given to the order in which I listed them, and one specific tool/framework/library (ask the company which one is the most important). Your message should look something like this:
We are seeking a senior JavaScript developer, preferably with experience in ReactJS.
If someone knows JavaScript, they will typically be reasonably comfortable with CSS and HTML. If someone knows CSS, they will be reasonably comfortable with HTML. If someone only knows HTML, they aren’t a web developer. Only ask for a CSS developer (instead of a JavaScript developer) if the client specifically says they need one.
CSS can be crazy hard, and I know of fewer specifically CSS developers than JS developers. If a JS developer is like a unicorn, a CSS developer is Pegasus. No less magical, no less valuable, but certainly less talked about and sought after. If people can have only one, they typically go with a unicorn. The Holy Grail is a Pegasus unicorn, but those are exceedingly rare. HTML is just a horse. No one cares about horses.
Do not ever, unless pressed by the candidate, present anything approximating the following:
We’re looking for a JS developer with 3-5 years’ experience in jQuery, JavaScript, ES2015, ReactJS, Angular, SASS, LESS, CSS, DHTML, or comparable technologies, plus experience in JIRA or TeamTrack and Git (or other SCM).
If you do present something like that, you obviously don’t know what you’re talking about, and the company therefore probably doesn’t, either. This message is completely unappealing and sends a signal about the kind of annoyances a candidate is going to end up dealing with throughout the hiring process and their tenure at the company.
“Be specific. What is the position? How much money? What is it going to be like to work there? How big is the team? What’s the environment like? Otherwise, you’re just wasting both of our time.”
Pro tip: Unless specifically demanded by the potential employer to do so, do not ever mention XHTML, DHTML, HTML4, HTML3, Prototype.js, MooTools, AJAX, YUI, Dojo, or Script.aculo.us. Even jQuery is questionable – probably best to leave it out. Some of these are so old or uncool that it’d be like asking someone if they want to do game development for the Nintendo 64. No. No one does. Not interested. This more or less goes for WordPress also. Just about any company that uses these technologies probably uses them in legacy settings or is aware they should be phased out.
9. WordPress Is the McDonald’s of Websites
“There is absolutely nothing wrong with being the kind of web developer who takes WordPress gigs, but you should understand that this is a completely different ball game from a client-side engineer. No value judgement here. Some people enjoy burgers, others like steaks, and some enjoy both but only want to professionally make one.”
Never send client-side engineer candidates a WordPress gig if you ever hope to recruit them for anything else in the future. Unless they specifically have WordPress listed on their LinkedIn or StackOverflow Careers CV, you are better off not mentioning it.
This arguably includes Drupal as well. If someone is looking for a Drupal job or has relevant Drupal experience, you’ll probably know it. If they aren’t, there is likely a reason for that. If the position is explicitly a Drupal position, you’re better off only going after people who specifically mention Drupal in their CVs.
10. Be a Part of the Community
We absolutely don’t mind recruiters coming to meetups and events. It’s even okay to ask (a few) questions to learn more about emerging trends and technologies. In fact, we’ll probably love it if you do.
“It’s just a job to you, but it’s our career. We can tell if you don’t care.”
Do some Hour of Code, Nettuts, and/or Egghead.io tutorials. Try to learn to code yourself. If you find it to be fun, you’ll eventually have a marketable skill — – and have the best leads on a great job for yourself. At the least, you’ll be able to speak more intelligently to the people you are trying to recruit and the clients for which you’re recruiting.
The best recruiter is one who understands not only the companies and positions , but also the technologies and the people filling those roles. Build a rapport, and soon you’ll find you actually have some candidates coming to you.
Questions? Agree or disagree? Think I’ve forgotten anything major? How would you like to be approached by a recruiter? What recruiting disasters have you seen? We’d love to hear from you!
This article was initiated by myself, but benefited greatly from huge contributions and suggestions from my team at Salesforce – notably Scott Williams (@scott_joe_will ), who came up with at least five of the “10 things,” and Stephen James (@tweetllama ).
A version of this article originally appeared on 42Hire.com.
Christopher McCulloh is a senior front-end engineer at Salesforce.