I’m a Technical Recruiter to the core and that comes across in my approach to this topic. I’ve tried to show how I go about my process, and while I apply it to tech, most principles are universal. For those recruiting non-tech, there’s plenty of things here I hope you’ll find helpful, and certainly the overall framework will still apply, though not to the fullness required of roles of a more specialized nature.
Make your job descriptions easy to find, though not easily found by everyone and their out of work brother. Start with a title that’s clear, and standard, though not generic, (Technical Recruiter Vs. Recruiter, Cost Accounting Manager with Deltek Vs. the more generic, Accounting Manager, etc.) Have a jazzed up company intro. The stuff most companies include few read, even employees. Intro your team with an elevator pitch and then briefly describe the role. No one wants to be reduced to a list of bullets. The position blurb is a great place to express how you see the role in your company’s eco-system, especially in tandem with the team blurb. …Post with caution. Tell candidates about the exciting challenges they’ll get to tackle. They’ll feel invested in finding solutions with you. Everyone wants to feel like a Rock Star. Do you need an expert, maybe a Master, or even Ninja. Just remember to use descriptions that match the tone of your role. When you plant a seed, you allow the curiosity and excitement to build, or at least for potential candidates to remember the opportunity and company later, reaching out when ready. How will they get to use their skills in meaningful ways? What’s the impact your candidate will make in the role? What will they learn? And how will they fit into the overall company structure? Use “you” and active language to make it more real versus theoretical, as if they’re already performing the role. Leave them already feeling invested in the position, able to picture themselves on the team, and definitely excited. Do they need to send a portfolio, submit a GitHub account, or are just left thinking about what they need to “be prepared to…”, as that was provoked by your job description; these things have candidates consider what it takes to match their offering to yours. (The typical exception is ironically their resume.)
When talking about responsibilities is when most companies list out every single thing this person will possibly do. That’s not necessary. An overview will do and in many cases is better, as that provides the candidate with a picture, while a task list does not. There’s balance to be struck. To convey the purpose, there should be some inkling as to how this position will fit into the larger picture of the project, and overall company mission. What’s really needed isn’t your mile long wish list, it’s the brass tacks of what it takes to get the job done and what would make them shine/stand out. What are you offering candidates, be it in learning/advancement opportunity, benefits, or otherwise that should make your position/company more attractive than the competitor’s? If after reading your JD, a candidate shrugs their shoulders, still not knowing what you’re seeking or the real qualifications, because everything is so generalized, that’s a fail. That in a way means everyone and conversely, no one, is really qualified for the position. How helpful! (It’s also really frustrating for candidates, who feel like we didn’t bother to even tell them about the position, which we should do, at minimum.)
This webinar is focused on the Recruiting side of the house. Just a note on the HR aspects, though, because they are intertwined and cannot be ignored: JDs serve important HR purposes: defining company roles and job codes performance duties & expectations performance mgmt compliance - OFCCP + Basic & Preferred Qualifications – (BQs & PQs) immigration I don’t care if a candidate has 2 or 10 years of Java if what I’m seeking is a certain level of proficiency. I want good, not necessarily more experienced, and any good Recruiter knows, the two aren’t necessarily directly linked. That being said, BQs & PQs are expected to be objective and measurable, meaning you will need to express expectations of a more qualitative nature in your responsibilities section. This is where tone and presentation matter, as that can be done without diluting the message about what you really want, and while making the minimal expectations something to not immediately have your resume thrown out. It’s a delicate balance, especially depending on the strictness of your company’s HR QA dept. If you have 7 years of Java, are deep within certain layers, and want a role that’s robust and where you’re challenged, having a job that simply requires at least 2 years of experience, though without contextual information, won’t exactly inspire. The best approach is to have minimal qualifications that are the minimal. If you want a mid-level Java Engineer, for instance, and typically would define that as 5-7 years of Java development, for BQs I would likely go with at least 2 years experience and for the PQs, 4+ years. This would honor the letter of the law, as well as spirit. Sometimes expectations that are too low will detract more qualified talent, which is why I use the responsibilities section to tell them what I really want, and make sure my PQs are such that those who meet the requirements can apply, and those who exceed aren’t turned-off. A way to work within the PQ rules, (BQs are more rigid), is to list versus a general skill, instead a specific or advanced function within said skill more likely associated with those possessing more depth of knowledge. Example: Given it’s Open Source and I have access to YouTube, in theory, I could within a few days learn to code at least a few lines of Chef. Lots of people, given it’s the hot tech skill of the moment have some. Recently I wrote a PQ that asked for 2+ years’ creating recipes with Chef, and building cookbooks. A little context: a Chef recipe is all the code for a particular file, and a cookbook, all the files needed to perform a particular function. What I want is someone who is good in Chef, and has depth, but that can’t be necessarily translated into years of experience and the qualitative is not something for which I can ask in this section, as it’s subjective. This isn’t a “nice to have” for this position. The role has a heavy emphasis on configuration management and automation provisioning and for those things, we use Chef. The level of skill sought is genuinely needed. By asking for what I did and how I did it, hopefully I’ll get candidates with a greater depth to their Chef skills, and deter those who have only done a line or two of code, just to say they did. Most HR QA groups like it more general. I think it’s unfair to have people thinking they’re well qualified when in fact they’re not at all. I also fear the potential this has on explaining the dispositions, as so many who meet the requirements are then deemed unqualified before even a Recruiter screen. The BQs and PQs are also an important part of the immigration process. For example, if you require a Master’s degree in technology, you’re allowed to file Greencards under EB2, but if only preferred, with a Bachelor’s required, it’s typically EB3. This must apply to all candidates, not just those being sponsored. The Federal govt. uses the JD, which they expect accurately reflects the role’s duties and responsibilities, to assess our immigration filings, as to how we’ve coded our positions, which corresponds to the available filing options for the prospective employee. Errors and especially deceit in this area have potentially dire consequences. (I cannot stress this to the degree of its disastrous potential.) This isn’t even the tip of the government compliance ice-burg, the fullness of which would take up multiple webinars, and include employment & immigration attorneys, HR experts, and government representatives.
The best and brightest don’t define themselves by most of those job description bullets, a specific skill, programming languages (e.g., Java engineer), etc. Instead, they are forward-thinking problem solvers, who will use the right tool for the job. Job Descriptions, while they should be specific, unless absolutely necessary, like in the case of a needed skill or certification, should also leave some room for the right candidate to recognize themselves in how the mission is described and based on the purpose/real needs of the role, explore their candidacy. As important as it is to the group I support that we hire more people with strong Chef skills, someone who has good scripting, understands the full stack, has a good background with configuration management, and especially automation, who is a thinker, as in not someone who can just do it, but understands how all the pieces fit: that person would very much still pique our interest. So while you might be stressing something, without being general, do leave room for someone who isn’t on paper exactly what you’re seeking on paper.
we don’t just string together cool sounding words
The purpose of a well-crafted JD is to communicate the essence of both the role and ideal candidate. It’s just awesome when you can do that, creatively. Here at Capital One, with the Data Management team that also supports a lot of Big Data, we rewrote the job descriptions, creating a standard framework. Specific roles would need their respective expectations and qualifications added, though within the template of sorts. This was for many reasons, not the least of which, consistent branding. When this group opened several Mainframe positions, while we used the framework + appropriate bullets, from the framework we omitted a section that included fun and attractive things related to Big Data and innovation, like wanting someone who obsesses over Data, even having Nate Silver call them to see who will win the next election. While a great section, and appropriate to intro the group within these Mainframe Engineers will work, including that section is a mismatch to the role and likely candidate. Be realistic with your asks or only a Ninja will be a viable candidate, only something you want if recruiting Ninjas. I once kicked back a job requirement from my hiring team that in the BQs, no less, wanted at least 5 years of at least one of the following Open Source technologies: GIT, Nexus, Docker, or Rocket. Well… Rocket has been out less than a year, Docker since 2013, the company that makes Nexus started in 2009, and that leaves one that while as of the last few years, widely used, but until then, rarely found with any depth. I’m many things, not one of which is a Magician. And while not an HR expert, I’d imagine having a BQ that is nearly impossible and with some of the examples, actually impossible, is more than frowned upon. Managing your hiring manager’s expectations is good for many reasons, only one of which, a well-crafted job description. And besides, the JD isn’t meant to have a candidate laughing AT you! Also, while power descriptors are great, just don’t overuse them.
Telling a story and having candidates feel they are there, already in the role, has your JD stand out from others. The Director of Recruiting role at NPR for which I’m not well qualified, and the reality of which doesn’t particularly excite me, had a JD that sucked me in, as it engaged me by igniting all those things about this industry I love, having me imagine the culmination of which while onsite, listening to All Things Considered.
There’s a delicate balance between being overly general, overly specific with listing out things that aren’t necessary to mention, and striking the right mixture of accurately depicting the role and generating excitement with more colorful descriptors.
My appetite wasn’t even dampened, let alone wettened. What would have piqued my interest and elicited my response, or at very least curiosity, and a back-of-the-head note: Had she said that she was seeking a Lead Tech Recruiter for a medium-sized commercial software company with a start-up mentality, that’s super fast-paced and energetic, and I would take on the challenge of leading up a team of 5 tech recruiters, drive strategic/creative sourcing efforts, and needed to be adept at recruiting emerging technologies, as they have needs in Cloud, Mobile, Big Data, and Virtualization. Bonus Points: if she had mentioned my LI picture t-shirt!
Side Note: because it’s probably distracting some of you: apparently that is how you spell whet, in this case. Who knew? I’m not targeting all the fish in the sea, nor Nemo. Part of the balance is finding that school of fish most aligned with your qualifications, culture, offerings, etc.
How would you react if reading a job description for a Recruiter and told requirements include: using the ATS to review and disposition resumes, going to job fairs, submitting requisitions for approval, and a whole host of other mundane tasks I/we do in a day/week? Inevitably there’s going to be some function of the job that’s less appealing and the candidate doesn’t particularly want to do. It’s an entirely different story if the requirement is one not always associated with the role, like if it’s a Sales Engineer position that includes cold-calling. To not mention it and only those things that are exciting is tantamount to bait and switch, ironically also a sales tactic, but nonetheless. If the responsibility is normal and customary to the role and level, and especially those of a mundane nature, it’s best to leave them unsaid. When you think about it, if you list everything for every job, JDs would be 50 pages long.
Intakes allow you to better fully understand the opportunity and role’s responsibilities. Working together on team blurbs helps your client group refine their elevator pitch, deepens your understanding of their group in general and most importantly, target audience. Now with a skeleton JD from the hiring team, enhanced information from your intake, plus more understanding of the group, role, and how both fit into the larger ecosystem, the job description is much easier to finish writing… and market. Walk away not just better understanding the job’s responsibility and requirement bullet points, but more importantly, how to recognize, define, and proactively attract their target candidate audience! That makes for a more robust job description! (not to mention, recruiting lifecycle) Getting the client group involved makes them more invested and generates more and better referrals when team members can forward a JD that actually says something and of which they’re proud. We’ve all done the awkward laugh when apologizing to someone that the JD sucks. An engaged HM is now working with you towards shared goals. You’re on a mission, together. And once you have their buy-in, as their hiring experiences prove better with your guidance, you’ll have on your side an ambassador, soliciting the buy-in of their counterparts, using their own successes as evidence. That translates to much more than writing descriptions: it will strengthen the relationship and their trust and respect of you. One of my favorite responses: I don’t mean to create more work for you, but I don’t think this JD, as written, is very marketable. We will get too limited of a pool.
The same is true of a job description that uses a kitchen sink approach.
Being both inclusive and exclusive allows you to spend more time doing what matters, engaging top talent, providing clients exceptional service, and making awesome stuff happen. I don’t know about you, but spending copious amounts of time dispositioning unqualified candidates in the system isn’t where I’m able to make the most impact. Some JDs might as well just say, “must have a pulse”, which means lots of people who barely have one apply. Also keep in mind that too many requirements or being rigid means you’ll likely miss out on qualified candidates.
If that worked, anyone could do our job and professional recruiting is still very much alive and well, needed now perhaps more than ever.
These may seem random. …they’re not Rushed or non-existent intakes do not make for an informed Recruiter, who in turn is less able to convey the fullness of the opportunity, be it in the job description, or while speaking with candidates. An overly loose job description + indiscriminate posting = lots and lots of applicants …of the throw their resume against the wall variety Employee Engagement is a vital part of Talent Management and the job description, most often being the 1st impression a prospective candidate has of your opportunity and maybe even company is essentially pre-employment engagement. This is where they’re getting their first sense of who you are and how they might fit into your organization. A carefully crafted job description sets this in motion. When there’s too many applicants there’s less time to spend with the few, a greater likelihood there’s more time delays by the time we weed through the irrelevant to get to the qualified, and worse, a lessened chance we even attract the qualified, as they won’t see themselves in a role that’s been described using a bland cookie-cutter template. Having a targeted approach, both with the description and posting strategy + using a system like Silk Road that allows for automation in meaningful ways, as they’re defined by your needs, and applying the human aspect of recruiting means you spend less time on that which doesn’t deserve your attention, more time cultivating relationships and getting things done, more quickly, more efficiently, and in a way that can be replicated, as well as scaled. This is where tools matter. No tool takes the place of good recruiting, but with the right tools, good recruiting goes to great!
It should go without saying, but I’ll say it anyway: use proper grammar, pay attention to the underlined words, as that’s your spell-check giving you a warning, and maintain consistent formatting. Now this is obviously a more exaggerated example, though I have seem some doozies out there.
Just yesterday I finished writing a JD that included “Rocket”. No need to go down the rabbit hole, but Rocket is a container platform tool that’s been out less than a year, and taking the industry by storm. While we have Rocket, other things we’re more widely using. We’d love to hire someone with the skill, but having it included on the JD was actually more about letting people know we’re on the forefront, and that’s what those in the know will think when seeing that, and geeks very much care about that. And of course, we very much want to hire great geeks. Win-Win!
Speaking with team members will provide a better day-to-day picture, something we want to translate in our JDs. Also, their background will provide insights on how to weigh the need for certain skills and experiences. What’s a little internet stalking for a Recruiter? I suggest knowing some companies that regularly publish job openings matching your needs and style. What do they say, imitation is the highest form of flattery?
I use my job description writing process as a way of immersing myself with the company, group, project, and finally, specific role. It’s been especially beneficial given I’ve been contract recruiting for 8 years now. It’s my way of getting ramped up quickly. It’s so much more than writing one description! When I first started at MicroStrategy, I remember my Manager there, the best of my career, jokingly asking, but not, at the end of my first week, if I was going to get to recruiting some candidates soon. I was already assigned some roles, and spending a lot of time working on the JDs, both specific to those openings, and how to tackle the framework. It wasn’t long before she grew to really appreciate my process. Hiring Managers felt engaged and heard, and I certainly contributed to MicroStrategy’s central job descriptions database. And of course I got results! One of my accomplishments there was to put in place a repository and job description frameworks for a variety of roles. I consider it the gift that keeps on giving! An important thing I really learned there was to cultivate my relationship with HRBPs, and there I had two that were exceptional partners. Having those relationships reduced push-back on my more aggressive and less conservative approach. They knew and trusted me. They also knew if giving me instruction on how to comply with something, I would immediately, and fully. Also, getting to if non-technical and/or a more standard role, while the job might not be as sexy, the bullets don’t have to be boring. An AP analyst can certainly be meticulous about maintaining updated and accurate ledgers, for instance. And I would imagine the team blurb might include their mission: having industry best practice standards, being a line of defense in protecting the company’s bottom-line, providing an important service to the company, and alongside other driven professionals
I keep handy a repository of plug-n-play JD templates and bullets. The templates are more like frameworks, flexible ones, like with being edited for those Mainframe roles. My library includes full job descriptions previously written, named by title, as that can be more easily referenced later than the requisition number you’ll soon forget, templates that are well-aligned to various functions, and a repository of bullets I frequently use and can easily pull, both general, and within certain roles. That makes job description writing not only easier on me, but also for my hiring managers, which they appreciate. I use the bullets list to show them how we might go about writing up their needs, as in the approach to communicating those things. By already having a requisition framework, our time is spent honing in on 5-10 specific needs, and together creating their elevator pitch. While this doesn’t work in every environment, I ask my Hiring Managers to give me the basics of each category, team blurb, responsibilities, qualifications, etc. I then do the JD writing, as that’s my expertise, not theirs. After they give the nod to what I’ve created from their input, we go forward, having created something on which we’ve both worked, and in which we’re both invested, to reference and update. I’m certainly not rewriting each time I get assigned a new requisition and actually, it’s easy for me to go in and change a few lines. It’s plug-n-play. Since it’s continually improved and updated, once we put in the labor the 1st time, it’s simple thereafter.
(use the arrow function to point to that section) In the “after”, something to note is the mention of the game rooms and open facilities. It’s a window to the culture without needing to list out the benefits. It’s also more energetic, making the right type of candidate get excited as they read, even picturing themselves in those collaborative spaces, solving complex challenges with other passionate engineers. There’s a CALL TO ACTION!
After rewriting this JD for my HM while at SYMC, he said, “I’d apply for that”, and to which I replied, that’s the point.
Much like when cover letters were more standard, it was said that the cover letter led to someone reviewing your resume and your resume to the interview, the title is often the first and only thing a candidate sees unless they click to open the full description. They shouldn’t have to guess or not realize that’s the role for which they’re looking. I doubt you wrote this compelling job description just for kicks. You want it found by the right candidates and while it’s just as annoying in job descriptions for them to be nothing more than buzz words as it is when candidates do that in their resume, using industry keywords drastically increases the likelihood your opportunity is found, not to mention, understood. This week Apple announced they’ve surpassed their 700 millionth iPhone sale. While it could take a whole other webinar to cover this topic, I’d be remiss to not mention the impact this should have on our job descriptions. More and more, people are doing everything, including their LI networking and job search from their phone. This means embracing job description writing that packs a greater punch with shorter descriptions, much lighter on prose. (The mobile revolution is also one of the MANY reasons I don’t recommend sending full job descriptions with an initial LI outreach. Well… the mobile factor + that whole it’s work and not Six Flags thing.)
(use the arrow function to point to that section/specific lines) Trust me, if you’re a Cloud Engineer, getting to “champion” this platform is seriously cool stuff! And please notice the group specific intro. No one cares that Capital One is a top 10 bank, and Fortune #124, so I left it out. And if I need a Java person to work in Cloud, or even surrounding it, like in DevOps, this only needs tweaking, not a complete rewrite. Instead of describing a function of PaaS or IaaS, for instance, this encapsulates the Cloud mission, which engages and excites, versus just describes.
(use the arrow function to point to that section/referenced lines) In this example, which is from a job description I wrote just this week, there’s things specific to the role’s requirements, some generally function related, and others that are of a general nature. Taken From My Central Cloud Department and Automation Bullets Repository: (things I could only know because I intimately know this group) “Automate the provisioning of environments pulling strings with Puppet, cooking up some recipes with Chef, or through Ansible, and the deployment of those environments using containers, like Docker or Rocket: (and for the love of automation, at least have some configuration management tool, through some version control)” I don’t need to think to write that again next time I’m working on a Cloud or DevOps role. All I’ll need is to verify if that role also utilizes Puppet and Chef. Taken From My Central Software Positions Bullets Repository: “develop scripts and glue code to integrate multiple software components” That’s something nearly all software positions can use. Taken from My Central General Bullets Repository: “Strong verbal and written communication skills due to the dynamic nature of collaborations with customers, vendors, and other engineering, solving complex business problems together” This is a one I use on virtually all my job descriptions. Searching for it would uncover JDs written in whole or at least in part by me, unless of course someone else out there used their research skills to find and also use it. (I wouldn’t blame them.) And here’s a funny, given my current contract is with Capital One: that last bullet, as it was first written when I was with PayPal, after “looking to punch a clock”, said, “try a bank”. …And out of fairness to Capital One, they are doing some really exciting and innovative work. They aren’t hiring clock-punchers, either!
(use the arrow function to point to that section/specific lines) And I feel the need to qualify here that this newly created JD, at the request of the VP of Cloud, merges 3 overlapping profiles: Cloud Developer, IaaS & PaaS. The result did encapsulate, though is lengthier than I typically like. It’s 1.5 pages on MS Word, whereas I prefer 1 page. I can stand to be less wordy, though have found, that candidates do read through my descriptions fully, as at least my JDs are entertaining. They are also informative. If you’re a Cloud Engineer, that can mean a lot of things. Knowing we use Puppet and Chef, and that we’re hyper-focused on automation, for instance, is telling. Seeing that we prefer someone who has migrated infrastructure to Cloud + all the cool and catchy stuff both allows qualified candidates to understand the mission and picture themselves accepting that mission, working onsite, alongside other techies. “Serious geek street cred if you have a robust portfolio on GitHub and/or Open Source contributions of which you are proud to share!” This bullet actually says much more. GitHub, for our non-Technical Recruiters, is a networking site of sorts for Software Engineers. It’s focused on Open Source technologies, and where techies can ask questions, join forums, share code, and collaborate. I’m more drawn to resumes that include a GitHub account address, typically found next to the link to their LI profile. It shows they’re keeping up, passionate, and the kind of geek with whom I want to speak. It’s so powerful it nearly renders their resume irrelevant and if your HM is also a geek, they’ll stop reading the resume and instead click to review the candidate’s GitHub contributions. I strongly suggest you find your role’s GitHub equivalency! Is there a particular more advanced skill that tells you the candidate likely possesses a greater depth in what you need? Maybe it’s a certification that’s telling, experience with a certain company, or coming out of a particular university program. This helps you not only more easily identify those most attractive for the role, but for the candidates, the same, as it tells them about your culture, direction, and more about with whom they might work. …birds of a feather This job description got some final tweaks late last night, all done on-the-fly, while IMing with the Hiring Manager. As with most all things, synergy really plays a key role. This particular write came about, as I said, from a merging of other descriptions. It left me feeling a bit worried that while a good job description on paper, (I suppose literally), was it good in that it did its job? I asked him an important question I encourage you to ask of your hiring teams: does this description not only capture the brass tacks of what you need, but also the essence of what you really seek? After an affirmative answer, I also asked if there was something, that while not a deterrent or bad to have, that just isn’t relevant to his needs, making the inclusion of it distracting. No kitchen sinks here!
(use the arrow function to point to that section/specific lines) In contrast to what we just saw: This JD, written by a friend and former PayPal peer of mine, Nick Peddy, who now runs technology for the Happy Home Company, recently ranked one of San Francisco’s top 25 up-and-coming start-ups, highlights matching the style with the environment. While it includes drastically less written information, this description says a lot. The right type of candidate for this role understands the unsaid, and while this doesn’t tell them the project, it creates a pretty clear picture of the culture. And I’d imagine requiring people apply through that method drastically reduces the applicant pool, and discourages those who aren’t up for the challenge. This is somewhat elitist and maybe intimidating, an approach personally of which I approve! (…And that sentiment highlights why I identify as Talent Acquisition, not HR.) This style isn’t right for a larger or more structured organization, though again, know and speak from your voice. In this case, I can actually hear Nick speaking. Oh. And funny, while I don’t think most of the HR folks on the call would approve, the last bullet point, on the HHC’s website, is written out. That’s something I’ve seen from a lot of start-ups lately.
Making your job descriptions visually appealing involves much more than having paid attention in 9th grade English. Keep the packaging in mind. You’ll lose a candidate’s interest if too long, especially if prose. Many/most won’t read fully and that means your initial outreach to them has a reduced impact. I’m guilty of excessive bullets sometimes and need to watch that. It can feel overwhelming to a candidate, or even rigid/stodgy. When in need of many bullets, one solution is to break up into categories. I’ve used: responsibilities and expectations + in this role you’ll get to learn about + it would be great if you also had… + about you (where I use the catchy stuff) Oh, and I know the Production DBA will need to maintain the servers, so I assure you, so does a DBA applying for that role. It’s not worth the bullet!
ERE Job Descriptions Presentation - John Greer
The Art of MakingThe Art of Making
Job Descriptions Work for YouJob Descriptions Work for You
NW PDX Consulting
The Magic FormulaThe Magic Formula
Be Engaging + Be Compelling +
1. Attract the targeted audience
2. Tap into a candidate’s sense of
3. Use power descriptors!
4. Pique interest, plant a seed, and let
5. Paint a compelling day-to-day
7. Call to action
As the name Job Description does and should imply, it’s
meant to DESCRIBE the position!
In addition to communicating the necessary requirements, a
well-crafted Job Description should answer the following
What are the day-to-day responsibilities?
What is the purpose of this role? (think IMPACT)
What skills and experience are really needed?
Why should a prospective candidate work with your
Maybe even, what will they learn?
Job Descriptions serve practical and strategic purposes,
internally and externally.
It’s all fun and games until the OFCCP audit!
Just like a resume doesn’t encapsulate all of
the candidate, the job description doesn’t tell
the whole story about the opportunity.
Sure, it’s cool you want a super awesome AP Analyst with
ninja like payments skills, who rocks Excel better than
Superman flies and codes invoices like a boss, but what
does that even mean? And if you know what it means, does
the tone really match that of the role, department,
environment, or what would likely attract the ideal
Unless you’re Google,
don’t try and be
The result is awkward,
worse, a failure to
convey what you
uniquely bring to the
Strive for consistent messaging without a one size fits
Crafting a job description isn’t just an exercise in creating
Know and speak to your audience
Unless you’re actually hiring a Ninja, it’s highly unlikely
everything your job requires does so at Ninja level
Facts Tell, Stories Sell!
It’s not about a list of bullets. It’s a picture you’re creating of
the contribution they have an opportunity to make and what
they’ll experience along the way.
Job Description Writing
Less Isn’t Always More…
Recently, a Recruiter from apparently what should be
named, Boring Inc., reached out on LinkedIn and
asked if I was interested in a Recruiter role in
Virginia. (end of message)
The solution for appetites/thirsts that haven’t been made
is not watering down my whiskey
Leave your laundry (list) at home!
Pick and Choose!
That’s why they call it work, and not Six Flags!
You’ve been assigned a new position, maybe
with a new client group or Hiring Manager and
want to know where to start…
My suggestion… at the beginning, which is the
Refining along the
way is very different
from using a throw
it against the wall
Be Inclusive & Exclusive!
A well crafted job posting should be to attract and engage the
right talent, and discourage the wrong ones from applying. It
should be inclusive enough to appeal to the targeted
audience, yet exclusive enough to discourage irrelevant
candidates from applying for a role for which they aren’t
Part of a targeted recruiting
strategy, in combination
with writing a well-crafted
job description, is to have a
marketing and posting plan
that doesn’t include the
cardinal sin of the “post-
The Right Tools + REAL RECRUITING = TA Excellence
A recipe for bland job descriptions
It’s not the size of the applicant pool, but the quality of the
engaged candidates that matters
Beware Black Holes
Recruiters aren’t automatable
Strike the balance between automation and humanity
If you don’t think this guy’s LI
profile says anything…
Don’t just talk,
We’re seeking the best
employee to do important
things at a great company,
who will use their vast
experience to benefit the
mission by making an impact
and being awesome.
◦ Work within an agile software
engineering team to create software
software development includes: back-
end & front-end, database
development, UX design, REST APIs.
You will perform automation of
development, buld, and testing
Must have good attention to
Great Job Descriptions are a
Create a sense of urgency
Show you’ve got exciting stuff
going on, note innovative
projects, or highlight sexy
technologies that would attract
the type of geek you seek
Send the message your
company is growing and has
great opportunities, so check
At Little Research Goes a Long Way:
Use a focus group to test a sampling
Pull job descriptions from similar roles
“Interview” recent hires & team Rock Stars
Share the job description with people currently in that role:
Does this depict the position accurately?
Based on this JD, would they apply?
Now I know what you’re thinking…
What if my positions are non-technical?
What if my positions are non-technical and more straight-forward
in nature, like an AP Analyst?
This is all well and good in theory, but I need to do more in a day
than write and rewrite job descriptions. Is that all you do?
Do you have to rewrite every job description, every time?
Relentlessly protect the world’s information. Make
a difference at Symantec. Across the globe, we
are an ‘essential’ partner to both consumers and
businesses of all sizes. We combine our talents,
our brains, and our creative energy to reinforce
our place as a world-class technical community.
In the Norton™ Engineering team you will
develop products that will fight cybercrime
worldwide and protects our customers' data and
identities by developing innovative new Norton
products and services that quickly detect and
eliminate both current and emerging threats.
We at Symantec pride ourselves on taking an
energetic and forward thinking approach to problem
solving, so forward that we work to provide
solutions to problems that will now never be
because of our forward-thinking. We enable a team-
oriented atmosphere for the rapid development of
cutting edge mobile security software products. Our
teams operate in a global mode, enabling more idea
sharing and better solutions. Our modern, open, and
technology-centered facilities (game rooms, and
collaborate spaces) help release the creativity of our
team members and the catered lunches and regular
on/off site team building events create a culture of
Symantec seeks a technology-passionate mobile
software engineer, iOS or Android. Our solutions
need to be scalable and robust, as well as simple
and easy for our end users. In that context, you will
be expected to research and develop cutting edge
technologies. We look for individuals with the ability
to think and act quickly and collaborate in small,
agile teams, while believing in code ownership and
pride in a job well done. If you have a flair for
creative problem solving, innovative skills, and
delivering superior quality mobile applications, read
further to learn about your mission, applying, only if
you choose to accept the challenge.
5+ years of industry experience
Objective C or iOS Development
Experience with 3rd party libraries and APIs
Understanding of the full mobile development
Those who have written their own iOS apps
Past experience developing in Mobile strongly
Computer Science or equivalent degree
If there is no App for that, help Norton be the first to deliver it
to the world. If there is, make sure the best one on the
market comes from Norton
Work alongside highly skilled and experienced engineers to
tackle some of the most challenging problems, taking lead on
a major feature of the Mobile product line. Innovators get to
experience ownership here
Research and suggest implementation of new technologies.
We’re on the cutting edge and plan on keeping it that way!
If you have not figured it out yet, we’re running fast and hard.
Come here and expect to get awesome things done!!
At least 2 years in mobile development (built more than just a
flashlight on your phone)
Strong proficiency in Java and/or Objective-C, object oriented
design and mobile technologies
Ideally you have contributed to an Open Source project and
can point to your GitHub repository with pride
You know what continuous integration means, and believe
automated testing is the path to happiness, and when you
need to use manual, it’s for the sake of quality
Someone who thrives under pressure, is passionate about
their craft, and hyper-focused on delivering excellence
Strong verbal and written communication skills are a must
due to the dynamic nature of discussions with other
engineering and product teams
We’re looking for self-starters, those who can work
independently, as well as with and across teams. Extra points
if you can drive the process, and have a deep understanding
of architecture and design
BS/BA degree in Computer Science or equivalent experience
A Few More Pointers:
Refrain from using internal lingo/acronyms
Use specific, though standard titles, (Oracle DBA instead of
generic Database Administrator or Ninja Database Dude)
Adjust for the mobile revolution
Geek. Nerd. Tech-Junkie. They’re all pet-names to us. If you share our passion for all
things technology, and are up for the challenge, come dare to dream, disrupt, and deliver!
Developing cutting-edge Cloud technology takes the culmination and collaboration of
bright, innovative, and talented people, along with forward-thinking leadership. We nurture
an environment where people with a variety of thoughts, ideas and backgrounds, all
guided by our Shared Values, come together to learn why Capital One is among the “100
Best Companies to Work For.”
We are seeking highly creative and intellectually curious Cloud Engineers, at all levels,
who are passionate about cutting-edge distributed computing. As part of a team that’s
leading the next wave of disruption on a whole new scale, you will play an integral part in
advancing Capital One’s Cloud eco-system and culture of technical excellence. You will
champion the Cloud Management Platform (CMP), live and breathe Infrastructure
Automation, support Hybrid Cloud Solutions, and display a strong understanding of Cloud-
as-a-Service varieties: PaaS, IaaS, and SaaS. Creating the next generation of network-
centric Cloud architectures, you will make a key contribution supporting end-to-end public
Cloud Automation of application delivery, including Infrastructure provisioning and
integration with Continuous Integration/Continuous Development (CI/CD) platforms, using
existing and emerging technologies. The ideal candidate will have experience moving
infrastructure to the Cloud!
Responsibilities & Expectations:
Stealthily plan and lead the deployment of the cloud solution in a production environment
Use your winning personality to influence broader Engineering groups in adopting Cloud technologies and
Develop scripts and glue code to integrate multiple software components
Automate the provisioning of environments pulling strings with Puppet, cooking up some recipes with
Chef, or through Ansible, and the deployment of those environments using containers, like Docker or
Rocket: (and for the love of automation, at least have some configuration management tool, through
some version control)
Design and develop automation workflows, performing unit tests and conducting reviews to make sure
your work is rigorously designed, elegantly coded, and effectively tuned for platform performance, and
assessing the overall quality of delivered components
Strong verbal and written communication skills due to the dynamic nature of collaborations with
customers, vendors, and other engineering, solving complex business problems together
Evaluate & build different compute frameworks for all tiers and while you don’t have to scale buildings,
implementing scalable systems solutions is required
We’re looking for self-starters, those who can work independently, with and across teams. Establishing
smooth running environments is paramount to your success, and happiness
Serious bonus points awarded for experience migrating on-site solutions to cloud based offerings, such as
If you have not figured out yet this place is really running fast and hard. Looking to punch a clock? Turn
back. Come here and expect to get things done!!
Serious geek street cred if you have a robust portfolio on GitHub and/or Open Source contributions of
which you are proud to share!
You’re fungible, and for that matter, fun!
Discerning. You have a strong familiarity with a combination of the following: VMWare, KVM, OpenStack,
CloudStack, Amazon, RightScale and various Cloud abstraction layers, and understand the importance of
selecting the right technology tool for the task
Insatiably Curious. You ask why, you explore, you're not afraid to blurt out your crazy idea. You can work
at a tiny crack until you've broken open the whole nut
Automator. You know what continuous integration means and believe automation is the path to
happiness, knowing how to script/automate everything, from tests to environment provisioning
Do-er. You’re biased towards action. Expect to tell us what you’ve shipped and what’s flopped
You’re not intimated by challenges, even thriving in an unstructured environment where you’re
empowered to make a difference. In that context, you will be expected to research and develop cutting-
edge technologies, to accomplish your mission, should you choose to accept
You love learning new technologies and mentoring more junior engineers
While a cape is optional, the uniform we’re seeking is someone super passionate about their craft,
particularly all things Cloud and hyper-focused on delivering world-class solutions on an aggressive
schedule. Is this you? If this is your version of a cape, continue to apply
Bachelor’s Degree in Information Systems, Computer Science, or Engineering; Master’s Degree Preferred
5+ years’ with OOP concepts and scripting languages, (Python, Ruby, Perl), and frameworks (RAILS)
3+ years’ creating recipes with Chef, building cookbooks
3+ years’ using cloud based hosting solutions (AWS-EC2/S3, Azure, Google Cloud)
3+ years’ with automation tools for server provisioning and Open Source tools
3+ years’ developing automation workflows and routines, using Open Source Tools (Chef, Puppet,
Hudson), or Vendor Based Tools (HPSA/OO, vCAC, uDeploy)
3+ years’ with large-scale software implementation (high transaction volume, high-availability concepts)
2+ years with Linux, server automation and scripting
We are looking for a Swiss-army-knife Full Stack Software Engineer to join our talented engineering
in any or all of these areas is a strong plus... but not an absolute requirement. The only
absolute requirement is a solid grasp of good software engineering principles and best practices, and a
willingness, nay burning desire, to learn new things. If you understand the difference between a
programmer and an engineer, we're speaking to you. We are a small, experienced team and everyone who
works here has to be at the top of their game. The person we're looking for:
has a sense of intellectual curiosity and desire to learn
is self-driven, actively looks for ways to add value, and knows how to get things done
values data and truth over ego
has a strong sense of code craftsmanship, takes pride in the code they write
sometimes spends more time on the unit tests than the actual application code
has good verbal communication and reasoning skills, including the ability to make a business case for
is not an a**hole
How to Apply:
Write us an email convincing us why you might be a good fit, with a link to your LinkedIn and GitHub
profiles (or other examples of past work). Part of our interview process is looking at your actual code, so
show us what you're proud of and be prepared to talk about what you've learned from it. Emails with
attachments get auto-filtered to the trash.
This is an intermediate to senior-level position. It is a permanent and full-time, beginning as soon as we
find the right person. You will work on-site in San Jose, California.
And a Few More Pointers:
Combine prose & bullets
Be mindful of length – especially with prose
It’s not a contest to see how many bullets you can make fit
Thanks, Captain Obvious!
If they’re bored reading the job description, just
imagine how they might imagine themselves actually
performing the job!