Hiring process part 1 · job posting
When I worked as a freelancer, one of the tasks I did was to help companies hiring talented people. Aside the case of Melusyn startup, I was mostly handling the technical interviews with the candidates, and gave my advice to the company: this candidate clearly lacks knowledge, while this one may have an interesting profile and should learn fast. Obviously, most small or medium-size companies don't have skillful personal who can handle an interview, ask tricky questions, and not being tricked by ignorance disguised as cleverness. With my help, those companies could ensure that they are not hiring quacks, but only people who actually know the stuff they are talking about.
Unfortunately, those same companies rarely handled correctly the remaining parts of the hiring process. Often, they didn't know how and where to search for talented people, nor would they know how to interest the people they found. This caused an issue: when candidates arrived at the stage where I had to interview them about their technical skills, nearly all of them were unskilled, inefficient programmers who knew nothing about programming or development in general, and not much about the language they used for ten years.
The series of articles I start now is intended to help those companies understanding the problems they can encounter during the search for candidates, and the solutions that may exist.
Since I'm often blamed to be too theoretical in my articles, this series will be based exclusively on real-life examples. Mostly bad ones, to see what one shouldn't do, but also good ones, to serve as example.
Originally, I wanted to start the series by the very first thing which leads to a search for candidates: the need. But, again, this would be too theoretical, so instead of writing a whole article on that, let me just shortly explain what is it about before I focus on job postings.
The genesis of a position
Before you (CEO/human resources manager) can tell yourself that there is a position available in your company, there should be a need. It is crucial to make the need explicit. This is not yet about money and opportunity: this is about the actual issue you're encountering: the need.
There are diverse needs which might lead to a position. The “we have some money so we can hire somebody” approach, for example, is not based on a need, and will often lead to failure. You don't hire somebody because you can; you hire him because you crucially need him.
Let's consider a few potential needs.
The team is not developing the product fast enough. Yeah. That's right. Now forget about hiring, read The Mythical Man Month and learn the basics of project management. In most cases—and in every case I had to study, I repeat: every—adding a person in the middle of the project is not a solution and would inevitably slow things down.
The team doesn't have a specialist in ADO.NET/profiling/Unix administration/whatsoever. This is called adaptability: the developers you have right now are expected to learn things in order to respond to the new needs of the company. If they don't, either they are amateurs or, more frequently, you don't let them learn things.
We have a difficulty such as an extreme number of bugs in our code, and nobody knows how to deal with it; hiring somebody more skillful can solve the problem. Now think about it twice: you're hiring somebody to solve a problem. Once it is solved, would the person be fired? If yes, this is not really hiring. If no, it means that the person will be hired based on the requirements which will not be valid three months later. When you're in a situation like that, often the solution is to get a consultant (I'm available, by the way).
We are starting a new project and training our current personal and freeing them from their respective tasks will be too overwhelming. Now that's an actual need which may lead to a position, except one problem: teams are built based on their complementary skills, their interpersonal relations and their feel of being a part of a team. A bunch of people hired a week ago might cohere into a team, or may remain a bunch of people working on the same project.
We are starting a new project, so our personnel joining the project (and leaving their previous projects) should be replaced by new people we will hire now. Right, kill all other projects (the ones which bring you money) simply because you're believing that you've found the new big thing to work on.
We are looking long-term for experts for our future projects. Hm, you're really hiring somebody right now to participate to a project which might start in two years?
As you can see, all those needs are problematic. My point is not that you should never hire, but that the decision to hire is much more complex than a bunch of strict rules. But the fact that the decision is complex doesn't mean that the need is as well.
The benefit of making the need explicit is to be able to consider alternatives. It's not “I hire a developer because I need a guy with strong database skills.”, but “I need a developer with strong database skills on this Java project, therefore I can either hire someone, or reassign Jeff on this project or ask temporary help to a freelancer Mary talked me about a week ago. Or I can mitigate the problem by not using the advanced database features, which will slow the project by one to two months.”
An additional benefit is that even if you finally chose to hire somebody among other alternatives, you will be able to write a job posting more easily, because you know exactly why do you need to hire a person. Many people don't know what they need, and so they write lame job postings.
Writing a job posting
My view on the subject is rather radical. Unless you're an extremely attractive company for talented people, such as FogCreek, Valve or Facebook, you don't have to write a job posting. At all. Don't waste your time. Talented people won't read it.
It's simple to illustrate through a story.
Fred is the best IT specialist/Unix guru in the city—a sort of a guy any company wants to have. Fred has a job at ThisCompanySucks Inc.—a multinational corporation which has a lot of money, but not a lot of respect for their most valuable professionals.
For example, Fred just had an argument with his manager: he tried to explain to the manager some technical aspects which should be done on infrastructure level before switching the new servers to production, but this manager never listens; “the servers should be up and running tomorrow evening”—he shouted before slamming the door.
Such situations became too frequent to push Fred to search for a new job. So he visits the website of Blizzard, because he enjoys the spirit in this company and knows that they have a subsidiary in the neighbour town. Fred doesn't find anything corresponding to his profile, so he takes a look at a few websites of large software vendors and large scientific organizations. Nothing there either. Once the work day is finished, Fred goes to a bar with his friends and asks them if they know about any position. One suggests a small company: his sister works in this company as an accountant, and she heard their system administrator is leaving in two months.
The next day, Fred calls this company. The CEO is clear: the company wouldn't be able to pay the same salary as Fred has at his current job, but they would make him the only person who takes technical decisions related to infrastructure. Two months later, Fred leaves his current job for this new opportunity.
Most professionals act the same way. They have in mind three-four companies they want to work for, but they won't go look at job postings of your company, because this company is not the one they dream of. On the other hand, “the person who knows someone who knows this talented guy”-style chains work well and this is the thing you should capitalize on. This means that:
You should be particularly open about future vacancies. Edith, the front-end developer, will be on parental leave for four months? Make sure everybody in your company knows that: DBAs, accountants, even the guy who changes the light bulbs. Make sure your partners know that. Make sure the front-end developers of your competitors know that. If your competitor has a manager who shouts on front-end developers or if the guy who changes the light bulbs knows a person whose brother is passionate about JavaScript and CSS 3 and all this stuff, you may be sure that they will come to you.
It seems so obvious, but nevertheless, some companies just don't understand that. At my last workplace, I was actually ordered to never discuss with anyone (including the members of my team) the fact that I will leave the company. That's the wrong way to capitalize on social capacity to find people to hire.
You should be proactive. Since you don't need to write a job posting, you may focus on the actual thing that matter: searching for people, instead of waiting for them to come. Be proactive with people around you. Walk to the opposite part of the office to talk with Tim, the DBA, because you recall Tim talking about a guy he's chating online and who is skillful in front-end development. Contact the young lady who gave you her business card at PyCon two years ago: she probably have found a job since then, but what if she doesn't enjoy it or has a colleague who wants to leave?
Most CEOs are not proactive when it comes to finding talented people. Surprisingly, they can be full of energy when discussing a business opportunity or talking with a potential customer, but isn't hiring the best people you can much more important than selling a copy of your software product to an additional customer?
— But wait, we still need a job posting to formalize the fact that we are searching for a person!—interrupts a CEO from the audience.
— Unless you're in public sector, you don't. You can't formalize a person. Are you worried about accounting? They don't care until you hire the person. Are you worried about being clear about the profile you're looking for?
— Exactly, I don't want misunderstandings between me and the potential candidates, and the social chains increase the risk of misunderstanding.
— OK, now we got somewhere. You need a job posting to make things clear. What would you include in the job posting, i.e. what exactly should you render clear and explicit?
— The technologies the person should know.
— You certainly don't want to do that. Because you actually want to hire Fred, the Unix guru, even if your servers are under Windows. Simply because Fred will spend a few weeks learning some subtlety of Windows and be nearly operational meanwhile, while Joe—the opposite of Fred, already knows how to administer Windows machines, but will be stuck for months when you'll need configure your switches to support LACP.
— Well, if I need a Java developer, why would I interview someone who worked exclusively with .NET?
— Because this .NET guy has already the knowledge you need—a knowledge of developing large-scale applications, a knowledge of writing reliable code, a knowledge of working in a team, a knowledge of understanding the requirements and the business rules. Learning a programming language is nothing compared to the path required for a programmer to become a developer. This .NET guy is unable to explain the difference between checked and unchecked exceptions? I couldn't care less. He encounters the term “checked exception”, Googles it, reads an article, and voilà, five minutes later he knows the difference. But when the Java programmer doesn't understand why does it matter to have a common code style or when he takes every code review too personally, there is nothing he can Google.
— In my experience, programmers tend to learn new languages much more painfully than that, and it certainly takes longer than a few weeks to become skillful in Java.
— Programmers, maybe. But I'm talking about developers, and specifically about talented people. They already know a few languages, and learning an additional one is not as difficult as it looks like. Personally, I hardly have an excellent level in programming languages, but it took me a few weeks to be productive in Python enough to be able to work on a large-scale project. Given that I work alone, with no code reviews, so I may miss a few things. A person well-integrated in a team will not have this drawback I have. After 7 years of .NET, Microsoft SQL and Windows, I suddenly switched to Node.js, Python, MongoDB, Redis and Linux. Was it scary? Totally. Was it worth it? Completely. You see, a few weeks later, I was already writing production code, the one which is tested and refactored.
— Ok, what about the actual job title? If I'm looking for a DBA, I don't need candidates who are just developers, right?
— Let's talk about job titles. Many don't make any sense. They are invented by people from HR who know nothing about IT, and they are only useful for people from HR. I don't understand many of the titles, simply because they have no meaning. They talk about DevOps expert when they actually search for a system administrator. My last job was called “Analyst-programmer in R&D department”: what I actually did was coding. A monkey could do half of the stuff I did. Any undergrad intern could do the remaining work. But let's imagine you're great at inventing job titles, and you do it right, with the right terms, and everybody magically knows the actual meaning of those terms. You do the same for criteria. Would this help? I don't think so. You're searching for people, not machines. When I want to buy a new camera, I may indicate that I need a DSLR (job title) which can shot 4K movies at 25 fps (criteria). I don't need a mirrorless camera: I need a DSLR. I don't need a camera which can't shot 4K movies or which shots 4K movies at a maximum of 24 fps. I simply don't. When it comes to people, the same approach doesn't work. You may want to hire a front-end developer who is particularly skillful in CSS 3, but then, during an interview with Stephen, you understand that he may lack some skills in CSS 3, but gosh, he's an excellent team player and knows so much of JavaScript stuff that you would be foolish not to hire him. This is also a problem with most hiring websites. They like categories, tags, classification, filters, keywords. But techniques which work well on an e-commerce website don't work when the product is a human being. This is also a problem of dating sites. I can do a search for a brunette aged from 24 to 26 who likes photography and doesn't smoke, but would it mean that I will never ever fall in love with a fat neighbor girl who hates photographers, smokes and enjoys gazing at stars sitting on the roof of her house at night?
— So if I get you right, technical aspects don't matter?
— Not that they don't matter. You won't interview a DBA for a job of a front-end developer, and you won't interview a programmer who spent all his life developing video games in C for a job of a business analyst. But you don't need a formal job posting for this sort of information. If your accountant tells her sister that you're looking for a DBA, her sister knows that her JavaScript skills won't help getting this specific position in your company. Even in an event of a mistake, this is not too serious. Actually, seeing a person for a wrong job can even give you some ideas. The person may even know somebody who corresponds much better to your needs.
— What about the non-technical skills? Wouldn't it be useful to put non-technical skills on a job posting? You told about Stephen who is an excellent team player. What about a job posting which specifies that you need somebody who is able to work in a team?
— This is probably the most useless part of job postings. Candidates should be motivated, be able to work in a team, be professional, be productive, bla bla bla. This is just boring. Of course I'm not motivated, I am unable to work in a team (as well as to work alone), I hate my job and IT in general, I hate talking to people, I can't stand receiving orders and I also can't take responsibilities, I'm unable to be organized, I'm always late at work, please, please, would you hire me? Never put in a job postings things which are too difficult for a candidate to say no to. “Are you motivated?”—“No, I'm not.” “Are you ready to learn new things?”—“What?! I hate learning!”
— So you'll never write any job posting?
— I will. But with a different goal.
The real goals of a job posting
The actual goals of a job posting are:
To catch those people who are not the friends of the friends of the guy who changes light bulbs at your company,
To present yourself, your company and the context.
The second goal is actually the most important one. I mentioned the first one, but I'm not convinced that you get a lot of candidates this way. On the other hand, you get a lot of people who you don't want to hire. If you get too much requests that your RH department is overwhelmed, they may not be able to answer to everyone, and this can lead to a negative image of your company (and depress the desperate candidates as well).
Let's focus on the second goal. When people are reading the job posting, they want to know:
Who are they talking to (if they contact you). Talking to a secretary from human resources is one thing: most developers with a bit of self-respect won't bother responding to a job posting like that. Not only they don't need to be evaluated by someone with no technical skills, but they also don't want to work in a company where people are hired this way. Remember, talented persons want to work with other talented people.
What is your company, and by that, I don't mean what's your business about, but what is the spirit of the workplace. In other words, I don't care if you're developing a post-production software product or a bunch of products for the inventory management of small shops, but I do care if you're a startup hiring 19 years old hackers or a corporation where developers should wear ties or a company working with cutting edge technology and trying to ship code as flawless as possible.
This will determine who, among the developers, will contact you. For example, I would hardly contact a hacker-oriented startup—not because I have something against this type of companies, but simply because I'm not the style of developer they are looking for. I won't glue StarWars posters in my office, and I won't wear a t-shirt at work, just because I don't want to; this means that it's not a good work place for me, because I will have difficulties integrating the team. Those environments are not attractive to women either. On the other hand, a talented hacker who is able to build in one night something on which I'll spend weeks will not be attracted by a company which puts focus on its enterprisy professional look, does code reviews of all committed code, enforces style rules on commits and asks their developers to wear ties. There is no right or wrong. It's just a matter of style and a matter of taste.
What is the context, i.e. why are you looking for a developer now, while you weren't looking for a developer two months ago. This is strongly related to the need—the one I was talking about in the introduction. Are you looking for somebody for your new project? Or maybe somebody to maintain an existent one? Are you building a new infrastructure? Or expanding to the new offices?
This not only determines who will reply, but also how. For example, if the job posting simply says that a company is looking for a C# developer, I may apply as a C# developer, giving the details about my experience with .NET. If, on the other hand, the job posting explains that the company is currently migrating their PHP product to .NET, I'll focus on projects I've successfully migrated from PHP to C# at the past, on my professional experience in porting and rewriting code bases, on my capacity to take technical decisions, train developers, etc. Now, it appears that I'm not just another C# developer, but a person who can bring a lot to the company: technical advisory, training, prior experience. If the job posting explains that the company starts a new project, I can focus on my skills as a team leader, my ability to set up the underlying infrastructure or to be part of requirements gathering (as a person who actually knows the difference between a functional and a non-functional requirement), etc.
This is essentially the key to successful job posting, the one which will attract the persons you want in your company instead of scaring them away.
Once you understand that, it makes it funny to read the actual job postings written by average secretaries with no technical background (and no writing skills as well) for average companies. Let's study one of such postings: Sogia Système, Bordeaux, is currently looking for a project manager. It's in French, but I'll attempt to translate it.
Example 1
Title: PROJECT MANAGER
Starting by shouting at people is not a good way to introduce the job posting. Is there any reason to use all capitals?
Description:
project Manager
5 years education
successful experience of 3 to 5 years as person in charge of application.
reporting tools such as OBIEE.
third-party referencial " Links ".
tree customers.
CRM customers.
Ensure the daily monitoring of those applications :
Escalate issues with their business impact.
Participate in the preparation and project or streering committees, escalate process or applicative improvements justified by a business ROI.
Perform the cleaning and enrichment of databases.
Provide user support.
Document and perform the necessary procedures.
Create reportings around the customer/tree, support the customer information center, especially for marketing.
Ensure a permanent technological monitoring in the evolution of your domain.Type: permanent
Start date: asap
Location: BORDEAUX
So, remember the goal: to present yourself, your company and the context. Is the person presenting herself? Well, sort of. We know the author has difficulties in written expression, but we don't know his role in the company. What about the company? Nope, not a thing (except that they hired a person who cannot express his ideas clearly and let this person publish job postings). What about the context? Not a clue.
What do we know? We know that they are looking for someone who spent 5 years in college, the reason remaining unknown. The next lines of the posting make no sense, so it's difficult to tell anything from them. What is a “person in charge of application”? Why is the person suddenly talking about Oracle Business Intelligence? What are those referential links? Why are they hanging their customers on a tree? That's scary. Follows a bunch of tasks the unfortunate candidate will have to do. Among them, the cleaning of the database. Wait, what? Project manager. Cleaning of the database. WTF?!
How the whole process of composing such description happened? Was it an actual person who either consumes drugs or has some sort of disability who did that? It is understandable that the secretary didn't have a clue about OBIEE or the escalation of issues, but why would this person accept writing that? Why wouldn't he or she walk down the office and ask their DBA: “Please, can you write the job posting for me?” What happened to the communication in this company if the secretary cannot ask a simple thing to a DBA, or to any of the developers?
Finally, why are they giving this task to a person who obviously is unable to write, a person who doesn't know that “ASAP” is an abbreviation and should be written in all capitals, while “Bordeaux” is the city, and should be only capitalized?
The job posting doesn't answer any of those questions. Instead, it gives a very bad image of the company which becomes even worse when we read on the front page of their website: “Our strategy: being a recognized discoverer of talents; follow each talent towards excellence; [...]”. Why are they deciding to throw away all their marketing with a simple job posting? Why would they decide to destroy their image by putting side by side the claim that they are a “recognized discoverer of talents” and the actual job posting showing that they have no clue about anything related to hiring and have deep communication issues inside their company?
Let's look at another example.
Example 2
Salsita, a company in Prague, Czech Republic, is currently searching for a remote JavaScript software developer and published a job posting on Careers.SE. Note that Careers.SE has a specific format in three parts which prevents following the three goals I described above.
Job Description
Salsita focuses on the rapidly growing area of JavaScript software engineering: building complex software architectures using JavaScript for our international clients. This includes:
- Sophisticated modern websites using AngularJS and other popular frameworks
- Scalable backends using Node.js (we also use Python, Java and other languages for some projects)
- Portable mobile apps using PhoneGap (we also do native iOS development)
We are seeking experienced JavaScript software developers to join our team and work remotely alongside our world-class engineers. You will work on interesting and challenging projects for clients in the United States, Europe and around the world. Our development process is based on scrum and uses best of breed tools like Pivotal Tracker, Github, Review Board, CircleCI and Slack. We have a heavy emphasis on quality, with mandatory peer code reviews for every line of code we write, and a dedicated quality assurance team responsible for manual and automated testing.
They got it right from the beginning. The description of the company is here; moreover, they explain why is this a great company to work for: world-class engineers, interesting and challenging projects, Agility, emphasis on quality, code reviews, QA team. I don't see what else I could ask (given that the position is remote, so most points from Joel Test don't apply here).
Skills & Requirements
- Strong foundation in software engineering (preferably university degree or equivalent)
- Several years of professional experience programming in JavaScript
- Thorough understanding of JavaScript concepts including prototypical inheritance, closures, variable scope/hoisting, etc.
- Experience developing single-page web applications, preferably using AngularJS
- Excellent written English and good spoken English
- Strong communication and interpersonal skills
Because this is a remote position, you must have the appropriate computer hardware and internet connection.
As I explained, listing technical and non-technical skills is usually problematic, but Careers.SE encourages that, and to be honest, their list seems fair. They don't require candidates to be motivated or productive. They keep their requirements at a minimum, and clearly explain what they need.
About Salsita
Salsita is a successful, fast-growing software development consultancy headquartered in Prague with a sales and marketing office in Silicon Valley. Our mission is to create top-quality custom software solutions for our international clients. We are dedicated to continuous improvement of our agile development process and use of the latest technologies and tools. We are constantly experimenting with new languages and technologies including CoffeeScript, TypeScript, React and various functional languages for backend development.
In our business a company lives and dies on the quality of its team, and we offer every benefit we can think of to attract the best software developers available. In addition to our core development team in Prague, we are building a network of select remote developers around the world who have the skills and experience to complement our existing engineers.
Excellent, well-written description. They repeat a few things they've already told in the first part, but it doesn't look repetitive. This job posting gives an image of a solid company which looks for skillful people to create high-quality software and to work on challenging projects.
Back to the goals, they achieved to present the company (bonus points for an excellent presentation) and the context. What about the person I will talk with? Well, Careers.SE makes it difficult to explain that, but given the job posting, I'm pretty sure that a candidate will be interviewed by an engineer or somebody ele who is actually able to determine the skills of the person.