5 ms·

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 dat

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.

bengale 8y ago
> "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.
- nobleach 8y ago
  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)
crispyambulance 8y ago
> ...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!
- jrowley 8y ago
  It depends on what level of experience you are hiring for.
  - crispyambulance 8y ago
    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.
  - xvector 8y ago
    No, it really doesn't. Experience != speed.
- tene 8y ago
  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?
  - crispyambulance 8y ago
    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!
  - nobleach 8y ago
    Correct, I wrote it in Java, which was the most annoying implementation, but still about an hour's worth of work.
  - 8y ago
jmull 8y ago
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.
- nobleach 8y ago
  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".
  - jmull 8y ago
    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.
    - nobleach 8y ago
      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.
- collyw 8y ago
  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.
aetherson 8y ago
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.
- fossuser 8y ago
  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.
xvector 8y ago
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.
- nobleach 8y ago
  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.
  - peteradio 8y ago
    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?
    - nobleach 8y ago
      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"
      - peteradio 8y ago
        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?

bengale 8y ago

> "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.

nobleach 8y ago
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)

crispyambulance 8y ago

> ...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!

jrowley 8y ago
It depends on what level of experience you are hiring for.
- crispyambulance 8y ago
  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.
- xvector 8y ago
  No, it really doesn't. Experience != speed.
tene 8y ago
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?
- crispyambulance 8y ago
  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!
- nobleach 8y ago
  Correct, I wrote it in Java, which was the most annoying implementation, but still about an hour's worth of work.
- 8y ago

jmull 8y ago

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.

nobleach 8y ago
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".
- jmull 8y ago
  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.
  - nobleach 8y ago
    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.
collyw 8y ago
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.

aetherson 8y ago

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.

fossuser 8y ago
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.

xvector 8y ago

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.

nobleach 8y ago
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.
- peteradio 8y ago
  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?
  - nobleach 8y ago
    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"
    - peteradio 8y ago
      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?