How to stop recruiters posing as applicants | Hacker News Reader

How to stop recruiters posing as applicants

twitter.com

57 pointsColinWright67 comments

What I see here is one group of people (the company with the hiring page) doing the standard "fun/playful/lightweight engineering task" that people have been doing for years to filter applicants. Then some unrelated person tweets that this will prevent recruiters posing as applicants. Now the HN thread is assuming this is the only purpose and questioning if this problem is worth it.

Has it not occurred to anyone that what one dude says on twitter is the primary purpose might not be so?

Exactly. This is just a web-oriented version of "fizz-buzz".

Whether or not they had recruiters posing as applicants in mind when designing this, it doesn't change the fact that this particular task is ill advised. The first person that becomes remotely disenchanted with them will flood them with random applications. I'd bet almost anything that they will have to scrap this exercise and start over.

I don't see how it is more open to abuse than just giving an email address. You could send someone 1000 messages if you wanted.

Is the ability to hammer the POST interface really much worse than the ability to send lots of mails to a jobs@company.com alias? Sure, maybe people's email configurations are better equipped to deal with spam, but you can send email in a script, too.

I disagree. Were it to become a problem, it would be trivial to deal with an application flood.

Among many options, provide a unique 'application key' on the instructions page which expires after first use. If you're really concerned, or it becomes a problem, just add a Captcha-like requirement to get your application key.

Besides, as asveikau points out, the risk is no different than any other application acceptance system. Take applications by mail? Fine, I'll buy a roll of stamps and make a few stops to the post office.

http://www.de-captcher.com/ - have 1,000 Captchas solved through their API for $2. Captchas haven't been a reliable anti-spam solution for years.

Considering that I said "Captcha-like," don't you think you're missing my point altogether?

We've been running this exercise for the past year now. During that time we've had several excellent applicants, no recruiter spam, and no "web developers" who couldn't describe how a website might track a session. And no random applications other than people playing with it for fun.

Hi, I wrote this service. We do indeed mention that it's a hurdle for recruiters to jump, and it was partly intended for that, but we also use it to screen out people who can't really program. The number of applicants we had before this that couldn't explain how a website might track that you're logged in was terrifying!

This... reminds me of a friend's anecdote where a guy brought in to interview, describing himself as an "expert" in C, didn't know what a pointer was.

The interviewer had to "save" the situation by blurting (regarding the sample code given to the applicant on paper), "oh, those stars, yeah they must be typos. Sorry about that! Let's move on to another question."

We devs hate doing interviews. So we created an online programming test. For all applicants.

Only about 30% of applicants scored 100%. I'm still astonished.

We logged duration and attempts. I'm actually okay with someone retaking the test to improve their score. It was just CRUD work, requiring mechanics, not rocket scientists. And it means they recognized their own error and fixed it. Pretty much what you want out of any dev.

Am I the only one who finds the phrase "json encoded hash"... inaccurate? Maybe someone can enlighten me, but is JSON really an "encoding"?

And what exactly do they mean by "hash"? They want the JSON to be a fixed length? How would you like my JSON hashed? How are you going to pull my data out of the hash?

And as a 'field' called response? Don't they mean, "as the value of a field called response"?

Is this part of the test, deciphering the jargon soup? Because if I'm understanding this correctly, a bunch of terms just got misused in a very short sentence, which would put me off of applying here.

It's not. It's a serialized object.

The JSON object is serialized? How?

It's turned in to plain text that can be re-created in to the objects. From Wikipedia [1]:

"[...] serialization is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer, or transmitted across a network connection link) and "resurrected" later in the same or another computer environment"

[1] http://en.wikipedia.org/wiki/Serialization

I also cant make sense of it. Do they want me to send them a hash of all my details? I don't think that would be very useful in letting them contact me.

Hash here is referring to an associative array, not a hashing function.

What if the JS implementation in my system uses a tree rather than a hash table to implement an associative array. Is it then still a 'hash'?

"hash" = "hash table" = "associative array" (even if the implementation used by the language is not, in fact, a hash table)

Okay that's fair but... ugh. Unnecessary.

I agree, I hate the terminological abuse.

That was my initial reaction, and then I thought that they may be just trying to obfuscate the process a bit. The more "technical" terms they use, the more they deter non-target applicants.

Though, being too pedantic is certainly risks deterring the target applicants.

