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.
By the way, loved this post of yours!
dev.to/lpasqualis/5-reason-why-i-l...
Well, I can't really control how you feel, but I can control how I spend my time. There is such a thing as a point of diminishing returns in this kind of written interaction in a forum like this. I'd love to continue the debate over beers someday, but in this format, we could go on and on forever. I wanted to provide my point of view. I am not interested to convince you that you are wrong and I am right. In fact, I don't believe there is "wrong" or "right." Interviews are designed to assess a good match on both sides. Your stance against programming challenges does just that, which is great for both you and potential employers.
I agree. An unwillingness to communicate ideas, hard line or not, and debate the reasons for those ideas is not just diminishing returns, it solves nothing and exacerbates the issue.
Thanks for your time!
Alright, you had some interesting questions and I am going to give an answer. Again, my intent is not to convince anyone, just share a point of view:
Yep, and that's why I mentioned that I ask the old company if the interviewee has permission to show it. If they do, there is no problem. So, I don't dismiss it at all. The other issue with code samples is that it is very difficult to know if the person applying for the job wrote it or not. When I ask questions about it, they can claim to not remember the details. Instead, with programming challenges, the candidate could ask somebody else to do it (I've seen that a few times), but they won't be able to answer questions or use they "I don't remember" line.
They are useful when: (1) there is a GitHub account with a history of check-ins from the candidate, (2) when the candidate can answer questions about the code and (3) when the code is interesting, complex enough without being too obscure and easy to test.
It depends on the country, but in the USA you can easily get sued if you give negative feedback on somebody who is calling to check references. Many people simply decline to answer. Additionally, it is very difficult to know if the judgment of the person you are talking to when you check references is applicable to the situation in the new job. Sometimes it works, and most of the time is kind of inconclusive.
Interviewing candidates is an enormous time investment for an employer, and finding out if the job is a good match should be both the candidate and the employer first priority. Also, it is not all about the time investment (although, that's part of it), it is more about the accuracy of the investment.
A good programming exercise needs to be a tiny version of a project that a candidate would have to work with. I cannot comment on the quality of other company's programming exercises. If they are generic "reverse a linked list" then they are a waste of time, I agree. The exercise should be very much indicative of the person's ability to do the job.
Well, I've been in the business for 30 years and interviewed people for the past 20. In my experience and the experience of many other people I trust, that was the case. I did not run extensive studies to prove this point.
I think that people who want to join a company will find the time. People that want "any job" won't. That's the difference.
Well, but that's "life" I am afraid. Changing jobs is challenging.
I understand that, and that's why I don't give any time constraints to programming exercises. People can do in their free time, whenever that is. If it takes 3 weeks, so be it. I stand by that choice for the reasons you mentioned. I wrote about this extensively on my blog.
Well, you can choose to take that stance. I never heard of any company that does that. I cannot imagine that it will ever happen. The reason is simple: a company is NOT serious about hiring you at all until you demonstrate that you are the right person for the job. The exercise is meant to assess that. Until you demonstrate that, you are a stranger with a piece of paper claiming to be a programmer. They don't know you. If you expect to be paid to demonstrate that you can code, I am afraid you are going to be disappointed.
I didn't mean it like that. Might have been too fast.
Some sort of test is necessary or way to fibd out someone is good or not. I've hired people that looked and talked their way into it, to find out after the fact they were no good. Even people with 15-20 years of experience.
We ask for a test when we can't be sure of the potential of the candidate. There are devs that are pearls out there that are either too shy or really bad at interview. This apply to them too when they have no way of showing off something they did.
Its not always necessary but it surely is often.
Sorry for the harsness of my first comment. Pretty dure you aren't lazy. Taking the time to write this article is a proof of that.
I appreciate the clarity.
You're absolutely right in that I cannot deny "developers" make their way into situations they don't belong in. Someone who can properly verbalize their way through an interview is not the 100% positive indicator of their skills in the field. No argument there.
To posit a counterargument, references, contributions to open source, personal projects and the like should be heavily considered in such a case.
I think respectfully discerning when a test is necessary versus when it is not would go a long way towards improving the situation. At least if not to make sure you are not potentially "scaring away" awesome developers because he/she is not keen on being tested. Again.
It sounds like that is the approach you take. Choosing when to employ a test as is necessary instead of a blanket requirement. I applaud that.
It still feels like there's an underlying factor that is not being addressed. At least not articulated well enough to be addressed. Why did this interview gate become necessary? Where did we fail, in the industry, in such a way to warrant this?
Your argument is one I have heard before, and rightfully so, where someone has presented themselves in a manner that seems befitting of the job and you only found out later that it was not an accurate representation of themselves.
I feel like there are some open questions even there: Are we certain that developers consistently misrepresent themselves (perhaps deceitfully for selfish gain, usually to make money with low effort)? Are we certain that employers / interviewers are not misrepresenting the job requirements, perhaps? Are we certain that we are asking all the right questions during an interview process (bar an actual test) that might easily flush out mismatches? Are we diligently following through on things like checking references and talking to an interviewers colleagues or past employers?
It feels like, to me, both sides make a bad situation worse and that, in my opinion, is an indicator that the real problem is not addressed.
Maybe that opinion is wrong. I would be happy to be corrected on it.
Yes. Absolutely.
The answer to the main question, you already answered it: caring.
There is too much people that just doesn't care. Being a coder isn't just something you can be good at if you don't want to improve and work on yourself.
School and diploma just give a hint of what the real world is. There are tons of self-opportunity out there that anybody can do to get that experience without having a real job.
Unfortunately, most of the candidate just don't and makes us cautious about the potential good dev.
I totally agree with having something to back you up with project or open-source participation.
I hired one dev that had zero education in the field. He would just love to code in his basement all the times. This guy was 100 better than any other coder I had that went to university. All that because he was caring and living it.
The best dev imo are the one that love their job and that need to self control themselves to not stay and continue to code and improve.
"You can't skip testing and just determine with an interview and a CV if someone is good."
I can. It's not that hard. Just talk about programming. BS artists and the well rehearsed trivia masters will reveal themselves rather quickly. Likewise, good programmers with a passion will reveal this as well.
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.
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!!
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.
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).
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.