Or is that unsporting somehow? Downvotes suggest yes, but on the other hand it'd be pretty silly for someone to expose an API intending people not to write tools that use it.
Sadly "yes". That said, it's not "so hard" in absolute terms, but that is precisely why it works so well as a zero'th order filter.
You wouldn't want to hire based on passing that, but you certainly want to NOT hire based on failing. (Depending on what you're hiring for, of course; I can't see not taking a sales guy to do sales if he couldn't do it.)
I'm not immune to that concern, but 'ruined' seems like a strong word... it's not like I've injected that code into their page.
Really, I just thought it was a funny little hack worth sharing with the community. I doubt anyone from Parse sees it as hugely threatening to their recruitment strategy.
Well, from a personal point of view, when we did the reddit hiring, it really annoyed us when someone posted their solution to one of the problems, because there were clearly people who were copying the solution to get their cover letter to us. So then we had to read those letter to determine that no, this person isn't actually qualified, and now we wasted our time (and theirs).
So that is where I was saying the harm comes from. It's not hugely threatening, it's just annoying.
Don't you think that's throwing the baby out with the bath water a little bit?
I agree that it's a problem that people can easily dupe an interview by copying a readymade result, but that doesn't imply that public problems are unilaterally a bad idea.
In fact, I'd liken this to a public announcement of a security exploit. Someone has found an insecurity within the social algorithm of public problem interviews.
Your original claim was that one bad anecdote at reddit was enough evidence to consider "that posting public problem to hire people isn't a good idea."
Do you think that all public interviewing options are unilaterally unable to defend against people divulging public problems?
A public problem is essentially just a contest. Lots of contests are considered good figures of merit. If you win a nobel prize or a fields medal, that's a sort
of public problem solving exercise. Would you hire someone who won a nobel prize over someone else, all other things being equal? I certainly would.
Maybe the real issue here is that these interview problems aren't sufficiently challenging or interesting such that the barrier to entry is keeping answer-copiers out.
Unless you're Gregori Perelman, for example, you're likely not going to be taken seriously or given much credit for solving the Poincaré conjecture.
PS. I don't think it was fair to downvote me just because I disagree with the pov. Is that why I was downvoted?
I have extensive recruitment experience and I understand the idea of "let's filter out as much as we can to gain time".
My experience is: it doesn't work, you will have to crawl through resumes, do phone interview and have people come over. You can be clever about what you ask in a resume and how you do your interviews but you will somehow need a list of skills and experience and somehow you will have to talk to the people you want to hire.
Additionally, you don't want people who just "find solutions to problems", you probably want people who build systems. That's a different skill set, which is why you will not filter out the right type with a teaser.
You will also unreliably assess their skills because you cannot tell how much time it took or if they actually did it.
Have people come over. Evaluate their technical and human skill. Nothing fancy, just straightforward stuff.
If in one day of interview you think they're people you'd like to work with, hire them. If you have any doubt, don't.
Let go the idea of the exam. You're a company not an university.
I don't know. If the candidate can find a code on the net that does what he wants, it's not bad. In some situations, even better than writing the code by himself ;)
It is unsporting. The whole point of the exercise is for job seekers to show their chops and that, for some basic problems, that they can solve it without using Google.
For fun, I posted my info using curl, vi and not one Google search. A web developer with 2-3yrs of experience should reasonably be expected to be able to do this challenge.
Maybe, but personally I'd be pretty weirded out if someone who could figure out the significance and use of the string I posted could not figure out curl.
Based on personal experience, I'd respectfully say it's just you. I do see your point, though.
I've met plenty of people who could code up a simple web UI but weren't very familiar with the underlying HTTP protocol. I guess my point is that knowledge of the protocol and web infrastructure is more valuable (sometimes) than just being a person who knows how to slap something together.
Hey team, maybe I'm wrong but I don't get the sense that this is a "test" for entry. It says more about who they are and what they're about than it does the applicants.
Telnet is not the best thing to use when talking to non-telnet servers since it's not a raw protocol that just passes data back and forth. For example, telnet appends an ASCII NUL to any CR in the stream. Netcat gives a truly raw socket.
Of course. Abstraction is important and powerful, and the right tool for the right job etc etc. But that still means there's a certain thrill in submitting HTTP POSTs via magnetized needle.
I've seen job listings embedded in <meta> tags, in HTTP headers, all sorts of odd places. The trick is that some smart person stumbles on it by accident, posts it on their blog, then gets picked up by a major tech site.
Literally the worst developers I've ever known are the sort that would eat this kind of thing up.
The worst developers in my opinion are those that appear highly proficient and effective until they're asked to actually produce something, then never produce anything of value whatsoever. They're infinitely worse than those who are clearly ineffective from the beginning. They're talented but immature; unwilling to do anything they don't see as a game; unable to see everyday tasks as games.
There is a billboard around Utah that has a base64 string on it, if you decode it, it reads "head /hi" and if you HEAD their domain/hi it says POST then some params about yourself to /apply.
I know, my confusion was at the down vote and correction; clearly that's what they wanted people to see. I'm not sure what mistake people thought I made.
neat idea. now if only every employer had the same standard REST api at an agreed upon URI, (like sitemap.xml) so you can mass-apply, mass-update resumes. on their side they can mass-flag, mass filter, prioritize.
I should do this more often. Look at the wealth of information returned in the headers:
1) They're using nginx (which is powered by Ponies!)
2) The site is fronted by varnish with a ttl of 1 hour, of which there appear to be at least 4 varnish servers.
3) Links to the various CSS files. Do browsers actually use these headers instead of the <link>s in the html?
4) Drupal is somewhere in the mix.
5) Mention one of the company core values, of which there are at least 8.
6) Anyone geeky enough to be reading this should apply for a job.
$ lwp-request -e -d www.zappos.com
200 OK
Cache-Control: max-age=2452
Connection: close
Connection: Transfer-Encoding
Date: Thu, 02 Feb 2012 23:53:38 GMT
Server: nginx/1.1.14
Content-Type: text/html; charset=utf-8
Client-Date: Thu, 02 Feb 2012 23:53:39 GMT
Client-Peer: 203.206.129.48:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Link: </favicon.ico>; rel="shortcut icon"; type="image/ico"
Link: </styles/main.p.20120201135153.css>; media="screen"; rel="stylesheet"; type="text/css"
Link: </css/print.20120115152845.css>; media="print"; rel="stylesheet"; type="text/css"
Link: </styles/home.p.20120201135153.css>; media="screen"; rel="stylesheet"; type="text/css"
Link: </>; rel="canonical"
Title: Shoes, Clothing, and More | Zappos.com
X-Cache-Hits: 117
X-Core-Value: 8. Do More With Less
X-Meta-Description: Free shipping BOTH ways on shoes, clothing, and more! 365-day return policy, over 1000 brands, 24/7 friendly customer service. 1-800-927-7671
X-Meta-Keywords: index, zappos, zeta, clothing, shoes
X-Powered-By: Ponies!
X-Recruiting: If you're reading this, maybe you should be working at Zappos instead. Check out jobs.zappos.com
X-UUID: 970dff52-4df6-11e1-a3ab-001a645b7cf4
X-Varnish: 1001890813 1001890584
X-Varnish-Host: varnish04.zappos.net
X-Varnish-ID: drupal
X-Varnish-TTL: 60m
That's 1.3K of overhead per request. I call that doing Less with More. Recruiting in HTTP headers may seem like a clever gimmick to some, but I doubt it could possibly warrant the aggregate degradation of performance. If that's what they call doing "More with Less", my reaction is hardly an urge to work with them.
Yes, I measured the size of the HTTP headers. It's not a subjective measurement. It's not 1322 bytes; it's 1275 bytes. 1322 looks like you forgot to remove the indentation that was added above for code formatting. 1275 bytes == 1.3K.
Where do you get 1275? In any case, you can't consider all of this waste. Some of it is necessary (the connection headers, content-type, some of it is a performance improvement for a subset of clients (the link headers, etc.) and a small percent is waste (X-Recruiting etc.)
I measured the headers in ajtaylor's above post. Zappos delivers different headers each time, and currently they're only giving me 599 bytes, including zero Link headers.
I agree of course that you can't consider all of it a waste. My point was just that their HTTP overhead is exceptionally large, and their superfluous headers adversely affect all of their users despite the fact that almost none of their users will ever read them.
The fact that their X-Core-Value in ajtaylor's example was "8. Do More With Less" makes them seem clueless about the real impact of HTTP overhead.
- Surely a better challenge would be to publish a brief but involved spec, then say "implement this API that returns your job application details." Then they can retrieve the job application from the applicants. Ideally, applicants also publish the source code somewhere, so they can see how you code.
- Oh wait, this is #1 on HN and getting tons of views. It has already worked out perfectly for them, and I should stop criticising. :)
I can imagine a time when this practice becomes so common that spambots start mass-applying, and then employers need to use a CAPTCHA to ensure that only humans are using their API.
CAPTCHAs on an API. Never thought I'd see the day...
Actually, I specced this out for Delicious around 2007. I wanted to have the API be able to reply with "break this CAPTCHA/challenge/etc to continue" before actually applying the write/read/etc. (Delicious was very aggressively spammed.)
I like your zmqrpc idea. I had a very similar RPC/MQ-combination running for a while, using RabbitMQ instead of 0mq, Ruby instead of Python and JSON instead of BSON (switched to bencode later for better binary data support). But other than that it was pretty much the same mechanism.
edit: Your "Join the Team" page has an opening titled "Internships: Fashion Design, Journalism, Software & Statistics" but then in the description it's unfortunately only for "Fashion Design, Graphic Design, Statistics or Journalism".
The reason (as pointed out by zeraholladay) is that nmap scans per default only about ~1000 ports. If the service is running on a non standard port it will not show up in the default scan
Noooo! Don't give away the keys to the kingdom. :)
Instead, maybe say "no ping scan".
On the other hand, if you're aware of nmap and know how to use it to get past the first hurdle, you're probably more than capable of solving the actual challenge.
Is the purpose mainly just to prevent spam / completely unqualified candidates? Its rather trivial to do the post for anyone with dev experience so I can't imagine its much use to actually gauge their skills
That's what we thought too - this was the definite first pass, and we always intended to have a challenge/response type question for extra credit.
But we didn't need it - it turns out the kind of people that are intrigued enough to apply, and have enough ability to install a few libraries are likely great people.
I thought employers generally gave FizzBuzz during an in-person interview. Surely a 5 minute phone call from a halfway technical interviewer could provide a way better filter than FizzBuzz, and avoid wasted time by having woefully unqualified people come into the office.
There are lots of filters, if I ever end up in a hiring role I intend to make use of several. Someone may be able to talk the jargon well enough during a 5 minute phone call but I think they should always be asked to write code at the in-person interview stage, and if they can't do FizzBuzz when they're being hired to program it doesn't matter what magic they weaved during the call.
Right, the bar should be much, much higher for a programming job. Since there's no challenge in it, no weeding of applicants is performed.
To me, though, it's self-defeating to simultaneously accept resumes via email -- it shows there's nothing actually at stake. Don't they want only the smartest, most persistent candidates? It doesn't seem so to me.
It shows creativity and maybe they will attract less applicants, but for sure applicants who are a fit to their company, their culture and someone with the right set of skills.