No, you're confused. Nobody is saying they are being pedantic. Everyone is saying the opposite - they are being sloppy and non-technical with their terms.

I don't believe I am, since JSON is a hash by definition. It is characteristically technical.

Are you sure it's not referring to the session ID when it says the hash?

I think it means to suggest that you should send in your response a key value pair of response -> session ID that you get from the headers when you load that form.

They most likely meant "hash" in the sense of Ruby's Hash (http://ruby-doc.org/core-2.0/Hash.html), a.k.a. hash map, dictionary, associative array, etc.

It's annoying terminology, I agree.

Its the distinction between data structure and algorithm that seems to fall apart here. The word hash on its own is used to refer to the output of a hash function ("the hash of X is Y") rather than the ADT "dictionary" that they really meant. It appears that you're right though, this may be something extracted from the Ruby community.

That's precisely it, I come from a background of doing Perl and Ruby, which led to my misuse of the word hash here.

I was gonna say.... my first thoughts were : a) which algo, and b) which field should be hashed ...

....so in fact they're probably weeding out programmers who've done such things

You are not the only one. I read that and thought it was the most awkward phrase you could have picked.

Not because JSON isn't an encoding though ("JSON-encoded" makes sense to me) but because saying "hash" instead of "hash table" or "associative array" or pretty much anything else is uncomfortable -- the word hash on its own generally refers to a hash function rather than the data structure.

Except in Perl where it is a synonym for dictionary.

And Ruby [1], apparently.

[1] http://ruby-doc.org/core-2.0/Hash.html

It's not terribly precise but it's not very confusing if you're familiar with the way HTTP APIs are typically constructed nowadays, which presumably would normally be the case for the kinds of applicant they want to attract. They want you to HTTP POST a JSON-formatted (yes, you could say 'encoded') JavaScript dictionary - a 'hashtable' (hash is an appropriate abbreviation for this, albeit a confusing one) - i.e. a JavaScript object whose key/value pairs match the keys they specified.

Of course, the question of why they requested the key/value pairs be POSTed in JSON format when HTTP specifies a perfectly simple and widely supported mechanism for POSTing key-value-pairs to a web endpoint, which is application/x-www-form-urlencoded... well that's a different problem.

Yes, I could have been a lot clearer about that, and will clarify the text in the morning, this was my first attempt at a publically available API, and now you mention it the documentation could have been far better.

As people have picked up I meant a hash table serialised as JSON.

As people have picked up I meant a hash table serialised as JSON.

You are probably thinking about associative arrays. A hash table is something different: http://en.wikipedia.org/wiki/Hash_table

And so my lack of formal CS education is exposed! I guess I've got some reading to do on the train into work tomorrow to properly understand the distinction.

I wasn't aware that this was even a problem. I would think that using a tactic like this would immediately turn any contacts they made into enemies, rendering this a futile exercise. They also effectively made an API for anyone that feels like flooding them with millions of applications containing random data. All in all, like a cold medication that happens to cause cancer, I'd say this is a solution to a small problem that opens the door to dramatically larger problems.

I'm guessing the logic might be that there's a certain percentage chance that once communications are open with the hiring manager, the recruiter may be able to talk his/her way into getting the hiring manager to look at some of the recruiter's candidates.

From an EV perspective:

  Contacting company as a recruiter: 0% or very low % of success
 
  Posing as an applicant at first: 
  - x% chance of initial reply from hiring manager
  - y% chance of "conversion" of manager into "client"
  - x*y is perceived to be greater than other options

I imagine that the recruiter can either, (a) submit a "real" resume that he/she has, or (b) submit a "fake" resume that looks really good, eliciting a response, then bait and switching to a different "real" candidate, saying that the initial one is no longer available.

It isn't a huge problem, but it was enough of a problem to be annoying, and I had an afternoon to spare so threw this together with the hope it would also attract some attention from inquisitive hackers.

You could indeed flood us with applications using it, but if you did we could also screen them out pretty easily, or just turn the service off.

you are really convinced of this.

How is this any different from just having an online form to fill out? The only difference I can see is the web browser is filling out post details, rather than you just crafting it manually.

Are you a recruiter? Don't be sour grapes :P

Well this would explain why my phone has been going crazy all evening!

