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.
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.
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.
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.
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.
The huge backlog of code you are referring to is probably owned by other companies, and cannot (or should not) be seen by employers. When job candidates show me a portfolio of proprietary code that was developed in old jobs without permission from their old employers, I show them the door. If they lie about having permission, I find out because I call the old employer and ask, unless it is the current employer, in which case I don't call and don't want to see the code. There is NO way I'd hire somebody that shows IP to other companies.
If you have open-source projects out there, that's great. t might or it might not be useful for evaluation. Usually, it isn't.
The experience you have with other companies is not visible to others. Just because you were employed somewhere doesn't mean that you were a good employee.
# Legal risks prevent "reference checks" from being very useful, so it is not as easy as "call my old employer and ask them."
It is difficult and time-consuming to properly evaluate and test code that resolves a problem you are not familiar with. The familiarity with a programming challenge exercise allows an employer to evaluate the candidate much better.
If you are hired by a company that does programming exercises, you'll find that the quality of your co-workers is very high. It is not coincidental.
Companies that require programming challenges want to see if you really want the job. If you don't do the exercise, they'll decide (rightfully so) that you don't care enough. That's actually a win for the company because they avoided wasting their time to interview somebody who doesn't care enough. It is also a win for the candidate because with the "no, just no!" attitude they won't keep their job very long in that company.
The result of the programming challenge is not work. The company has no use for whatever you write. It is not doing free work for the company, it is demonstrating that you are willing to go an extra mile.
"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
Comment marked as low quality/non-constructive by the community. View Code of Conduct
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 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 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.
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
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.
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.