I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
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.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
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:
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 hardworking developer a lot of time and trouble if someone would care to look at his past work.
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.
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?
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.
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"?
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.
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"?
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.
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 many 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?
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.
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.
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.
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.
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.
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.
Well, but that's "life" I am afraid. Changing jobs is challenging.
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 one's 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.
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.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.