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 and read some of the comments.
https://www.reddit.com/r/programming/comments/8dbv04/the_latest_trend_for_tech_interviews_days_of/
https://www.reddit.com/r/webdev/comments/8deo8l/the_latest_trend_for_tech_interviews_days_of/
https://news.ycombinator.com/item?id=16874015
One thing you cannot tell me is that this topic is not polarizing. It absolutely is.
Let me see if I can explain a view that I don't think has truly been addressed. To get there, let's work through some of the arguments.
From the perspective of an employer
I've been in the "employer" shoes. As a developer, I've also had the opportunity to work with a great deal of awesome developers. As well as some less than stellar ones.
If you get a developer on board who is either extremely inexperienced but somehow "duped" you into thinking they were more experienced OR someone who maybe has the experience but just really doesn't care about their job (it's just a paycheck) OR (and God forbid) you get someone who's in both sides of the spectrum...
I don't need to spell any of that out.
The number of hours that get sunk and lost can be innumerable if you have a developer who doesn't care about their job. Look, I'm not saying be a super passionate developer evangelist who does it day in and day out every single waking moment of their life. I'm saying, CARE. Care enough to try and be good at your job during the hours in which you are being paid to be good at your job.
Where did that sense of honest ethical workmanship go?
I've diverged. The point is, as an employer, having experienced developers of these sorts, I know the cost it takes on the colleagues and the company. Hours lost means money lost. There's also a demoralizing factor to that.
Of course, the biggest price for any company to pay is failure to exist anymore. It takes only one person to deceive or not care enough to create that scenario. Just as one person has the power to make incredible and positive change.
To this point, therefore, I am not shocked that employers ask you to complete a quiz or a code challenge so you can at least prove you know something about what you're applying for. I totally understand that.
The arguments against it
I'm a dad. Fresh. A few months old now. I have very little time. So let's do some math here.
Imagine yourself in a job where that job is no longer sustainable, for you, maybe because the company is going under or because you're going to get fired or maybe you just hate your job. Doesn't matter. You're exiting.
Time to go look for work!
So you decide to play the numbers game. The more places you apply to, the better your chances of getting into one of those places, and you are fully aware of quality vs quantity. That means you're not just going to robo-market yourself to everywhere. You will take the time to read job postings and listen to what's being asked from recruiters but you will also make sacrifices of your time to apply for as many places as you can.
That's a great start.
So you start applying.
What happens next? Some interest! Finally. So you get asked to do a test. You've got 48 hours to accomplish it and the test usually takes somewhere around 2 - 5 hours.
Cool, your first test. You sit down and crank it out in a night because you're so pumped and hopeful. You submit it. Now you have to wait for the review.
The next day, another person shows interest. Things are starting to pick up now. You get asked to do another test. This one has 3 days to complete it and, again, 2 - 5 hours to accomplish it.
The day after that you get TWO people who are interested and one asks for a 5 hours test and another for a 2 hour test but you have to do the 2 hour test right away. That same day, the first company you applied for would like a one hour call with you to discuss your test submission and chat with you about the technical reasons you chose to do it.
Ok it's a bit of a crazy day, you have to do all this while still managing to be productive at your normal job, if you can manage that. Doable. Not the best scenario, but doable.
Keep going, man.
What does the end of your week look like? Between the tests and interviews and maybe you're doing multiple interviews and maybe you get flown down somewhere for in person interviews. Do you know how much time you spend in a month doing tests? Let's take just the tests.
Let's say you did 3 tests a week, each taking you approximately 2 hours, and you did that for a month. 4 weeks in a month and each week had 6 hours worth of tests. That's 24 hours of tests. That means you've now given over 3 full business days of FREE work.
Let's say you make around 3,000 a month. Let's say 20 approximate working days in a month. That's about 150 bucks a day. Pre-tax.
You've thrown away 450 dollars of YOUR time.
That's not to include time with the regular interviews, chatting with a tech team to present your solution like you're some kind of a puppet who puts on a show, time taken to prepare your presentation, and so on and so on and so on.
The last time I checked, the way capitalism works is that there is an exchange of something between two parties, typically where one gives you money that puts a value on something you offer in return. An exchange of goods, if you will.
If a company paid me 450 dollars, they'd damn sure expect something back, and rightfully so.
What can YOU expect from a company back when YOU spend YOUR money on them? Are you guaranteed to get the job at the end? Absolutely not. If anything, and I've experienced this, you might submit your test, a better candidate (so to speak) comes along and they fail your test based on some stupid and arbitrary point so they can disqualify you without feeling bad that they wasted your time so they could hold out for that someone better.
If you're someone like me and you don't even have the time to do a 2 hour test, you're missing out on potentially a good developer with lots of experience who won't bother to do your stupid test. Then you can sit there and complain about a shortage of good talent.
We're focused on the wrong things
Look, here's the way I see it. Employers are trying to answer the WRONG question. Developers are answering the WRONG question when they accept these tests.
What's more, developers are very much part of the problem. The developers who don't care or who lie, in particular, or maybe have grand delusions that with minimal effort they deserve riches, and there are plenty of those around, they're all part of the problem.
Employers are trying to answer the question of "How do we ensure we hire the best developers we can possibly get that fit in our company and have the skills we want?" with the answer: technical tests.
WRONG QUESTION
The right question is: "How do we make sure that as many developers as possible have the training and qualifications they need to be productive in ANY company? Anywhere. Ever."
In other words, what the hell is wrong with the developer ecosystem that produces such disparate polarities of developer quality that employers feel it necessary to make us ALL jump through a dog and pony show of hoops just to have the OPPORTUNITY to be considered for an opportunity?
Why don't we fix the ecosystem itself? Instead of trying to apply more and more rules and, thereby, pissing off the developers who have always played fair and who have cared deeply about their craft to the point where they don't want to play the game anymore either? How does that solve anything at all?
Stop accepting technical tests. Stop asking for them too. Developers need to be made responsible for their willing inadequacies and the threat of being fired or let go or not getting that promotion can be great inducers. Companies need to treat developers with respect, too, invest in them a bit, treat them like human beings instead of code churning machines with a computerized brain full of all kinds of knowledge that no average person can reasonably maintain.
How do we solve the underlying problems here? Better training for everyone. Better training for developers (I don't believe bootcamps are the answer) and better training for organizations so they understand that world enough to make some informed decisions.
Those are topics for a different post.
Latest comments (31)
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!!
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.
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.
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.
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.
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 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.
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?
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.
If the company is willing to pay me for time spent with a test, then I know they are serious about hiring me.
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.
Many companies pay. Basecamp wrote about this in their latest book. They pay somewhere between 1,500 and 2k to do a take home project. If you're working they give you 2 weeks, if not, 1 week.
I've had several companies pay to take tests. I took one that was a quiz format that took about an hour and was paid $50. I had another take home project that took about 5 hours and they gave me $150 to do it.
Also, companies are interested in candidates all the time before they see them code. I don't even need to apply for jobs anymore, recruiters and companies reach out to me, based on my experience.
Another thing that might surprise you, is there are companies that hire developers without requiring a coding challenge at all. A simple discussion about programming is usually enough to determine the skillset of a candidate. Have them talk about their experience, problems they solved, and technical decisions they made, because that is more than enough to give you a solid understanding of their capability.
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 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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.