I took test assignments when I was looking for a junior position. It felt fare, since I hadn't have much on my CV or GitHub and a test assignment was a way for me to show what I'm worth. And sometimes I could judge the requirements and expectations for the position much better than from the job posting. So, win-win.
It varies a lot depending on the company. Many companies give an assignment requiring 5-10 hours of work and then never get back / or give more detailed feedback than "Sorry, not what we are looking for" or they reject anything that does not match a very specific pattern.
Ideally, the hiring company should do a 15-20 min pairing with the applicant to discuss what exactly they are looking for and what could be improved in the applicant's code.
Exactly my point!
As someone with plenty of experience on both sides of the table, I can't see this article as anything but misguided.
I indeed use a single (and original) take-home coding challenge instead of whiteboarding during an interview. Let's look at it this way...
If you ever come across an interview process for a coding position where the candidates never need to code as part of the hiring process...run.
A take-home coding challenge has less pressure attached. Would you rather do in 20 minutes, with a bunch of interviewers staring at you, or would you rather do it at your own pace, in your own environment, where you can give it your best?
Would you rather work on yet another version of "fizz buzz" during the interview, or tackle something legitimately interesting and unique that (seriously, according to all my candidates) takes no more than an hour or two?
Actual field experience has proven: take-home coding challenges are one of the best, fairest, and most objective means of evaluating the technical skills of a candidate. Everyone can talk the talk, but you must have a way of evaluating who can actually do the work.
(Yes, we have simple-but-effective ways of making sure the person really wrote the code.)
Side note: one also research jobs, applies for jobs, and interviews for jobs on their own time. It isn't unfair for one to do a coding challenge on one's own time too. If someone really doesn't want to bother, then that's fine - there are plenty of people who care enough about the position enough to use a couple hours of their Minecraft time to complete a coding challenge. (For cryin' out loud, we have over two dozen sites where people complete coding challenges for FUN.)
I see a lot of articles complaining about the hiring process, but honestly, until one has actually interviewed dozens of candidates, made a few mistakes in the process, and seen how one's hiring choices panned out, one doesn't have much basis to make as definitive statements as found in many articles like this.
Actually, if we were to take all the "complaining about the hiring process" articles at face value, we'd be hiring the first Joe Bloggs who applied for the position, and giving gift cards as consolation prizes to everyone else who didn't get the job (seriously, that WAS one article's suggestion).
The hiring system as a whole can certainly be improved, but a lot of the unpleasantness is due to our having to screen for people who talk big, but don't have the skills to match. They show up in every batch of candidates, for every job posted, every time. (Yes, there are people with no coding skills whatsoever who apply for senior development positions.)
Same thing here, I've been an interviewee and an invervieer many times in the past.
As much as I like seeing a sample of candidate's code, I disagree that this is a fair thing to do. It's ok to give an assignment on a later step in the process, but it's never a good option to give it as an initial filter.
Well, we may just be coming from different backgrounds, then. I've learned the hard way, it is a critical part of the interview process. Granted, this is after I phone interview them, but I will never hire without it. In fact, no successful hiring manager I've ever known will; the ones that skip it invariably wind up with extensive mishires.
I have to call bullshit on this.
1) I worked at places where they did not have a coding challenge, live nor take home. Colleagues were competent and it was a great job.
2) I (and many others) would rather do it in 20 minutes with interviewers staring at me, rather than spend hours of my personal time working on a throw away project for free. This way, even if I fail the interview, I'm only out 20 minutes vs hours. I'd rather go to church service than do that.
3) I like working on interesting things, but I don't like working for free. This argument is the same as saying developers should always be coding, even in their free time, for the passion of it. And that's what take home assignments are. It's a way to offload the expense of hiring onto the candidate. It's no different than unpaid labor.
If you can't weed out majority of unqualified candidates (yes, some will get through, but some will also get through even if you have a take home test) by just having a chat about software development with them, then the problem is with the employer, not the interviewee.
I'll have to counter your points, unfortunately.
1) Every company will wind up with some decent programmers, no matter what hiring processes they have. That doesn't mean that doesn't matter. The perspective of one employee within the scope of his team doesn't correlate with the overall reality in the development field. It doesn't make your experience invalid, but your experience alone does not invalidate the broader scope. Chances are, you seldom encounter the mis-hires. (And yes, there are many developers I've spoken with who wind up working with people in development positions who actually can't code.)
2) And hiring managers would rather not have to waste 20 minutes taking to yet another someone who can't code to save their life. You'd be amazed at just how many hundreds of hours get wasted on that.
3) No one likes working for free, but you're not being asked to. A coding challenge yields no direct profits for the company. This has nothing to do with the errant "developers should always be coding" philosophy.
4) Your statement about how a decent hiring manager should be capable of weeding out candidates by "just having a chat" shows you have clearly never done hiring in any meaningful capacity. Any job looks easy to the one who isn't doing it.
Maybe you still don't agree, but I'm not just talking from personal experience; I've spoken to many hiring managers and software developers about this topic for years, and these have been common threads.
I'm torn on this. As a junior, unemployed, I liked take-home assignments. I had the time, and it was an opportunity to show my skills. However, when I was applying while working, I had exactly the problem you described. Three coding challenges in a month, on top of my regular responsibilities and other job hunting tasks, nearly burned me out.
I still prefer coding challenges to timed tests or algorithm problems (especially for a front-end role - it makes me question the company's judgment when their test has so little relation to the work). But it was hard enough for me to make time, and many people have a lot more hurdles than me.
No single solution works for everyone, so I think the only good answer is for a company to offer an option. Those with more experience or a great portfolio shouldn't have to build yet another to-do list app when they already can demonstrate their value in other ways. But that's harder to quantify into metrics, and opens the process up to more unconscious bias. It's hard to do it well!
Totally agree, it's all about balance. However, I still believe that nobody should receive a take-home assignment at the beginning of the process.
This is not a fair initial filter, but it might be ok when both sides are ready to invest extra time.
You are making a lot of assumptions here... Really a lot.
At some point the company needs to know what you're worth and you can't just know that by talking to the person for one hour.
To me assignments are useful when the process is well advanced and that you need to lift a doubt.
I don't think I'm assuming too much here.
If they need to see some code it's ok. I prefer to see the candidate's code too. However, I think it's not fair to ask a candidate to invest their time before both sides are sure that they are interested in each other.
This is indeed deadly simple. If the company comes after with their head-hunters, test assignment won’t take place.
If you are applying on the position—stay tuned, you’ll get the assignment. Because I personally want to see how you code what is needed for us. If it takes many hours, we won’t fit either.
What do you do when given an assignment with a skill you dont have. Note: You made it clear in the initial interview call you have no practical knowledge of the skill and also it was not in your resume but they go ahead to give you an assignment having 50% of the skill you dont have and was given 6-8 hours to finish. Do you do the interview assignment or not?
Good question, thanks!
When you're missing skill to complete the assignment and you made it clear for the company then I think what they are looking for is for you to demonstrate that you're capable of learning that skill on your own in a short time.
6-8 hours deadline is very tough in my opinion, but what can you do about it, eh? Those are the rules of the game, you have to follow them I'm afraid.
Would I do that? If I wanted the job I would do my best to complete it. Even if I missed a deadline I'll send it back anyway. I would tell them, that I had to learn a few things first of course. If I were an interviewer I'd respect that attitude.
Btw, if you learned something new while working on the assignment, it's not a bad assignment after all. It's better than simply wasting your time on making yet another standard task, right?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.