Thoughts on LinkedIn Recruiter
We just wrapped up our first hire through LinkedIn Recruiter.
Prior to this, every engineering resource at InnovoCommerce has been sourced through Stack Talent (formerly Stack Careers) directly or indirectly.
We had great success with Stack and I hired two of my all-time favorite resources from that channel. However, this go-around, we decided to experiment with LinkedIn with a fallback on Stack if we didn’t like the results we were getting.
I thought I’d share my experience with it for other folks looking to expand their toolsets for talent.
Pricing
What initially drew me to LinkedIn Recruiter is that it’s priced kind of like how Facebook or Google ads are priced. You basically set up a daily budget for a certain rate of clickthroughs. We set ours at the recommended $18/day and received plenty of clicks.
I really liked the self-service model which didn’t require me to talk to a sales person to set it up. I put in the credit card info and off we went with our job posting. it’s a low barrier of entry from a process and financial perspective. If I didn’t like it, I could end the experiment early after 1-2 days.
With Stack, we had to go through a salesperson to acquire a slot. The primary option is to purchase the slot for a full 12 month period @ $4500 for a single slot (discounts may be available if you purchase more), but I told our sales rep that we’re a small company and did not see utility of that price plan for us. He did the typical car salesperson routine and had to ask his manager for a special for a 6 month slot at $2200. This really turned me off even though we had previously acquired our team members — directly and indirectly — via Stack. What’s even worse is that a Stack sales person didn’t even contact us on the first day. We had to reach out to them again on day 2 to get them to call us.
With LinkedIn, we ended up running the posting for some 23 days at a cost of $446 with 60 candidates applying. We’ll look at the breakdown later in the post.
If you are looking to hire multiple positions, Stack — purely from a financial perspective — is a better bet since you can keep reusing that job posting for the next 6 – 12 months.
For my team, the decision to use LinkedIn was partially an experiment and partially because we knew we would not make full use of that slot.
Flexibility
This go around, I did not use the Stack tools so I can’t compare LinkedIn to Stack, but I can say that I liked the flexibility of the LinkedIn posting with two caveats.
After it was posted, I changed the title once from “Senior Full Stack Engineer” to “Senior Software Engineer” as I was receiving resumes for candidates who were far too UI-focused in skills and experience. However, one thing I could not change was the location of the job. I do not know the internal algorithms used by LinkedIn, but most of the candidates who ended up applying were from the Greater Los Angeles area since our office is in Irvine, CA.
However, I was open to hiring from NY Metro/NJ and Tijuana, MX also. I did get applicants from all over the world, but I can’t be sure if my pool of applicants would have been different had I been able to change the location or add multiple locations. This seems like a really basic feature which should be incorporated.
I also didn’t like the fact that for the skills section, it was not possible to put arbitrary text; there is a certain pool of terms which it wants you to use. It seemed somewhat limited and not as broad as say Stackoverflow’s (not Stack Talent) tag database. For example, I wanted to put “MSDeploy” or “Web Deploy” as we use this for some legs of our application deployment but it was not an option in the skills section.
Other than that, I was able to alter the posting multiple times, I was able to amend to include additional details, and so on. But there are at least two boundaries on the posting that limit you.
Usability
On the usability side, it was a mixed bag for me.
Great:
- Really liked the integration of the LinkedIn profiles with the applications; made it really handy to get an overview of the candidate
- Very seamless access to resumes along side of the profiles
- Email notifications are really solid with the resumes handily already attached
- Job gets attached and featured on your company LinkedIn page
- Easily publish the posting to your network, which can be a good thing (find more trusted, proven resources) or a bad thing (limits the pool of potential candidates)
Not so great:
- Navigation is not so great; you get redirected from the main LinkedIn domain and need to log in again, not the most intuitive UI, the link to edit the job requires multiple clicks (should be a primary action), not enough usage of color/font-size to differentiate different UI elements
- Limited formatting options in the post body
- Issues with the WYSIWYG editor (maybe just a Firefox issue?) whereby it would add phantom line spacing
- I would expect being a Microsoft company now, to have better in-line document viewing experience (a la web Outlook)
- No ability for candidates to provide a “cover letter” or some introductory text; all you get is the application. I find this to be a weakness as I would really have loved to see a candidate provide some background info or a short personal message and why they are applying
- Salary range is not a metadata option so you can list it in the body, but it is not a filterable criteria for the applicants on the other side
- The “Not a Fit” is a mysterious button; I wish I could tell a candidate why they were not a fit instead of just clicking the button and the candidate disappears into the ether. At the least, there should be a tutorial which describes the interactions like what does “Not a Fit” do?
- No ability to “pause” or “suspend” the posting once you had a good set of candidates in the pipeline that you needed to process; it was all or nothing.
While it seems like I have many areas where I took issue with the usability, I was generally satisfied with my experience once I got the hang of it.
I think one really cool feature would be to allow A/B testing of the same posting and provide statistics on view/click rates. So it would allow creation of multiple “profiles” for the same job which get chosen at random to see which text is more effective for clickthroughs. Even better if LinkedIn could apply machine learning across their pool of thousands of job listings to suggest improvements to a listing based on the skillset, title, etc.
Quality of Candidates
Ah, the all important question. Again, I did not use Stack this go-around, so I cannot comment in terms of a comparison, but I can give you my experience with LinkedIn. I expect that as LinkedIn has grown, the potential pool of resources on Stack and LinkedIn has a high degree of overlap so the pool itself is not necessarily the key point, but how well the matching algorithms work.
LinkedIn starts you off with a pool of 50 “matches”. I use that term in quotes since I would say that most of the candidates did not actually match what I needed so I was puzzled by how LinkedIn chose those profiles. All of them were local to the Greater Los Angeles area so it makes the issue of not being able to specify multiple locations even more egregious. I ended up not contacting a single one of the matches.
Then of the candidates that did apply, I would say they fell into a handful of categories:
- Had the skills, but located in sub-optimal geo-regions. Egypt, South America, Eastern Europe. These would not work for us. This is where the ability to specify multiple locations and assign a weight to the location would be extremely useful.
- Had no skills, but applied anyways. I did interview a few folks from this group because you never know, you might find a gem once in a while. LinkedIn does have a great feature for this since it shows you the candidate’s years of experience and matches on relevant skills.
- Wrong skills, but applied anyways. The title and description was for a senior software engineer and I received applications from some folks whose backgrounds were more oriented towards infrastructure or IT support. I had a few who had strong backgrounds in test, but would require more training to get up to speed.
- Right skills!
Of the 60 candidates that applied,
- 12 were contacted
- 7 went through an initial interview
- 3 then went through a technical assessment
- 4 turned us down after the initial phone interview
- 7 went through an initial interview
- 17 were un-contacted (still in queue) after we found our candidate
- 31 were marked as non-matches
For the last 8 years, I’ve been using a standard assessment for every candidate that I’ve interviewed. It is not a hard assessment, but it measures how deeply you know common web application technologies like CSS, JavaScript, and C# as well as a candidate’s understanding of OOP (with an open ended design question). None of the questions assess knowledge of libraries or tools. The questions are “core” questions that seek foundational knowledge. For example, for CSS, I only have two questions and one of them is what does position:relative mean? You would not believe how many candidates get this wrong; if you can’t answer this question, you’ve never really done CSS. In all of the interviews I’ve run in the last 8 years — not only in the context of my current employer — perhaps only 5-6 candidates have gotten this right. People have come to rely on libraries so heavily that they have no understanding of the foundations of these tools. For JavaScript, the first question I ask is for a candidate to complete the following code snippet:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
var person = { firstName: "Charles", lastName: "Chen" } // Objective: alert the value of the firstName property // without invoking person.firstName; use the string value // "firstName" alert( // TODO: One line here ) // Expected output: alert with "Charles" |
It’s a fundamental question of whether the candidate understands that objects in JavaScript are dictionaries. Likewise, very few candidates have gotten this question right.
The candidate that we did finally made an offer to ended up with the second highest score ever on the assessment so it looks promising at the moment 🙂
Of course, we also had one candidate who gave me this gem:
Final Thoughts
This was our first experiment with LinkedIn and I think it was relatively successful. Having such deep profile information integrated into the candidate management pipeline is a big bonus. There are definitely improvements that the LinkedIn team can make to make it a better tool. For teams looking to make targeted hires, it’s a great deal. For teams looking for bulk hires, Stack may still win from a financial perspective. I think that the base talent pool likely has very high overlap, but the matching algorithms are going to be different. With LinkedIn, there is one aspect which is quite interesting is that the job listing must have some weight based on connectedness. We got lots of second-degree applicants (candidates who knew someone already connected to me). I don’t know how strongly this is weighted in the overall matching algorithm, but it may have a negative effect on your candidate pool if your overall connectedness is low.
Post Script
This is the first time I’ve used JSFiddle and .NET Fiddle to conduct technical assessments. These are excellent tools that make use of an awesome library from Mozilla called TogetherJS and I plan on using it for all future interviews. They both let you collaboratively edit and run code; a really great way to conduct a remote technical assessment.