Hacker News Reader

Comment by nobleach | Hacker News Reader

Our recruiters discourage us from sending out "take-home" tests, but I have to admit, I'd rather see a comprehensive "can you build an endpoint that fetches data from other places - some in parallel, some in serial - and build a response?" type challenge instead of "can you reverse a string?" or "can you find the next permutation of this number sequence?". Yes, it'll take about an hour or so to pop something up on your GitHub. But it'll show me how/if you handle errors, if you add logging, if you write some tests. I get that not everyone has the time (or desire) to devote to this but... I sure do hate doing the "CS-secret-handshake" to make myself believe a developer can solve problems.

View on HN

Some random advice from the Internet, for what it's worth:

If you want to see how/if a candidate handles errors, logging, adding tests, etc. you should explicitly ask the candidate to handle errors, and add appropriate logging and tests.

Otherwise, you're mainly testing whether a candidate can read your mind.

The problem is, the appropriate level of error handling, etc. depends on context and if part of that context is in your head only, your test is sampling a lot of random noise.

That's only if I would refuse to talk to someone who DIDN'T do those things. I've yet to reject talking to a candidate that achieved the goal, yet left out those "nice to haves".

My point is they aren't "nice to haves" if you don't ask for them. They are "purely random to haves".

Ask for what you want. What's the worst that could happen? The candidate gives you want you asked for? Not a bad sign for a prospective employee.

Sure they are. This is the OPENING to a larger conversation. This is not, "get this right, and you're hired". I've yet to see anyone attempt it and NOT get it to work... the few that have put some quick logging and error handling were nice surprises and that drove the conversation when we got them on-site.

Agreed. We gave a test for an agency a couple of months back. Our junior forntend dev complained about a number of things that we hadn't specified (using typescript for example). I pointed out that it was a bit unfair to mark down on things that were unspecified.

   > ...can you build an endpoint that...

Wait, you're expecting someone to whip up an endpoint that pulls in arbitrary parallel and serial data sources, handles errors, has logging and also has tests IN ABOUT AN HOUR?

That's kinda optimistic!

How long would you expect someone to need to write code that makes a few HTTP requests (or read files or whatever other data source is specified), some kind of parsing or decoding (probably JSON) to get the URLs for more requests, and spawns a couple of threads?

Nothing about that sounds tricky or time-intensive to me in any language I've used very often. An hour sounds perfectly reasonable to me.

I'm curious where you're coming from here. What part of this would you expect to spend so much more than an hour on?

All your doing is testing if someone memorized the same APIs and libraries as you have, and has recently done whatever project you just did that's just like this (except it took you a week, and now that you know how to do it you think someone else should be able to do it in an hour). But your company already has one of you and doesn't need another.

In my case (the GP here) no I don't care WHAT framework/language the candidate users. But they DO have to know how to use a webclient of some sort. And any person with experience in any common stack should be able to perform a data fetch. If you can't do that, you're probably not a fit as that half of what our microservices do.

Regarding whether my company would like, or needs another me, you'd have to ask them. I believe they'd say they would like several more of me. And there's nothing wrong with that. I provide a good amount of value.

data fetch, in parallel: MOVDQA xmm2, XMMWORD PTR [esi+ecx]

data fetch, serial: REPNE SCASB

I also can use a webclient of some sort, which is handy for looking up instruction timings.

I was including time spent reviewing documentation there. I definitely don't have any of those memorized. I almost never write code without frequently consulting an API reference.

Am I misunderstanding you, or are you really saying that you expect someone to take a week to write a program that spawns a couple of threads and makes a couple of HTTP requests?

If it were only to take an hour then it's not a "comprehensive" exercise in the ability to solve problems as the OP desires.

It would then be an exercise with toy data that measures how smoothly the candidate conforms to the expectations of whatever framework they're using to solve hello-world-level problems.

"An hour" is a really short time!

> I'm curious where you're coming from here.

the GP is probably coming from some workplace that doesn't do exactly that same thing all day, every day, and doesn't know a framework for this from the inside out.

How to do a custom HTTP request on any language will probably take some good 15 minutes reading the documentation (if one is perfectly comfortable with its networking documentation), how to parse JSON will take at a minimum some good 30 minutes reading the docs even on Javascript (unless you are ok with eval). Discovering how to serve that endpoint is a multi-hour learning task by itself.

