Targeting PAST experience on LinkedIn – can it be done?

I recently had a recruiter ask me if there were any way to be able to search LinkedIn for people who have worked at a specific company in the past, but who are NOT currently working for that company.

I can see why some Sourcers and Recruiters would want to specifically target people who are not currently at a company, but have worked there in the past. I’ve done a bit of digging on this, and I have yet to find a way to reliably targeting past experience while ensuring that you only get results of people who are not currently working at the target company.  When searching within your network on LinkedIn, as you may know, the only controllable option you have is to be able to search for people who are currently at target companies. If you leave the “current companies only” option unchecked, you will get results with a mix of people who are currently employed at your target company as well as those who are no longer working there. Also – when searching inside your own network – you are limited to results of people to whom you are connected up to the 3rd degree.
Going beyond your own LinkedIn network, you can try using Google and other Internet search engines and employ the site: command to search into LinkedIn – but we have to be aware that this is not a method that affords you precise control over current or past experience.  However, I’m going to give Google, Exalead, and AltaVista a thorough LinkedIn Boolean workout.

Let’s begin with some Google basics. For example – if you were using Google to search into LinkedIn and try to find people who have worked at Lockheed Martin at some point in their career and, for the case of this exercise, currently live in the Denver area, you could use this search and enter any additional specific search terms you might be targeting where I have SKILL/TITLE1, SKILL/TITLE2, etc: “greater denver area” lockheed -intitle:directory -intitle:updated SKILL/TITLE1 SKILL/TITLE2

That gets pretty clean results – I checked several pages worth. However, if you run into false positive hits like answers or jobs, you can try adding the following:

-inurl:jobid -inurl:answers

When you execute the search, you’ll see that it pulls results of people who are currently working at Lockheed Martin as well as people who have worked there in the past. Not really different from attempts made searching within your LinkedIn network  – with the exception that you will likely find more people since you are no longer limited to the size of your personal network or LinkedIn’s limit of 500 results.

