I do disagree with the premise though. As someone who's worked in the tech field for 15+ years and has been on plenty of interviews, I for one would much rather do a short homework assignment than have to stand in front of a few people and white board shit in real-time.
Here are reasons why it's a solid idea:
1. Way more closely simulates a real work environment. I've never had a job where I get the assignment moments before I have to code it, use a whiteboard to write code, am severely time-boxed and have a group of people watch me work.
2. More inclusive. Your work stands out more when someone isn't making judgements based on looks, age, gender, etc.
3. If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough. People will spend weeks on an unpaid open-source project but then complain about 2 hours for something that might get them a great job.
Having said that, I agree with you also that the interview can be a great time to go over the homework and ask questions, talk about why a particular strategy was chosen, etc.
I would personally love to see more interviews go away from whiteboards and more towards homework.
For the brief stint that I did interviewing, I had candidates whiteboard after doing a homework assignment, but all I had them do was step through the very algorithm they had implemented in the homework using a very simple input dataset. None of them had any issues with the whiteboard, even those who were clearly very nervous/anxious.
Building software is hard enough as it is. I doubt making the coding tasks open book is probably not going to allow in many (if any) unqualified candidates.
Maybe I'm talking to more than one company and don't feel like subjecting myself to this absolute nonsense over & over. Maybe I'm just feeling out the opportunity without having to worry about solving a made up issue and hope it conforms to what the employee reviewing it considers good.
What other in-demand professions(based on demand vs. qualified candidates) make potential employees sing & dance, and then go through a full interview process on top of that?
Do accountants have to balance a fictional company's books or find the most efficient structuring of a fictional company's taxes across multiple jurisdictions before being allowed to have an actual conversation with a peer about the role?
a) setting up a git repo with working code in it (including tests, dependencies and whatever else) so I don't have to worry about inane(but taxing) decisions in terms of project structure/code style. Also, verify it works before sending it out to candidates.
b) including clear & detailed instructions on what is expected
c) given the test to current employees (blind) & timed them on it (allowing for the fact they know the domain & technology)
d) make it somewhat representative of day to day. i.e. I have 0 interest in spending time configuring and doing anything which is a 1-off task such as authentication etc..(unless the companies primary product is security/auth)
In short, make it easy for me to prove myself.
It sounds like you don't think much of testing, if you're expecting tests to be handed to you. Testing is hard! Writing good test cases can be as hard as writing the code itself. If your tests are inane, then you're going to catch the easy bugs and miss all the hard ones.
And when on Earth do you get clear and detailed instructions on what is expected? At least in my current job, I feel like half of what I do is turn vague expectations into crisp technical requirements. If part of the assignment is for you to write a function, I can't include test cases for you because I don't know what type signature you're going to pick for the function. This isn't an inane detail. In some ways the signature of the function is more important than the implementation: the implementation is local to the function, but the signature is going to effect the structure of all of the code that uses it.
Should have been clearer They should have tests to cover their code (not the code I'm going to right).. This cuts down on me adding testing libs needed, any setup, and laying down a pattern for their expectations(wrt tests). With expectation dev would add tests to cover their code.
> And when on Earth do you get clear and detailed instructions on what is expected?
On the job, I have easy access to the information/easy access to the people with the information. Not to mention personal relationships with the people I need to query.
My usage of 'inane' refers to things that a dev on the job won't be doing 99.9% of the time. Things that take effort & thought to setup(initial project setup) but don't really give any insight into whether a dev can write & architect code well. All the things a company already has in place.
I'm a qualified accountant, and have, during an on-site interview, been asked to update a company cap table based on some information about additional fundraising and employee grant transactions.
> before being allowed to have an actual conversation with a peer about the role?
I did do two coding exercises, though. In one case, the exercise was very fun, and I was able to use it as an excuse to work in a language that I didn't work often in. In another case, I really believed in the company, but I would only do something that took about 1-2 hours.
As an employee, I see it the opposite way. If a company is offloading interviewing costs onto interviewees in this way, then I am competing as a commodity and the overall offer is unlikely to be good. A company with this sort of process can afford to test everyone and pick up the 0.1% of folks who are geniuses that don't know that they're worth $150k+ at a salary of $60k/yr.
If I'm not imposing costs proportional to what I'm expending, I'm unnecessarily weakening my negotiating position and setting up the wrong incentives. This is why it's a good idea to get your customer service complaint resolved through tying up a phone agent, making a complaint on twitter, or generating a paper trail that concerns the "no regulatory incidents" department.
I've happily spent weeks on unpaid open source projects and I complain about it. Mostly because homework requires no effort or investment on the company's part and it's too easy to hand it out to everybody and then toss candidates' hard work away after it's submitted because they don't like your name or something.
These days I mostly ignore homework requests and point companies to my GitHub profile. I haven't lost any good jobs that way. Companies that erect hoops that make it clear that their time is massively more valuable than yours before you're hired are going to treat you the same way once you're hired.
I disagree that homework is necessarily more realistic. IME all homework assignments have been the same kind of garbage asked by whiteboard happy companies - how to reverse a binary tree, etc. Pointless crap that has no relationship to 99% of real jobs in tech.
When I was running interviews I organized a 1 hour test during interview that was as realistic to the job in question as I could make it. I truly don't see why that isn't the standard.
When my last gig got over I went through 10 places over a month and a week to find my next place. If homework was always only 2 hours each time that would be half a work week. The last homework I had to do actually needed some environment setup, but things had changed in some library etc. and I went through nearly 2 hours to setup environment I needed for the assignment. The homework was timed, I had 24 hours to complete from time it was sent. Somebody was sick that weekend and as a consequence I did not finish the assignment.
Supposedly applying for a job should take some hours to tailor make your resume, your cover letter and so forth, then some time to travel to interview and now extra hours to do homework. As far as might get me a great job it's been my experience that what it gets me is a job where people value getting things done but also having fun while doing it, with some foosball games and other perks littered about an open office all seemingly decorated by the same team working globally. There will of course be opportunities to determine the technical direction of projects and perhaps the company as a whole! etc. etc. Perhaps I am fortunate that all my jobs are great, but on the other hand if that is the case I am more likely to go for the job at the place that doesn't make me do the extra hours as opposed to the one that does.
on edit: of course people do complain about having sex infrequently but it is the infrequently they complain about, not the having.
It was a great screen for them and something to talk about durning the interview.
That said you still do need to do some coding during the interview though. We've had enough candidates bring in professional interviewers to solve the coding portion of our remote interviews that there is no way we would trust that the candidate actually solved the homework themselves. We no longer allow any remote interviews due this alone.
What if a large group of developers banded together and said "We'll only interview with companies that offer us a range of choices on the interview process, because we want to be able to choose option(s) that suit our strengths. We do this because not only because we want to put our best selves forward but also because this helps nudge companies to explore the space of various interviewing methods, which ultimately makes the companies better off as well because they get better long-term matches."
I think it is better for everyone this way. It is more accurate, it is less pressure and less demanding on the candidate, and it doesn't require an engineer sitting there asking intro-CS questions to a stranger instead of working.
Speaking from experience, shooting 1~2 very detailed hypothetical situations (i.e. 'homework') to a candidate 1 hour prior to their interview and asking them to think of responses to a few 'hard questions' that they will be asked to 1) answer and 2) explain their reasoning during the interview tends to work well. This usually reduces candidate anxiety, helps the evaluating committee get a better look at the candidate's approach to problem solving and validates (or not) their previous experiences, and improves the flow and time management of interview itself.
Note: I'm a senior recruitment manager within the corporate HR Team of a Korean Engineering & Construction firm
P.S. I really suck at writing on whiteboards, it feels like my handwriting transforms into one of an 8 year old.
e.g. If my thousand lines of code are being weighed objectively and fairly against a thousand other applicants' code, so be it. If they get bored of reading and pick one near the top that isn't terrible, that's bullshit. And if mine is the top entry, I'd better not get passed over because someone didn't like the color of my tie.
(Experience bears this out, though I didn't find out until much later into my tenure)
I think of jobs more in terms of relationships -- if we don't mesh, if we don't get on, then neither party will get value from the relationship and it's better to find out sooner than later.
Personally I like homework, because it allows me to show my strengths (actually writing code that is solid) without being "under the gun" in terms of interview pressures. I love being able to discuss the code I wrote and talk about areas it can be expanded and improved, and why certain decisions were made. In my mind, that process is closer to the job I'm often interviewing for than questions like "explain why Bellman-Ford uses v-1 relaxations"