Posted by nicksergeant 1 day ago
It's powered by https://rapidapi.com/letscrape-6bRBa3QguO5/api/jsearch, which is a little pricey, so I'm trying to decide whether to put more effort into the project (I'd have to charge _something_ to offset the costs).
Edit: seems like this is only the "Classic Search", and presumably may disappear once "AI search" is no longer optional?
FWIW, I didn't know the current search was a new "AI search" and that the "classic search" still provides this functionality, when I built this :)
All of the timeline discussion stuff is a small minority of their users. You can completely ignore it, as most do.
The app performs its functions entirely client-side except for the job search to JSearch, which only requires the company name.
> What you choose to upload to JobsByReferral.com is entirely up to you - you don't need to upload the entire ZIP. You can upload the Connections.csv-formatted file after you review it. You could also obfuscate person names if you'd like, before uploading.
> We also do nothing with your data. You can verify the app does not send your data to any backend endpoints _except_ for company name (so that we can find jobs at that company).
Edit: we've added some privacy details here: https://jobsbyreferral.com/privacy
Referring randos to be nice isn’t a thing any more at any company that has been paying attention.
I even wrote a version of it, but like many side projects; I lost motivation after leaving the original company I was working at (where I was integrating with things).
I really want a way of recommending people you've worked with previously; should they happen to apply to your current workplace.
I've worked with some absolute stars and would gladly work with them again.
My original design (that I even got working) had two ways of "recommending" people, essentially you had either: select people from your linkedin network or add an email address/phone number and name you know them by.
Then after selecting a person you're asked how closely you worked with them; becuase sometimes it's a nice person but you can't speak to competence: sometimes, it's someone you were really in the trenches with and they had your back.
I also design the opposite of this, where you would "un"-recommend people, or essentially downflag their application.
The thing is, my system wasn't fully integrated in the the HR management system, so it would add a comment if someone applied with the correct details but recruiters didn't have access to the database of recommended people- it also had an issue where someone could impersonate someone else by pasting the same linkedin link - though then they might need to know who might be recommended.
Anyway, nothing foolproof, just making it easier for people with a good reputation to be integrated into the company easier.
but how is your solution better/different to a referral, other than the un-recommendations? (which i like the idea of but am weary of ethically)
I wouldn't go out of my way to tell our internal recruiters about every person I might enjoy working with again; additionally I don't necessarily think they'd care to chase someone down - especially so if there's not a currently open position.
I'm also normally not directly plugged in to HR's candidate management system as an IC, unless someone is escalated; at which point then I might give a referral.
The value of such a solution is that people can just quietly plug away recommendations when they first join and forget about them until that person happens to apply later on, at which point their notice is not just noise.. it becomes a signal on an emerging opportunity. One that might not have otherwise been there.
Bonus; if recommendations are tagged with the user who made them, HR could reach out for additional context on the candidate.
Let's imagine tomorrow a Product Manager at LinkedIn wants to introduce this as an official functionality? They're going to have to run it by management or their pod (or find the PM in charge of that area if its not them), finish existing project, wait for resources to be ready, have legal/marketing/compliance involved, get it developed, go through all the other red tape, etc.
I don't know exactly how LinkedIn works internally, but I'm sure some of this is accurate.
So maybe, MAYBE they'll have it in a couple of months? But someone can build it in a few hours, even if they're not super good at this stuff.
It changes everything about how we think about products and SaaS software.
Note that the end result is not the same as what LinkedIn would have built. Perhaps in some ways better and in some ways worse.
E.g. personally I am not comfortable bulk uploading personal data of myself and my network to a third party server.
Thats the whole point. In an AI world, you're no longer bound by the limits of what 3rd parties do or don't do, plus or minus some datasets (like in this case, the job postings).
> personally I am not comfortable bulk uploading personal data of myself and my network to a third party server.
The subject of this show HN is completely client-side.Why should I take all of my data and give it to you, a rando on the internet? Is it being stored? Will it be shared? Sold? Maybe, as there's nothing that says you won't.
Looks neat, but strong pass because of the above.
That's the whole point.
It was always possible (hire software devs to do it), but the bar and cost is much, MUCH lower.