I thought of using Exalead ( in an attempt to exploit the fact that Exalead recognizes the NEAR proximity operator. Using the NEAR operator, we can try to force certain words to be close to the word “past” or NOT in their current position in an effort to try and search people’s past experience specifically.  This is not an exact science, but it’s worth a shot.

This search is trying to find people who mention Lockheed on their profile, but who are not currently employed at Lockheed: -inurl:jobid -inurl:find -intitle:directory -inurl:answers -inurl:updates “greater denver area” Lockheed NOT (current NEAR Lockheed)
Checking the results, you can see that it works relatively well, but not perfectly, mostly due to the structure of LinkedIn’s profile page – current and past experience are listed so close together that trying to use the NOT/- operator in conjunction with NEAR will cause problems, such as eliminating results we actually want. FYI – Exalead does not appear to recognize “-(current NEAR Lockheed)” exactly as it does “NOT (current NEAR Lockheed).”  Running searches back to back switching out the – and NOT yield slightly different results.

I tried a variation of that theme, trying to avoid profiles of people who list Lockheed as their current/most recent employer in the career history section of their profile: -inurl:jobid -inurl:find -intitle:directory -inurl:answers -inurl:updates “greater denver area” Lockheed NOT (experience NEAR Lockheed)

This search seemed to work well – better than the above search, in my opinion, and it’s interesting to note that a good number of the page 1 results have profiles of people who have headers stating they are currently at Lockheed, but when you scroll down to their experience section, they are in fact, not currently working at Lockheed. So this search string worked relatively well.

Here is yet another variation on the theme – what we’re doing here is avoiding profiles of people who mention Lockheed in the current title/employer field, and it appears to work well: -intitle:directory -intitle:updated “greater denver area” Lockheed NOT (“greater denver area” NEAR Lockheed)

Now that we’ve given Exalead a workout, I figured I would turn to an old favorite of many – AltaVista.

I first tried running the last search I just ran on Exalead: -intitle:directory -intitle:updated “greater denver area” Lockheed NOT (“greater denver area” NEAR Lockheed)

It only returned 1 result – so Exalead wins this round. For anyone interested – the search executed exactly the same when I used “AND NOT.”

Then I turned to one of AltaVista’s coolest and most powerful features- configurable proximity searching.  If you’d like a refresher on AltaVista’s advanced Boolean operators, check this link out: (

This next search tries to eliminate results of people with profiles that mention Lockheed within 7 words of the word “current” on their profile: -intitle:directory -intitle:updated “greater denver area” Lockheed NOT (current ~~7 Lockheed)

Strangely enough – that search only returned 6 results. The first result is odd because Lockheed is definitely mentioned within 7 words of Lockheed, but the rest seem to be good results – people who are not currently at Lockheed. However, 7 results is a little on the small side.

FYI – it appears to run identically with or without parentheses. However, switching between the – and NOT where we have (current ~~7 Lockheed) does change the results – not just the number, but the actually results themselves. Odd.

Here is another search we have already run on Exalead, which attempts to avoid results of people with profiles that have Lockheed mentioned within 10 words or so of “experience:” -intitle:directory -intitle:updated “greater denver area” Lockheed NOT (experience NEAR Lockheed)

That yielded only 2 results on AltaVista vs. 61 on Exalead – so Exalead maintains its lead, pun intended.

Alright – time to try and get Black Belt on AltaVista.

I attempted to invoke AltaVista’s power of proximity AND order – trying to find profiles that mention Lockheed but not Lockheed mentioned before the word “past,” which, according to the standard LinkedIn profile structure (assuming everyone uses it, of course) would mean they are currently at Lockheed. Trying to prevent “Lockheed” from showing up before the word “past” SHOULD work based on the majority of the LinkedIn profiles I have seen. “greater denver area” Lockheed -intitle:directory -intitle:updated NOT (lockheed < past)

This did work – but it yielded only 12 results and some of the people do currently work at work   at Lockheed.

I then tried to prevent “Lockheed” from appearing before the location on the profile – which is a field/area where, if utilized, is where many people list where they currently work. “greater denver area” Lockheed -intitle:directory -intitle:updated NOT (lockheed < “greater denver area”)

This search did run, yielding 12 results. However, it definitely let slip through some people who do mention Lockheed before “Greater Denver Area”

And now…let’s give Google another shot.

While Google does not support proximity searching in the form of the NEAR operator or configurable proximity (shame on you Google – really), we can try to approximate proximity searching by making use of Google’s single word wildcard operator – the asterisk.

What I will try to do is use multiple asterisks, representing multiple wildcard words, and combine it with the NOT operator, to attempt to prevent results of people who mention “Lockheed” within 2 – 5 words of words that would indicate that they might currently be employed there, such as “current” or “experience” or “greater denver area.”

In this search, I am trying to avoid Trying to avoid the word “Lockheed” within 2-5 words after “Current:” -intitle:directory -intitle:updated “greater denver area” Lockheed -“current**Lockheed” -“current***Lockheed” -“current****Lockheed” -“current*****Lockheed”

That search ran and yielded 106, but many of the results have “Lockheed” mentioned within 5 words of the word “current.”

Out of curiosity, I tried spacing out the asterisks: -intitle:directory -intitle:updated “greater denver area” Lockheed -“current * * Lockheed” -“current * * * Lockheed” -“current * * * * Lockheed” -“current * * * * * Lockheed”

That search ran and yielded what appears to be the exact same 106 results – so spacing the asterisks does not appear to have any different effect, at least in this specific case.

Next, I decided to switch out the – to NOT for the Lockheed-related statements, again, mostly out of curiosity, and neither of the below searches ran: -intitle:directory -intitle:updated “greater denver area” Lockheed NOT “current * * Lockheed” NOT “current * * * Lockheed” NOT “current * * * * Lockheed” NOT “current * * * * * Lockheed” -intitle:directory -intitle:updated “greater denver area” Lockheed NOT (“current**Lockheed”) NOT (“current***Lockheed”) NOT (“current****Lockheed”) NOT (“current*****Lockheed”)

Perhaps Google’s single word wildcard asterisk operator doesn’t work well when combined with the -/NOT operator.  Has anyone else experimented within combining them?  If so, please let me know.

Well, I hope you enjoyed this exercise in attempting to isolate and target profiles of people on LinkedIn who have worked for a company in the past, but are not current employees of that target company. I know I learned a few things along the way – that Exalead does a good job with proximity via the NEAR operator, that some of AltaVista’s proximity operators (NEAR and before) don’t seem to work as well as they should, and that Google’s asterisk operator doesn’t seem to play nice with the NOT operator.