As a former tech recruiter, I can say there's a good chance interviewing team won't bother reviewing your coding exercise. It's easy to ask you to complete an exercise, but reviewing the exercise, let alone giving meaningful feedback, requires work. Teams aren't always willing/interested/able to put in the work review N take home projects.
Here's an example:
- apply to job
- recruiter does phone screen
- you're asked you to complete exercise before an interviewer has reviewed your profile/resume/application
- you put a bunch of work into doing exercise well and return it
- your exercise is not reviewed at all because: the job has been filled, the job has been closed, an interviewer didn't like your resume/CV/application, the recruiter misplaces your exercise, the team is too busy to review any exercises, etc.
I should explain what our coding exercise is. Its a decent size project on bitbucket that we ask developers to install. Yes, just install. No real coding required. Usually takes between 30 minutes to 8 hours. What we are looking for are specific things: a) Can you read and follow the installation instructions AND are you familiar with Git and NPM? b) If you face some installation issue, are you willing to spend the effort to solve it? c) Can you read code? Because sometimes a library wont work for you. So you might have to change the version or find a workaround. d) For more mid to senior engineers, we expect them to ask detailed questions on our choices of architecture, libraries and suggest alternatives and reasoning behind their choices.
So its not really a coding exercise where we ask someone to fix a bug or write code and then evaluate their coding style. Its a little different in that we are looking for problem solving skills in a startup environment. I don't think this approach will work for a large company where every developer has a specific role. But it works well for us.
I should explain what our coding exercise is. Its a decent size project on bitbucket that we ask developers to install. Yes, just install. No real coding required. Usually takes between 30 minutes to 8 hours. What we are looking for are specific things: a) Can you read and follow the installation instructions AND are you familiar with Git and NPM? b) If you face some installation issue, are you willing to spend the effort to solve it? c) Can you read code? Because sometimes a library wont work for you.
Interesting. I think that is one good approach. Because I've come across many people (aspiring to be software workers) who 1) cannot even follow clearly specified instructions to the letter (a basic skill for a software person), and/or 2) cannot figure out ways to deviate from those instructions in meaningful ways, if they do not work.
Seems like it's a decent way to verify spurious claims that are not well confirmed in a spoken portion of the job interview. It feels like a FizzBuzz version of environment knowledge and tools skills.
The kind of coding tests I don't like are the ones that seem too onerous and involved for the given role. I have recently phone interviewed with a company, which they don't make their own software as a revenue source but build software for other clients. I talked over the phone with one of the lead programmers, discussed my skills, situations related to my work experience, etc.
Afterwards, he issued me a coding exercise with a VERY DETAILED .pdf document that felt uncomfortably close to a request for proposal and summaries of requirements. I hesitated and replied back about this. They assured me that this is not unpaid work and that everyone has to take this same test, in the language of their choosing. The test was intended to produce code for a MVC web app that they can evaluate. So I guess they really wanted sample code, despite having already produced other samples from Github, and discussed my real-world MVC work projects from my perspective as a mid-level developer (including one where I had architectural control).
I think the most disappointing thing, though, is that this long test is mandatory for everyone that they interview. So, the responses and decisions you make in the phone interview portion don't seem to have any real impact on the next step in the process. Someone could have a highly popular library on Github and they could still say, okay you gotta take this test. Non-trivial tests should be tailor made to a person's own experience.
If you're going to ask me to do a project that takes n hours, either I'm going to reciprocate and require the same of you, or you're going to pay my consulting rate to do it.
I suspect every good candidate had the same approach. If you're getting people to do this for free, you're not getting very good applicants.
In this market, the people you're interviewing are far more desirable than you are.
One of the best interviews I ever went on was a pair coding exercise. The interviewer asked me to come in for a couple hours, and we worked through a problem together. The "my time is your time" vibe was really nice. An interviewer wouldn't he able to scale that kind of interviewing technique unless they were upfront with candidates about what they'd he asked to do, and had a reasonable level of confidence that a candidate would have a reasonable shot at getting the job. I really liked it, and it demonstrated that the interviewer had thought about the interview in advance.
I'm willing to do take home projects when I know how they'll be evaluated. If you are willing to ask me to commit my time to something, and let me know what I'm getting for my investment of time, that goes a long way.
As an interviewer, I tend to avoid paying applicants. It just feels odd. Instead, I try to make the opportunity (interview plus potential job) as enticing as I can. Once it gets out that an that an interviewee pays interviewees, I'd be concerned that I'd attract "professional" interviewees who just want the money. As a blood bank, I wouldn't pay people to donate blood either for reasons that feel similar.
Comments
As a former tech recruiter, I can say there's a good chance interviewing team won't bother reviewing your coding exercise. It's easy to ask you to complete an exercise, but reviewing the exercise, let alone giving meaningful feedback, requires work. Teams aren't always willing/interested/able to put in the work review N take home projects.
Here's an example:
- apply to job
- recruiter does phone screen
- you're asked you to complete exercise before an interviewer has reviewed your profile/resume/application
- you put a bunch of work into doing exercise well and return it
- your exercise is not reviewed at all because: the job has been filled, the job has been closed, an interviewer didn't like your resume/CV/application, the recruiter misplaces your exercise, the team is too busy to review any exercises, etc.
I should explain what our coding exercise is. Its a decent size project on bitbucket that we ask developers to install. Yes, just install. No real coding required. Usually takes between 30 minutes to 8 hours. What we are looking for are specific things: a) Can you read and follow the installation instructions AND are you familiar with Git and NPM? b) If you face some installation issue, are you willing to spend the effort to solve it? c) Can you read code? Because sometimes a library wont work for you. So you might have to change the version or find a workaround. d) For more mid to senior engineers, we expect them to ask detailed questions on our choices of architecture, libraries and suggest alternatives and reasoning behind their choices.
So its not really a coding exercise where we ask someone to fix a bug or write code and then evaluate their coding style. Its a little different in that we are looking for problem solving skills in a startup environment. I don't think this approach will work for a large company where every developer has a specific role. But it works well for us.
Interesting. I think that is one good approach. Because I've come across many people (aspiring to be software workers) who 1) cannot even follow clearly specified instructions to the letter (a basic skill for a software person), and/or 2) cannot figure out ways to deviate from those instructions in meaningful ways, if they do not work.
Seems like it's a decent way to verify spurious claims that are not well confirmed in a spoken portion of the job interview. It feels like a FizzBuzz version of environment knowledge and tools skills.
The kind of coding tests I don't like are the ones that seem too onerous and involved for the given role. I have recently phone interviewed with a company, which they don't make their own software as a revenue source but build software for other clients. I talked over the phone with one of the lead programmers, discussed my skills, situations related to my work experience, etc.
Afterwards, he issued me a coding exercise with a VERY DETAILED .pdf document that felt uncomfortably close to a request for proposal and summaries of requirements. I hesitated and replied back about this. They assured me that this is not unpaid work and that everyone has to take this same test, in the language of their choosing. The test was intended to produce code for a MVC web app that they can evaluate. So I guess they really wanted sample code, despite having already produced other samples from Github, and discussed my real-world MVC work projects from my perspective as a mid-level developer (including one where I had architectural control).
I think the most disappointing thing, though, is that this long test is mandatory for everyone that they interview. So, the responses and decisions you make in the phone interview portion don't seem to have any real impact on the next step in the process. Someone could have a highly popular library on Github and they could still say, okay you gotta take this test. Non-trivial tests should be tailor made to a person's own experience.
If you're going to ask me to do a project that takes n hours, either I'm going to reciprocate and require the same of you, or you're going to pay my consulting rate to do it.
I suspect every good candidate had the same approach. If you're getting people to do this for free, you're not getting very good applicants.
In this market, the people you're interviewing are far more desirable than you are.
One of the best interviews I ever went on was a pair coding exercise. The interviewer asked me to come in for a couple hours, and we worked through a problem together. The "my time is your time" vibe was really nice. An interviewer wouldn't he able to scale that kind of interviewing technique unless they were upfront with candidates about what they'd he asked to do, and had a reasonable level of confidence that a candidate would have a reasonable shot at getting the job. I really liked it, and it demonstrated that the interviewer had thought about the interview in advance.
I'm willing to do take home projects when I know how they'll be evaluated. If you are willing to ask me to commit my time to something, and let me know what I'm getting for my investment of time, that goes a long way.
As an interviewer, I tend to avoid paying applicants. It just feels odd. Instead, I try to make the opportunity (interview plus potential job) as enticing as I can. Once it gets out that an that an interviewee pays interviewees, I'd be concerned that I'd attract "professional" interviewees who just want the money. As a blood bank, I wouldn't pay people to donate blood either for reasons that feel similar.