I can relate my experience to the UK, well, london for 99% of my time, market. The usual process here is to have at least a first call / in person meeting and if both feel good in going on,...
I can relate my experience to the UK, well, london for 99% of my time, market.
The usual process here is to have at least a first call / in person meeting and if both feel good in going on, eventually having a code challenge. I've seen often enough that companies here check your public github / bitbucket and actively ask for yours as a way of skipping the code challenge.
When it comes to it I've found in equal percentage to be:
A simple applications (write an app that interact with this backend, already existing, and display some info, using this and that technology)
Some specific programming problems to see how you approach them more than your code
Some specific theory questions with a specific set of technologies
Creating a whole product, database, backend and frontend given very specific instructions and description of its use-cases
I believe that the last one is what the article's writer is talking about. It's not that common in my experience but when it happened, more often than not I am the one who doesn't even spend time answering to them anymore.
In a couple of occasions I wrote down the application design (how it should work in terms of logic and mechanics) and gave them that. They replied asking for an actual working example and I told them that I'm getting paid for doing something like that usually so we can discuss my tariff as freelance. Of course I was just telling them, kindly, to fuck themselves, and they never responded as expected.
Apart these bad experiences, the interesting thing for me is that I've seen the other three approaches but the basically never mix up. So, probably, it depends from the CTO/IT Lead/whatever idea of things that have value and should be tested, that it determine what actually is a "code challenge" here.
I personally think that the first is the better approach:
It's a good all-rounder test. It shows how a candidate organise its code, write it and have experience in making it modular/not modular and knows that third party libraries that a language always has at this time (think composer or npm libraries for example). It also helps in case the person already announced that it's not knowledgeable with some technologies you're asking to use, as it shows how it's capable of picking up new tools in a short amount of time. Of course you cannot expect the best practice for that specific tool but you should still be able to see the language and design best practice in action.
Of course this approach require the company to actually invest some time and effort in doing something. Imagining a challenge product being built for this purpose, means having created a database, backend and frontend already and have the candidate try to re-create the ones that fits the position he's applying for.
Specifically on the point of it not being paid, here's an opposing view from someone working in the games industry: Don't take unpaid internships, but don't expect to be paid for job interviews!...
I work in the industry and I'm usually on the sending side of these technical challenges. We always have a phone interview with the candidate first to make sure we legitimately believe they'd be a...
I work in the industry and I'm usually on the sending side of these technical challenges. We always have a phone interview with the candidate first to make sure we legitimately believe they'd be a good fit, and we always respond to those who participate regarding the outcome, with further feedback if the candidate asks for more details.
I can't speak for any other hiring staff but I think the way we do it is fairly ethical. We understand you're giving up time for us so we wouldn't ask you to do it if we didn't think you were in with a good chance. I do completely understand why people are skeptical of companies that send you a coding challenge up front though, and I'd probably be skeptical too if I was met with an automated request for hours of my time before even making human contact.
I'm also a hiring manager (albeit for a [ gag ] DevOps team where I'm mostly Ops and the rest of my team definitely leans more Dev) and we've changed to a Pair Programming interview. In most of my...
I'm also a hiring manager (albeit for a [ gag ] DevOps team where I'm mostly Ops and the rest of my team definitely leans more Dev) and we've changed to a Pair Programming interview.
In most of my interviews, the candidate's code doesn't work. This is fine by me as it's more important to see how well they understand the instructions and think about the process of solving the problem than actually solving it. An interview is stressful and I can say from my own experiences that functions and modules which I use in my code regularly become completely forgotten once I start interviewing...so I expect that a candidate may know exactly what to do but can very easily have a brain-fart which makes them forget how to do anything in Python/Javascript/Ruby/whatever. I even tell my candidates that I'm happy to accept pseudocode to explain their logic if their brain is failing them.
I must agree with the article and others that this process of expecting a candidate to spend a bunch of time with a bot before talking to a human is bullshit and should be stopped.
I agree with this to the point that I felt the need to not just vote, but to second it with a comment. Code challenges are great, and we always use them after a phone interview. I'm with a...
I agree with this to the point that I felt the need to not just vote, but to second it with a comment.
Code challenges are great, and we always use them after a phone interview. I'm with a relatively small company, so our first interview is actually with the owner of the company - a very valuable resource - and it's only at that point that we decide if there's enough of a fit to warrant a technical challenge test. We also do not use this as a filter - we've hired people who have done poorly because they showed their work and displayed that they could learn.
The demand for skilled, and experienced, developers is incredibly high at the moment, so no (sane) company is going to put mid-level or higher positions behind a barrier like that if possible....
The demand for skilled, and experienced, developers is incredibly high at the moment, so no (sane) company is going to put mid-level or higher positions behind a barrier like that if possible. Companies advertising low/entry-level positions, however, can be a lot more selective with whom they interview.
So while the intention of the article is good, it's hard to convince people just starting out in their careers to take the moral high-ground on this position and pass up opportunities.
Isn't it ridiculous that an industry that is so desperate to recruit people actively cripplr their ability to do that? Didn't google admit that whiteboard / algorithm based interviews are a really...
Isn't it ridiculous that an industry that is so desperate to recruit people actively cripplr their ability to do that? Didn't google admit that whiteboard / algorithm based interviews are a really poor predictor of job performance? It seems the rest of the industry has just blindly followed them because ... google.
And don't even get me started on "we only hire the best" bullshit mentality. How can several thousand companies all hire the best?
The problem is that the cost of a bad hire is really high - in something as complex as programming, bad enough people cause negative productivity. That, combined with the high likelihood (in IT)...
The problem is that the cost of a bad hire is really high - in something as complex as programming, bad enough people cause negative productivity. That, combined with the high likelihood (in IT) of people suing you if you fire them, causes companies to put up very high barriers to entry.
At-will employment is still subject to wrongful termination lawsuits. Unfortunately, one can always come up with some bullshit reason to file a wrongful termination case. For example, I know of...
At-will employment is still subject to wrongful termination lawsuits. Unfortunately, one can always come up with some bullshit reason to file a wrongful termination case.
For example, I know of someone who disappeared for a few months (without telling their employer). Apparently they spent that time in a halfway house for drug abuse. After being fired for not showing up to work for a few months, they still turned around and filed wrongful termination.
Oh man I was taken advantage of this way once. I applied for an internship for a large scale local farm. The grew plants (on hundreds of acres) and sold the seeds. Keep in mind this was a family...
Oh man I was taken advantage of this way once. I applied for an internship for a large scale local farm. The grew plants (on hundreds of acres) and sold the seeds. Keep in mind this was a family owned business with no IT staff whatsoever. I drove two HOURS to an interview that also lasted two hours. I literally had to park my car and cross a flooded bridge on foot and walk the last block to get there. I explained how I would build a product for them to fit their needs, to the point of sketching out rough drafts of DB schemas on the spot. I talked about hardware and what tools would be needed. They wrote every word I said down. Then they hired someone with less experience for a fraction of the pay I asked for, no doubt giving them all of the work I had prepared ahead of time.
I can relate my experience to the UK, well, london for 99% of my time, market.
The usual process here is to have at least a first call / in person meeting and if both feel good in going on, eventually having a code challenge. I've seen often enough that companies here check your public github / bitbucket and actively ask for yours as a way of skipping the code challenge.
When it comes to it I've found in equal percentage to be:
I believe that the last one is what the article's writer is talking about. It's not that common in my experience but when it happened, more often than not I am the one who doesn't even spend time answering to them anymore.
In a couple of occasions I wrote down the application design (how it should work in terms of logic and mechanics) and gave them that. They replied asking for an actual working example and I told them that I'm getting paid for doing something like that usually so we can discuss my tariff as freelance. Of course I was just telling them, kindly, to fuck themselves, and they never responded as expected.
Apart these bad experiences, the interesting thing for me is that I've seen the other three approaches but the basically never mix up. So, probably, it depends from the CTO/IT Lead/whatever idea of things that have value and should be tested, that it determine what actually is a "code challenge" here.
I personally think that the first is the better approach:
It's a good all-rounder test. It shows how a candidate organise its code, write it and have experience in making it modular/not modular and knows that third party libraries that a language always has at this time (think composer or npm libraries for example). It also helps in case the person already announced that it's not knowledgeable with some technologies you're asking to use, as it shows how it's capable of picking up new tools in a short amount of time. Of course you cannot expect the best practice for that specific tool but you should still be able to see the language and design best practice in action.
Of course this approach require the company to actually invest some time and effort in doing something. Imagining a challenge product being built for this purpose, means having created a database, backend and frontend already and have the candidate try to re-create the ones that fits the position he's applying for.
Specifically on the point of it not being paid, here's an opposing view from someone working in the games industry: Don't take unpaid internships, but don't expect to be paid for job interviews!
Disclaimer: I have tangentially worked for this person/their dev company before, but not in the roles this post discusses.
I'm not (much of) a programmer, so I'd like to see what people working in the industry think of this.
I work in the industry and I'm usually on the sending side of these technical challenges. We always have a phone interview with the candidate first to make sure we legitimately believe they'd be a good fit, and we always respond to those who participate regarding the outcome, with further feedback if the candidate asks for more details.
I can't speak for any other hiring staff but I think the way we do it is fairly ethical. We understand you're giving up time for us so we wouldn't ask you to do it if we didn't think you were in with a good chance. I do completely understand why people are skeptical of companies that send you a coding challenge up front though, and I'd probably be skeptical too if I was met with an automated request for hours of my time before even making human contact.
I'm also a hiring manager (albeit for a [ gag ] DevOps team where I'm mostly Ops and the rest of my team definitely leans more Dev) and we've changed to a Pair Programming interview.
In most of my interviews, the candidate's code doesn't work. This is fine by me as it's more important to see how well they understand the instructions and think about the process of solving the problem than actually solving it. An interview is stressful and I can say from my own experiences that functions and modules which I use in my code regularly become completely forgotten once I start interviewing...so I expect that a candidate may know exactly what to do but can very easily have a brain-fart which makes them forget how to do anything in Python/Javascript/Ruby/whatever. I even tell my candidates that I'm happy to accept pseudocode to explain their logic if their brain is failing them.
I must agree with the article and others that this process of expecting a candidate to spend a bunch of time with a bot before talking to a human is bullshit and should be stopped.
I agree with this to the point that I felt the need to not just vote, but to second it with a comment.
Code challenges are great, and we always use them after a phone interview. I'm with a relatively small company, so our first interview is actually with the owner of the company - a very valuable resource - and it's only at that point that we decide if there's enough of a fit to warrant a technical challenge test. We also do not use this as a filter - we've hired people who have done poorly because they showed their work and displayed that they could learn.
The demand for skilled, and experienced, developers is incredibly high at the moment, so no (sane) company is going to put mid-level or higher positions behind a barrier like that if possible. Companies advertising low/entry-level positions, however, can be a lot more selective with whom they interview.
So while the intention of the article is good, it's hard to convince people just starting out in their careers to take the moral high-ground on this position and pass up opportunities.
Isn't it ridiculous that an industry that is so desperate to recruit people actively cripplr their ability to do that? Didn't google admit that whiteboard / algorithm based interviews are a really poor predictor of job performance? It seems the rest of the industry has just blindly followed them because ... google.
And don't even get me started on "we only hire the best" bullshit mentality. How can several thousand companies all hire the best?
The problem is that the cost of a bad hire is really high - in something as complex as programming, bad enough people cause negative productivity. That, combined with the high likelihood (in IT) of people suing you if you fire them, causes companies to put up very high barriers to entry.
On what grounds? Google mostly (only?) operates in at-will states.
At-will employment is still subject to wrongful termination lawsuits. Unfortunately, one can always come up with some bullshit reason to file a wrongful termination case.
For example, I know of someone who disappeared for a few months (without telling their employer). Apparently they spent that time in a halfway house for drug abuse. After being fired for not showing up to work for a few months, they still turned around and filed wrongful termination.
Oh man I was taken advantage of this way once. I applied for an internship for a large scale local farm. The grew plants (on hundreds of acres) and sold the seeds. Keep in mind this was a family owned business with no IT staff whatsoever. I drove two HOURS to an interview that also lasted two hours. I literally had to park my car and cross a flooded bridge on foot and walk the last block to get there. I explained how I would build a product for them to fit their needs, to the point of sketching out rough drafts of DB schemas on the spot. I talked about hardware and what tools would be needed. They wrote every word I said down. Then they hired someone with less experience for a fraction of the pay I asked for, no doubt giving them all of the work I had prepared ahead of time.