This saves us a huge amount of time and I don't feel it's overly burdensome on candidates.
I do. After doing a couple of these "2 hour" projects from companies I have a suspicion were not even really serious about hiring and not even receiving a courtesy rejection email I swore off them forever.
These days I just point the company to my github and am explicit that if that isn't enough to grant me a face to face I probably don't want to work there.
I responded back, that's billable time there. That would require me to take PTO at my current job, and do your work unpaid. And that, I will not do.
I kindly told them where they could put their job. (They still advertise jobs on the monthly, but they seem legit aside that onerous 1.5 days of work. And no, I won't mention whom. Hopefully they'll rethink their policies, but alas..)
Yeah, I did ask around in their area with fellow engineer-y types. They are a legit company, and the webapp wasn't a way to get free work. Think of it as a standards approach, rather than bulletpoint resumes that verge on untruth.
To be honest, I'd prefer they have a sit-down with me. They can do their fizzbuzz or linked list test, but I want to get a feel of the problems they're fighting with. I've always liked deep technical discussions, and how I would do it vs how they would/did it. It's a bit more subjective, but I would think that discussing technical aspects and asking how I (interviewee) would do it.
I offered an IoT project Ive developed myself in lieu of it, so they could comment on my code quality. They declined that, and wanted their webapp.
They're missing out :) Although I've an interview with GitLab coming up. Everything I've seen how they operate and treat their people is just awesome. Regardless if I'm a good fit for the position they're offering, I still think highly of them. :)
* Failing outright to do anything even close to the requested task
* Not even basic error handling
* No tests
* Using generated code where it's not appropriate, or not bothering to implement e.g. catch blocks they've generated
The instructions explicitly tell candidates what we're looking for, so it's not worth chatting to someone without doing this filter.
Ghosted.
I'm applying simultaneously to tens of companies, if you insist I can send you a link to my repositories with all take home assignments I've done so far.
2 hours is not unreasonable for a take home project with the entire internet at your disposal. People need to be motivated to join the company they're applying to! (Anything more is definitely unfair for the candidate and doesn't scale well when reviewing code)
This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use. It's pretty common for algorithm tests to be an hour long anyway.
So many software engineers have it backwards. Companies don't work for you, you're not even in the door yet. Unless you're a vp or principal engineer with a stellar bg, your tasks are replicable and most employers aren't going to be drooling over to get you on board as entitled / piss-poor attitude is going to cause more friction than it's worth.
I refused a homework project for one firm[1]. It was a highly specific problem that only made sense for one specific version of an app server, and was really a lot of work with some tricky edge cases. Call me entitled, but after I made sure I understood what he was asking, told the interviewer where he could put his homework.
I think it is important to keep a sense of the power dynamic. It is really easy to start moralizing to the powerless (here, employees) when they do find themselves with bit of leverage for a change. Not only is it a bad look - punching down is for insecure assholes - systems break down without feedback and (sometimes) pushback.
[1] Well known, I'm not naming names because it probably was a fluke.
Maybe the guy who wants me to volunteer 2 hours of my time before deigning to have a conversation with me?
>You know how burdensome it'd be to verify that your repos were fully yours
I've never interviewed anybody who lied about the provenance of their repos. I'm pretty sure if I did, it would come out in a 5 minute conversation during the interview.
If one or two gifted liars slipped through the hiring funnel into the interview stage before being found out I wouldn't view it as a tragedy.
>This notion that 2 hours is a lot of time, well plenty of engineers would rather have that than waste a few months memorizing algorithms they'll rarely use.
2 hours is fine for an interview, but it's way too long to spend on a speculative application for one company.
So... you limit yourself to no more than 4 hours effort applying to any company? Doesn't that limit your choices greatly?
I don't find it limiting, no. I am only very rarely asked to jump through a bunch of bullshit hoops.
Regardless, you're going to have to put in time unless you're already trusted by one of the seniors/leads/managers.. if that's the case then there's no coding assignment.
If you're interviewing at 20 companies concurrently you should probably not interview at so many companies at one time and narrow down who you would most likely want to work for.
If they seem like a good prospect then you can signal your seriousness by granting a face to face interview / test.
By throwing out homework assignments (which cost you 0) you are signaling either that they do not seem like a good enough prospect to be worth your time or that you simply view their time to be worth vastly less than yours.
Yup, that's what I will do occasionally too. If the phone-call goes well, I'll invite them onsite for that coding task... no algorithms. I like being flexible with them, if they are more comfortable doing it at home due to scheduling, they can hack away at home.
>By throwing out homework assignments (which cost you 0) you are signaling either that they do not seem like a good enough prospect to be worth your time or that you simply view their time to be worth vastly less than yours.
I generally stick with working at start-ups. I need to know that the engineer I'm bringing on can handle high-pressure situations when we have to deliver milestones. Which I can totally understand why some potential employees that I've handed this assignment to become upset / flustered. But it's a good indicator if they don't complain at all and do an exceptional job, that they'll generally do well and at the very least be open to critique so they become a better engineer.
These requirements are absolutely not appropriate for more established/larger corps just as start-ups aren't for everyone.
I'd be happy with that if the projects looked they were yours. I can count on one hand the number of candidates who have had GH profiles, and even fewer with anything worth looking at. All I really want to see is a few examples of coding style and basic thinking.
To me, being an engaged participant in the open source community is a massively positive signal, even if it's just reporting issues and the very occasional PR.
It’s not that it’s 2 hours, or four. It’s that you’ve given two hours to twenty people and so have five other companies.
* Cheat
* Fail to follow simple instructions
* Write no tests for there code (even the given examples!)
* Just horribly fail to implement an algorithm
All in all, it's just a filter to be used before proper face-to-face interviews.
Just curious, do the instructions ask for tests? If one of these "programming quizzes" asked me to implement algorithm XYZ, I would follow it to the letter and implement only the algorithm.
we give them a couple of examples (input, output) pairs - surely you would at least run your implementation past these, right?
Well, I've been on the fence on this one. With imperative languages, testing is pretty much a requirement because of side effects and scope-creep (nahh, throw it into global).
Tests can be a good sanity check for simple checks like "I fixed a bug where X is supposed to give 22. Lets verify that"... But the problem is the tests are then code that can update and rot as main code changes occur.
I've preferred a more functional method. I don't want to test - I want to prove a function handles its inputs and provides the correct outputs. Unless there's a good reason for state , I prefer keeping functions clean. And even then, with state (say, a tally function for bandwidth), I prefer to have the variable updated with its own function. Keeps clean/nonclean separate.
Now.. one thing that's absolutely not acceptable is not commenting code. "Magic sequence in perl doing 6 things unintuitively" is not code comments. :(
really, though, if i'm implementing an algorithm that i've never coded before it would seem strange not to write at least some kind of verification of its correctness.
comments can be language dependent - perl yes, java maybe (on an API, definitely) - and situation dependent. i wouldn't care about comments on small amounts of code with good variable names and sensible structure, for example.
edit : also apologies for the formatting, i hate typing on a phone!
Comments are good, but what's aceptable as a comment is entirely subjective to someone's competence in the language in question.
For example, if you can't look at a Schwartzian Transform[1] in Perl and understand what it's doing, if not immediately than after a moment or two of looking at the steps, then you do not actually know how to program in Perl, you're just muddling your way through. Nothing in the transform is special, and if you are confused by anything in it that's the equivalent of being confused by arrays and simple array syntax in C. A comment of "optimized sort on computed X attribute" should be more than enough, but to anyone slightly unfamiliar with Perl it will seem woefully inadequate.
If your funnel spits out 'surprisingly' shitty candidates then it's probably not the best funnel.