Insufficient “processing power” is the reason why many improvements I had requested are not viable.
1. Why wouldn’t LinkedIn Recruiter search for a Boolean of school names, while LinkedIn.com can?
[Dan]
This is possible, of course, but right now, it isn’t in the plan because it is really (really) expensive to build Boolean functionality outside of keyword searches. This is true (the expensive part) for any field outside of keywords. So right now, we allow keyword searches (as you, of course, know). The cost (and therefore speed, and processing power… not just talking about engineering cost here) is substantial.
2. I cannot see an attached resume in Recruiter:
[Dan]
This is a funny one, actually. That guy Theo actually did a fairly creative use of the “featured” zone. So we don’t actually “show” that as a resume. We get resumes from Job Applications, and Post Apply Flow sharing. But that doc is actually in a very poorly adopted section called “Featured”. We don’t show that in Recruiter, because it has VERY low liquidity. So we don’t actually recognize that as a resume, despite the fact that it is.
Low liquidity?
3. The “Selection or Boolean” fields are confusing. I would separate them – give the user a choice of either Boolean or selections. Imagine searching for “current or past title” for this; I don’t think the UI should allow it:
[Dan]
This idea would work if you 1) assumed our taxonomy was perfect and 2) we supported AND operators with “Selection”. For 1), as an example, we don’t have “Jira Administrator” in our taxonomy. Now, does that mean we don’t let you search for this? Of course not! It’s a valid title. So we let you do Boolean to cover the first 85% of use cases well, but then allow keyword to let you get to 100% coverage. And because we don’t do 2), we would end up removing Boolean functionality if we made you do only Selection. The “Current Or Past” just tells us where to look. So in reality, I think the experience makes more sense now than what you are suggesting. If we split them, it would not work as well, and not get as much coverage.
Have you looked at the hidden LinkedIn operators yet? They can do wonders; I wish that would be in the UI. 😊
[Dan]
The article actually says this works but I don’t think it does. I tried it out (and had a PM on my team play with it too) for a few searches, and the results don’t match each time. So I don’t think this would work better, because I don’t think it is actually doing what that article says it is.
Oh yes, it does.
Check out our latest class on LinkedIn Recruiter, incorporating all the feedback I got from LinkedIn Engineering (thanks, Dan!)