JSON parsing in JS is a single call to JSON.parse(), no eval required. It's been in the standard since ES5 IIRC.

Correct, I wrote it in Java, which was the most annoying implementation, but still about an hour's worth of work.

It would take at least an hour to manually test such functionality.

uh, I can write an endpoint that does that in about 15-30 minutes in node with aws amplify if I'm doing queries with no parameters are other funny stuff. The most time consuming part would be getting the project set up.

Do it, live stream it. Shouldn't be too hard.

It depends on what level of experience you are hiring for.

I suppose, but "an hour" basically means straight-up non-stop typing for something like this. It would be stream-of-consciousness coding like in a hacker movie.

That's more than just "flow" that they're expecting to see.

No, it really doesn't. Experience != speed.

> "can you build an endpoint that fetches data from other places - some in parallel, some in serial - and build a response?"

Years back now this is what we did when we were hiring, and then used it to jump start the conversation in the interview. Tried to keep it to an hour or so of work, but if someones interviewing at multiple places that can add up quickly.

I think your recruiter is probably right, unless you have some sort of outstanding place where people are lining up to work. Personally I refuse to do anything like it for interviews now, and I know a lot of others on the more experienced end that do the same. There's way too many places that'll hire without it to bother, unless it was somewhere like google where its sort of expected.

Sadly this is the current market. We're grasping at finding the best way to judge whether to bring someone onsite. Video coding challenge? Simple phone conversation? We've done all of these and they often go the same way, hours taken out of multiple people's schedule only to find that we should have weeded this candidate out at an earlier stage. (Not always, but often enough)

Take-homes are valid. Maybe 4-5 hours worth of take-home is a reasonable approach to seeing if someone is really a decent coder. Lots of companies will ask you to spend 4-5 hours in an onsite interview. Substituting much of that onsite interview time with an take-home exercise has its pros and cons, but it's not insane, and it's not exploitative.

50 hours is not reasonable or valid.

For one my first interviews out of school (justin.tv) I had a take home which I liked, but it wasn't a substitution for the interview time - it was more of a pre-screen for the phone screen which then did the same solve a puzzle while I'm watching you thing.

The take home went well and took an hour or two, but it was a well contained problem and fun to write. I didn't do well on the docs share screen which is largely a separate skill you have to prepare for and I find more stressful.

Early on the 'I'm watching you solve a math puzzle' is brutal especially if you didn't go to MIT/Stanford where you're pretty well prepared for how to succeed in the technical interviews. My school (RPI) was more harmful than helpful - they had no idea how the process worked so you mostly learn through failure. This plus a dash of imposter syndrome makes succeeding in these out of school pretty tough. Once you've validated your skills by succeeding and working somewhere it's easier - I'd guess because you're more confident in your ability.

I wonder how much engineer mobility is limited by the stress of these interviews. If you don't find them stressful you have a pretty easy way to massively increase your income in a couple years. There's a lot of value in just getting good at passing technical screens. I don't have a better solution to this, but it is frustrating. Lambda school's approach to preparing explicitly for it is probably a good one.

The "can you build and endpoint" stuff can be learnt on the job in a matter of days. Problem solving is harder to teach.

Also, an hour is ridiculously optimistic for this.

For your average node.js developer, no, that's not at all optimistic. Installing Express, and some sort of data-fetching library and setting up the routes. I'll admit, when I did the challenge in Java/Kotlin, it did take considerably more time to get the JSON serialization into POJOs set up.

So its easy because you've tackled this exact problem before? Is that what you are trying to select on then? Show me you've done this thing before?

Why is it wrong to hire a developer that's had experience in the exact field in what I'd want them to work? Isn't that a great deal of ALL hiring?

It's a bit like having a home builder job interview: "Have you had experience framing a house? No? Then I'm a little unsure you'd be fit for this job." It's not wrong for me to say, "no, you've never done this sort of thing before, you consider it too hard to do in an hour? You might not be the best fit"

Nothing wrong with it. Seems a little bit restrictive, if you already have code like this for your organization couldn't a relatively junior person work by analogy in much shorter than 1 hr?

Reply on news.ycombinator.com