The answer is NO! Unequivocally, NO. Just No.
Look, I'm not saying this is an easy topic. Here, just a couple reddit posts and a ycombinator post ...
For further actions, you may consider blocking this person and/or reporting abuse
Wow. I disagreee almost a 100%. I did those a couple times and never seen an issue. If you want a job, then be prepared to do what's right to get it. Yes, getting a job is often proving you are worth it.
This sound lazy to me. There are a lot of dev who aren't even good at what they apply for. Its not just caring. A diploma does nothing in life. I've seen dev with doctorate in programming that are worse than people with absolutly nothing.
If you apply on a 100 jobs, then its your problem for doing so.just be ready to get a 100 calls. Working on your career require sacrifice and everyone who has been succesful can relate to that.
You can't skip testing and just determine with an interview and a CV if someone is good. that's almost impossible unless YOU don't care.
Straight to the character attack. Jump to the accusation that I'm lazy.
No, I'm not lazy. I've worked since I was 17 to build a portfolio, experience and a huge backlog of code. You can work for free if you like but I have enough under my belt and respect myself too much to be asked to perpetually put in days of free time just to prove what I've been proving already for over a decade.
Edit: spelling
Here is a point of view.
Thanks for the insight!
"The huge backlog of code you are referring to is probably owned by other companies..." which is a fair statement. However, the word "probably" and the words "is always" are not the same thing. Just because something might be owned by another company doesn't mean it always is in every case under every circumstance. Therefore, blanketing the entirety of cases as always illegal eliminates the possibility of cases where it is not illegal and would save an honest and hard working developer a lot of time and trouble if someone would care to look at his past work.
"Open source projects might be useful and they might not be". Absolutely true. You say usually it isn't. Fair enough. Under what circumstances are they not useful, then? Perhaps a better question, under what circumstances ARE they useful? Do we have any data representing the number of people who have open source projects or contributions to such and how often those materials are viewed and disregarded for a job?
"The experience you have with other companies is not visible to others." Again a fair point. My knowledge in the law is limited to my own country (and even then I am no lawyer) so I can understand legal limitations. Does this apply to colleagues? Does this apply to 100% of the cases you encounter? Again, is there a blanket course of action here along the lines of "Well, in 90% of cases, I can't even ask a previous employer for a reference, so I may as well just not try"?
Regarding the time consuming task of reviewing a problem you're not familiar with: It feels like you're passing the hot potato over. Anything you're not familiar with is difficult and time consuming. Anything worth doing is also often the same. Where do we cross the line of "It's too difficult for me so, here, let me make your life a bit more difficult instead of making my life a lot more difficult"? Not that it's the wrong thing to do, per say, but let's at least articulate that. Furthermore, what is to prevent employers from creating arbitrary tests that end up having no relation to the finality of the job? I can count a great deal of times I've participated in and heard of tests being taken where the test ended up having nothing to do with the job. The employer could not formulate a proper test, as much as the employer was convinced they had, and the developer wasted time on a test that did not directly match their skills to the job they actually did. How do we navigate that?
Your statement regard a non-coincidental relation to high quality co-workers and programming exercises: Do you have any data to support that statement outside of personal experience? Do we have some form of industry data that proves this to be true? Because, personal experience to personal experience, I can argue against that.
"Companies that require programming challenges want to see if you really want the job" and, here, I think we've crossed a line. Indicators of wanting the job are not solely willingness to do extra work, put in extra hours or do other types of "grunt" work, especially without pay. Asking someone to go the extra mile with no guarantee of a job at the end and no compensation is, in my personal opinion, disrespectful and an indicator of what I will be asked to do in this company were I hired. Just as a company wants to avoid wasting their time, so too do developers. I literally do not have enough time in the day to accommodate all the dog and pony jumps I have to do in order to prove to anybody that I want a job. That has nothing to do with my desire for that job. Furthermore, for developers who have spent years, perhaps decades, going the extra mile, it gets tiresome to have all your past work thrown away before entering the gates and asked to start from scratch. Imagine waking up every day and having to take your drivers test all over again before you can drive to the mall to get your groceries. That's what it feels like.
If the company has no use for whatever programming challenge I do then I should not be asked to do it. Perhaps you meant there is usually no technical implementation that provides any business value to that company if implemented. It's an exercise in demonstration of desire and skill but that's it and why should the company pay you for that. That seems more clear to me.
I can understand that point of view. Why pay for something you're not going to use? I think my previous statements generally touch on this.
I think the statement "If you're not willing to do my test then you don't care" is unfair. I care. I care a great deal. Anybody who has a family to feed and needs work cares. Limitations in ones life and ability to maintain a full time job, family responsibilities and the grueling process of interviewing cannot always meet your demands but it is not a directly a cause of a lack of care.
Edit: Spelling and grammar
Well, I believe that we do agree on one thing: it would probably be an unwise choice for you to work for a company that asks for programming challenges... which, ironically, makes the programming challenge a great way for the company to screen people who are going to be a poor match.
It would probably be unwise for me to work for someone who cannot be bothered to answer genuine questions about the reasons they believe something. This speaks volumes.
I do not enjoy coding interviews and I agree that it's on the developers themselves to fix this problem. However, I disagree with the solution this post promotes.
I have no problem with the initial code screen test. That test is an exchange of your time to prove that the company should provide multiple dev's time to interview you in person. A simple, fair exchange. If you're overbooked due to tons of programming tests, you over extended yourself when accepting to move forward with all of the companies at once. Quality over quantity means choosing the jobs you're most interested in first, and then coming back to others if you're still looking.
My biggest issues with coding interviews is the cookie cutter whiteboarding questions we ask developers to complete. I think whiteboarding is great for showing a candidate truly understands code, but as developers we need to spend more time in choosing the questions. Instead of selecting from a website or a book, we should consider the challenges we have faced in the job recently. Boil that challenge down into its most basic form and create a question for the candidate. Now we have an interview that reflects ability and aptitude for the job at hand.
Even better than whiteboarding is sitting down at a computer and pair programming the problem. That lends itself to the candidate sharing the process they are going through, and limits the intimidation of standing at a whiteboard and being judged by someone you don't know.
Thank you for a high quality response. Honestly. It's refreshing to hear someone who, although disagrees, does so with some effort and thoughtfulness behind their disagreement.
I think, overall, we could probably debate the issues around the tests themselves, how they're implemented, whether I've overextended myself in my example and so on.
You have some great points about how these tests could be properly structured, based on your experience, which I'm inclined to agree with.
I feel that there's a fundamental layer of this whole thing that we don't often talk about, though. The developers who discuss this topic often jump to the "We should or should not have these tests and here's X reasons for why I believe this" and that's fine.
But these kinds of tests were not standard even a few years ago. They're not even standard across the world. To me, that seems to indicate that there's something else going on. Why have these kinds of tests been introduced and why are they becoming normalized? Instead of asking the how, ask the why.
What points/factors led to that first company sitting down and talking about how they can't hire good developers and they end up deciding that a coding challenge (insert your nature of that challenge here) was the way to solve that?
What kind of expectations were broken and by whom? Do developers consistently under perform and lie about their experiences? Do companies consistently set their expectations too high?
It just feels like we're focused on arguing about the tests themselves but we're not focusing very much on the reason they came to be this way in the first place. These tests feel like an answer to a serious problem and I don't know that we're articulating that problem enough to tackle it properly.
Does that, at least, feel somewhat properly directed? Is that something we can agree on?
I always liked the "we don't do tests" scene from the 80's movie Dragonslayer....
I don't think a coding test shows anything worthwhile when human factors are really what makes or breaks the deal.
During my recent job search I had two "cool" tech companies have me waste time doing their coding tests. I did a good job on both of them and they called me in for a face-to-face and seemed like they were very interested. However, when I got there, once they figured out that I was over the dreaded 5-oh, buh-bye within 30 minutes. So, they wasted my time and, I assume, theirs.
Yeah that is absolutely wrong. I might try and tackle the ageism problem in the tech industry with another post/video.
In any case, your point, in this case, is wholly seen. A code test was pointless. All they had to do was ask how old you were to reject you instead. So much time saved, right?
In the US they can't legally ask your age other than "Are you over 18?". They can't ask about race, religion, etc either, legally. This leaves companies using other tricks, such as length of resume or a name, to guess at it. I suppose in my case their guess was wrong, probably by about 10-15 years low.
But, tests are essentially a waste of time because human factors (legal and illegal) will outweigh any testing. If the person looks good on paper and sounds reasonably intelligent on a phone interview, bring them in and talk programming with them. Don't jerk them around with homework or trivia quizzes. Just have a conversation.
I have really mixed/negative feelings about interviews in general. I find so much discrepancy between what I am being asked during the interview and what I am being asked to do in my work that it stuns me. Simple example that I have been through many times:
During the interview, I am being asked all sorts of questions like what is SOLID? What is DDD? They ask me to design an auction system etc. I get the job and what do I do? Sit in the logs, trying to trace a race condition or trying to hunt down a fronted bug with a scrollbar appearing only on Safari. Well, all that knowledge was really needed for the job, right? Your company does not even implement DDD...
Coding challenges are just as useless. I mean I had to write merge-sort algorithms, only during my studies and on interviews. I could actually ask my professors to rename their courses from "Introduction to algorithms" to "Basic interview questions".
I think developers should be given access to some parts of your code and asked to fix/refactor some code for money. They would submit their PR's for code reviews. If you, as an employer, would be satisfied from their work then a job contract would be signed. You are not buying a cat in a bag and they do not have to do useless things for free.
The code challenges are there to test your capability as a coder and to see if you are serious about getting the job in the first place. it also gives the hiring company a good vibe and confidence of the person they are hiring.
In short, it's a way to test your intelligence level, proving to them that you are not a lier and you are really good at what you do.
Let's stop here for a second and think outside the programming world! let's imagine a doctor, lawyer, engineer or even a builder. After 10 or 20 years in the business, no one would ask them to take a test or prove themselves simply because they have demonstrated it.
Why as a programmer I always have to prove it? to me, I find it insulting and degrading because it shows that they have no value for your work experience or the time you have spent working and learning about whatever language you have been working on. instead, they are putting all that aside and make their judgment based solely on a test that is 2 hours long or less! that's absolutely absurd and ridiculous.
you may be nervous, have anxiety, depression ...etc and didn't not performs well. That is it, you are not qualified. How ironic is that? it's like treating you like a machine rather than human.
If all programs stop accepting code challenges and get treated like humans and refuse to be part of this madness then things would change, again! think about other jobs they don't test people like that!
What is the point of PROBATION period? ! it's a risk that both the hiring company and the employee are willing to take to work out their differences.
That's my thoughts on this, Happy coding.
I agree 100%. These tests are always a disadvantage to developers that have years of experience behind them. Unless you are a super nerd you don't read the entire technical documentation which is what you have to do in order to pass a randomly generated set of questions on an entire framework.
When I got my contract over a 25+ year career I was interviewed by experienced managers and colleagues that asked questions that mattered. The type of questions focused on the day to day details of the job. Not on syntax. Syntax is bullshit. One computer language out of the 25 or more we have to work with now on the average.
This is a clear attempt to purge experienced developers from the work place and supplant them with continuous inexperienced and cheaper workers. You didn't score high on the test therefore you are not worth what you built up over your career. The only people that support these tests are the people that want to exploit and cheapen the industry or who have made money as gatekeeper opportunists create and entire business based on testing and convincing business owners its a smart thing to do.
It's very funny how many people defend coding challenges when NOBODY else does these sort of things to get hired. Are analysts asked to work on Excel spreadsheet? Mostly not. Are managers asked to "manage" something? Nope. Are engineers (the real ones) asked to design a functioning bridge? Nope.
And the reason is that all these things are basically worth nothing: the example of the guy over 50 speaks volumes, I bet that he wrote some of the best code they've ever seen, but guess what, it would have never worked out.
They hire you if they feel like it, regardless of what you can do (and someone has to show me some scientific results since you state that "this is the only way") in a coding challenge.
Google has basically destroyed the basis of the modern hiring industry by simply saying: "We've interviewed so many candidates and hired so many people that we can say that a degree is worthless".
What the people defending tests are saying is that even if the demonstration of having spent at least 4-5 years studying hard and PASSING TESTS is worthless, their 90 minutes test is much better at filtering people out!
This is one of the biggest logical fallacies ever, and if you fall into this one, than I'm sorry, but you don't understand Type II errors and those are important in our profession.
Coding challenges are bs. They do not work. The dev i replaced aced the coding test. His code was so bad after 9 months hee was fired and i had to rebuild correctly due to a "simple" feature add. I am a dev with 40k hours in the industry and id rather code something useful for the world than waste my time playing the developer test lottery. Tests are good for kiddos but im not in college anymore. Imho if an employer cannot invest the time to review my massive github portfolio, job portfolio or even look at the visual code graph of time ive spent coding on my coderrank, theyre not for me theyll just use me as an object and throw me away when the project is completed!!
I could not agree more. It's also pleasant to see opinions where we (the developers) are also held responsible for these things when it's appropriate for us to be called out on it. Your statement of "buying into the fantasy" is definitely part of the problem here.
For me if company uses coding puzzles in hiring process it's like a red flag: "This company is totally incompetence", so, I'm professional and there is no reasons to work with lamers.
Just to chime in a bit late. I've noticed that coding challenges are more common with inexperienced star ups; however, I know some large companies like Google use them as well. I've interviewed with high profile government intelligence agencies and NASA contractors and have never been asked to take a code screen. Normally, when I'm asked to take a code challenge I object and count it as a loss. When a company asks me to take a code challenge my first thought is that they are amateurs, it may be a bit critical but that's the vibe I get. If you're a good manager and you know your stuff you should be able to tell if a person is full of it or not by the way they speak and their GitHub. GitHub, in my opinion, speaks louder than any code challenge. Personally, I've met multiple 5-10 year vets that have done great on code challenges but don't understand what an enum or abstract class is.
I agree, but there's also the chance someone doesn't want to spend their free time releasing code on GitHub, and that's another way to profile people in the wrong way.
Let's work at a simple, real problem together, but only after we've decided that is likely that we are a good fit on all the other things. And I bet I can filter out those "vets" you're talking about by just talking to them, I don't even need to see their code (that in coding challenges is usually an imperative mess, and nobody should code like that in real life).