I'm the person who put this process in place for Hubbub (which incidently is a great place to work, you should apply). I'll quickly skim through comments and post some answers now, but it's 0014 here so I'll probably catch up with the rest tomorrow. If you have any questions feel free to drop us a line on developers@hubbub.co.uk (unless you're a recruiter!)

As a final note, we have much more detail at http://developers.hubbub.co.uk/, including information about the year's supply of bacon on offer to both successful applicants and the people who referred them.

You mean to tell me that if I work for you, you'll supply me with bacon, for a year?

I can't tell if you are making a pun. If you are, it's a good pun.

I mean literally. One of the perks is a year's supply of bacon, as in smoked back bacon from pigs. Specifically some of the best bred pigs in the UK!

Just like you wouldn't make it hard to pay for your product, I think making it hard to apply for jobs at your company is a bad move.

Because most people are applying to a 'better' job than the one they have now (Cooler? More money? More responsibility?), they know that most initial applications will come to nothing.

If you believe your CV will get a reply 1/5th of the time, spending more than the 5 minutes it takes to send over a slightly customized CV is foolish. There are a lot of other people that don't require this much effort. Time is better spent writing to them.

This is going to get plenty of replies, because it's on Hacker News, but if it was getting the traffic more organically (i.e. if this was widespread), I'm not sure it would get a single one.

Yeah sure, for the applicant he wants, this is solved with, notepad, curl, 10 minutes, but it's still more effort than emailing it to his rival.

We put this in place to automate the screening of applicants after our first round of advertising yielded a glut of people who could barely write code, and no one who was actually worth taking past a phone screen.

Since then we've been receiving applications of a far higher calibre, and many applicants who went onto a full interview after phone screening. We definitely receive fewer applicants, but that's a trade off we're willing to make.

I've seen a few of these before. Here's an interesting one if you can figure it out. http://web.archive.org/web/20120722010228/http://forrst.com/...

Ha, that's a clever one.

I'm not sure I'd be able to get over their incorrect usage of the PUT verb.

Google had a nice one back in 2004 also: http://articles.businessinsider.com/2011-07-22/tech/30049105...

But probably wouldn't work so good today. The first one to find the solution would probably post it on twitter, then the recruiters could follow :)

Great example - Google's billboard ads were the inspiration when I put this together.

Yep, because a recruiter couldn't pay someone $5 to beat this.

I'm sure this is far more complicated than the full-blown mobile apps I see advertised for $100 by developers overseas.

Developers often cost $100/hr. It'd take at least half an hour to teach a recruiter how to use Postman. I think you're off by an order of magnitude.

It also has the precondition that the recruiter is willing to learn.

Just wrote a python script to do this in ~3 minutes (will resist urge to post source code) for recruiters who know how to use the command line.

Would take me another ~3-5 to build a web front-end in flask.

So let's call it 10 minutes all in.

At $100 per hour that is $16. And you can get developers who would be capable of doing this for way less than $100 per hour (like $10 per hour) so $5 is about right.

If a recruiter can get past this then best of luck to them. We still won't pay the usual ridiculous hiring fees, but we'll at least be willing to listen!

A few jobs back we did something similar, and posted in the ad that people could apply by solving http://unhelpfulclue.aqxs.net/lookup.php (Resulting email changed)

Technical tests before screening appear to be getting more common. Currently job-seeking, I'm getting a little frustrated by the number of times I have to prove that I can actually implement variants of Fizz Buzz. It'd be nice if I could submit a link to a previously completed Codility test or something...

(Yeah, it'd be nice if they accepted Github links or something as proof of technical competence, but as someone on the other side I don't really want to have to validate a hundred random OSS projects and check the province of the code in them)

Recruiters pose as applicants? What for?

To communicate with a hiring manager that otherwise might not give them the time of day.

Flip side of posting fake jobs to get resumes.

I'm afraid I still don't get it. A recruiter wants to contact someone managing hiring in some company (or his own company)? How does posting a fake application help, it'll be found out in no-time..?

The recruiter will probably get the full name, position and true email address of the hiring manager.

Plus, if the charade goes a few more emails, more details about the job.

I don't think they pose as applicants as much as they use the contact method (usually email) to solicit their services, even sometimes ignoring when the hiring company specifically says "please no recruiters." If they are posing, it would be pretty easy as well, as they could send in resumes & CV's of job seekers they represent.

Recruiters also pose as companies posting 'jobs', and from what I've seen when looking for gigs it's likely they solicit in the other direction as well. How low they sink, who knows.

The recruiter may be representing a "stable" of clients (programmers) looking for jobs. The recruiter would want to talk to the hiring manager to sell them on (any of) their clients (shotgun approach), without figuring out which resumes might actually be a good fit.

Alternatively, the recruiter might want more details from the hiring manager about the open position, so they could hunt for applicants to bring back to the hiring manager.

a recruiter will get all their information including direct contact email when they respond to the fake qualified resume the recruiter submitted, then the recruiter harasses the hiring manager(s) directly on linkedin and email, or sells that information to their applicants, or other recruiters.

Or they bait and switch, saying that person is no longer available and give a second resume, knowing they have full attention of whoever is hiring. Or they would find out their phone numbers and harass them with endless calls.

I'm the person from Hubbub who put this in place. Before it was there we'd get pretty frequent emails from recruiters offering to send us CVs coming in to the advertised address.

This process makes it abundantly clear that we're not interested, and also has the pleasant side effect of screening out people who aren't interested enough to read the man page for curl.

Wait, why do recruiters pose as applicants? Is this a common problem?

Also, Parse (and a few other companies whose names escape me now) have been doing this for a while. https://parse.com/jobs (scroll down to "Apply to Parse!")

    Your post advocates a
    
    (X) technical ( ) legislative ( ) market-based ( ) vigilante
    
    approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
    
    ( ) Spammers can easily use it to harvest email addresses
    ( ) Mailing lists and other legitimate email uses would be affected
    ( ) No one will be able to find the guy or collect the money
    ( ) It is defenseless against brute force attacks
    (X) It will stop spam for two weeks and then we'll be stuck with it
    ( ) Users of email will not put up with it
    ( ) Microsoft will not put up with it
    ( ) The police will not put up with it
    ( ) Requires too much cooperation from spammers
    ( ) Requires immediate total cooperation from everybody at once
    (X) Many email users cannot afford to lose business or alienate potential employers
    ( ) Spammers don't care about invalid addresses in their lists
    ( ) Anyone could anonymously destroy anyone else's career or business
    
    Specifically, your plan fails to account for
    
    ( ) Laws expressly prohibiting it
    ( ) Lack of centrally controlling authority for email
    ( ) Open relays in foreign countries
    ( ) Ease of searching tiny alphanumeric address space of all email addresses
    (X) Asshats
    ( ) Jurisdictional problems
    ( ) Unpopularity of weird new taxes
    ( ) Public reluctance to accept weird new forms of money
    (X) Huge existing software investment in SMTP
    ( ) Susceptibility of protocols other than SMTP to attack
    ( ) Willingness of users to install OS patches received by email
    ( ) Armies of worm riddled broadband-connected Windows boxes
    (X) Eternal arms race involved in all filtering approaches
    (X) Extreme profitability of spam
    ( ) Joe jobs and/or identity theft
    ( ) Technically illiterate politicians
    ( ) Extreme stupidity on the part of people who do business with spammers
    (X) Dishonesty on the part of spammers themselves
    ( ) Bandwidth costs that are unaffected by client filtering
    ( ) Outlook
    
    and the following philosophical objections may also apply:
    
    (X) Ideas similar to yours are easy to come up with, yet none have ever
    been shown practical
    ( ) Any scheme based on opt-out is unacceptable
    ( ) SMTP headers should not be the subject of legislation
    ( ) Blacklists suck
    ( ) Whitelists suck
    ( ) We should be able to talk about Viagra without being censored
    ( ) Countermeasures should not involve wire fraud or credit card fraud
    ( ) Countermeasures should not involve sabotage of public networks
    ( ) Countermeasures must work if phased in gradually
    ( ) Sending email should be free
    ( ) Why should we have to trust you and your servers?
    ( ) Incompatiblity with open source or open source licenses
    ( ) Feel-good measures do nothing to solve the problem
    ( ) Temporary/one-time email addresses are cumbersome
    ( ) I don't want the government reading my email
    ( ) Killing them that way is not slow and painful enough
    
    Furthermore, this is what I think about you:
    
    (X) Sorry dude, but I don't think it would work.
    ( ) This is a stupid idea, and you're a stupid person for suggesting it.
    ( ) Nice try, assh0le! I'm going to find out where you live and burn your
    house down!

Reply on news.ycombinator.com