Second was kinda ridiculous: implement a stripped-down version of their website, with tests (and production-ready, of course). They claimed it could be done in 4 hours, which is probably true for all the devs that work there, since they already know exactly what's involved. I spent ~8 hours on it and submitted something that worked but had problems, which I documented thoroughly. Again, rejected with no feedback.
But here is why. For every personal story you have of working with a dev that can’t program, your recruiting staff has 3 of bad/lawyer invoking instances of dealing with crazy candidates. They are being honest with you when they tell you any other policy is too expensive.
You are only supposed to spend 6 hours on it, we give a 24 hours timer so you are not too pressured for time (you can take breaks, have diner, a walk, etc) .
So far it works pretty well.
I have not yet seen any applicant writing tests. Just delivering the project with the requested features and acceptable code (no memory leaks, crashes, unreadable mess, etc) is more than enough to go to the next step.
If you demonstrate enough proficiency during this step, we will probably skip most tech questions and focus on fit in the next step.
That's our third step though, first our recruiters filter applications (I have no idea how many people are funneled out at this point)
Then we have a 30 minutes phone call to discuss experience and presell the company. We also try to answer all their questions at this point and explain the challenge. Something along the lines of : "so the next step will be a take home test. We just want to see how you code, don't put too much pressure on you, just do your best in the time given"
Historically we have only been looking for pretty senior engineers, although we are relaxing this a bit.
The company has also been sponsoring a lot of visas (even with very interesting salaries, senior mobile engineers are hard to recruit .. most of them are already happy where they are), I think that take home are a good way to handle this case.
The applicant can take the exercise whenever he wants (the only limitation is that we might not be available to answer their questions in the middle of the night) and shows us what they can do.
When hiring back-end devs, I explicitly make it clear I want at least some tests -- and the more the better. Of course I don't expect 100% test coverage but writing tests shows that 1) you understand best practices 2) you know how to write testable (readable, maintainable, clean and clear) code. If candidates chose just one module and tested that well it would be enough to get the point across.
Seeing how people write their tests is also quite important for me -- if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag.
Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output.
> 2) you know how to write testable (readable, maintainable, clean and clear) code.
Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code.
> if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag.
No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it.
Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.
Testing in and of itself is best practices. Having familiarity with and a strong understanding of how and what to test is extremely important for any modern development cycle.
> Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code.
Except it's significantly more difficult.
> No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it
If you don't have a strong dummy data suite to test against, then you're not testing properly. This actually justifies exactly what I'm talking about.
> Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.
If it's mundane and easy then it should just be done. What I've found is that most can't.
If the candidate pool was small, then I'd take less of an issue to it. But if 50 people come in and they can all problem solve, then I'm going to become more interested in who can solve problems elegantly.
I had a coding test, not take home, where I was able to code on my own on a simple problem for about 45 minutes for each session then have a code review. We did this three times over three hours on increasingly harder problems.
This exact same format could be done remotely.
Why? That seems like an oddly specific thing to be a _huge_ red flag. Are you expecting random data to actually surface bugs - ie: making your tests non-deterministic? Or is there some other benefit you are looking for to make it such an important criteria?
That prototyping later becomes extremely useful for building local databases -- a strong factory suite means I can rebuild my local database and have it completely populated with randomized dummy data. Changing locales on some packages means I can have a local environment populated with data tailored for a completely different country and language, for example.
Re: surfacing bugs -- in a lot of cases yes. And a lot of bugs have been found this way.
If a developer can test, that's a good fundamental skill. If they don't use a factory, that says nothing about their fundamentals – it's something you can easily tell someone who knows how to test to go learn & do once they're on the job.
If taking an extra an hour of time to sell your work is "throwaway" then that person is either shotgun applying to jobs (and not being hired for a reason) or they're not taking their application seriously.
Think about it this way. It takes about 2 hours to learn how to write unit tests for someone who has never done it. Why make something as trivial so important in your interview process? I understand unit tests are important, but they aren't difficult.
If it's really that trivial, the developer should be doing it so routinely that it should take less than 15 minutes to write unit tests for the take home exercise. Your statement literally demolishes any excuse for not doing it.
All too well, my friend. That is why the employer is justified in asking for a demonstration of the ability to write good unit tests, as you have demonstrated by your own admission.
According to him, if I didn't setup a factory, when doing a take home assignment, then I'm not competent to write unit tests. I disagree.
So many people interview poorly. It's gotten worse every time I read about it. They're pushing away talent that way. I know people are stuck in their ways, but it's a bad idea unless you are are just looking for juniors and people desperate enough to go through that. I'm neither.
I mean don't people realize it's a seller's market?
I'm about to start applying to new positions and it sounds like I won't get the same courtesy, but only you can decide if your enthusiasm for the position matches the opportunity cost of the interview process.
All a take home test does is eliminate your strongest candidates, since they generally won't bother. It has to be a truly extraordinary position before anyone with significant experience will waste their time trying to compete in this market. Keep in mind my opportunity cost while job seeking is networking. Every minute I waste on someone's takehome is time I could be tayloring my resume to another position or emailing with prospective employers, which makes them all the more expensive to waste time on.
Considering I'll have to pay all taxes, medicare, ssi, etc. on all self-employment income and that the time I spend working on your challenge is time I'm not spending chasing other business, the contractor rate that I'm going to charge you is likely going to be around 300-400% of what I expect my salary to be for that time.
If you can't afford that, I'll probably think you're either exploitative or delusional or both.
But then again, your 6 hour programming assignment is worth about $1500+ of my time.
We take a salary because we want to offload risks and time spent doing sales to source our income, but we shouldn't have to do throwaway work for free to get that. Sounds too much like 'unpaid internship' to me.
The fact that some applicants will spend ridiculous amounts of time on a challenge is a critical flaw. It doesn't mean that take-home challenges are worthless, though. It just means they need a functional mechanism to enforce time limits equally on all candidates.
Simple, cater the challenge so that's not possible.
Some companies are just bad at conducting interviews, that's the real tell and not take-home challenges.
I've had terrible in-person technical interviews, but I'm not going to reject the entire concept of in-person technical interviews because I've had a couple bad experiences.
If someone doesn't want to participate in a take-home coding challenge then that's their prerogative, but not everyone thinks they are a bad idea. If I were requesting a take-home challenge and a candidate I liked said they will not proceed if they have to do one, then I would probably make an exception. But that's me working at a startup where I have full interview control.
Worse still, I've interviewed people who have put their employers' work on their personal GitHub, publicly and without permission, solely because of this reason. I have serious ethics/intelligence questions about those people and they become a strong no-hire every time I see it.
> which will never be maintained because its a take-home assignment
You will most likely be asked to add a feature or two to it in the followup in person interview.
All of mines have had a time limit to them of an hour. The process has always been
1) arrange a time with the recruiter when I will be free for an hour, e.g.lets say 1PM.
2) recruiter emails me the challenge at around 12:58. I get the challenge and have to code the solution and have it back to the recruiter by 2PM.
Then at the face to face interview we've went through a code review of my code and talked about why I chose to do somethigns the way I did, if I had to more time what would I do differently, was there anything in my solution that I wasn't happy with etc.
Seems to work reasonably well.
There is no way on earth I would be dedicating a weekend or more to an interview task.
You can always have someone else do the "homework" for you, but when you keep working on the same code base you have to show a real understanding of both the problem and your code, and it's quite close to a real work situation.
In hindsight I agree that telling people that will happen would level the playing field a bit.
1) You ran out of time to write tests.
This might be the least bad reason. You can probably talk your way out of this by explaining what tests you would have written if you had the time.
2) You don't know how to write tests.
This shows that you have only worked at places the don't do testing and that you haven't taken the initiative to learn about testing on your own.
3) You know how to write tests, but you don't think they are needed.
You could probably tell the interviewer why tests were not important for the particular exercise. But I have never seen a take home exercise that doesn't require a basic algorithm and some tricky conditional business logic. Both of which would benefit from unit tests.
4) The code you wrote isn't testable.
This is probably the worst reason. Everything is in one or two giant functions and you can't inject dependencies for testing without refactoring everything. This will frighten your interviewer.
1. Build a prototype of the feature I need to build
2. After I have a prototype, I start to understand the complexities of the project and I start thinking about how to modularize my code (the functions I would need, how the frontend-backend interacts together).
3. I rebuild the feature with TDD
For take-home assignments, I stop after step 2 because step 3 is the most time consuming part.
I'm pretty open minded about this, but with 5-6 years of development most take home assignments are so trivial and so self-contained.
Perhaps its really the take-home assignment that needs to change. For example, heres the sort of prompt that would motivate me to write good tests:
"Here's a private repository that every candidate we have hired has been building. We would like you to add a feature. Please build feature X on top of our existing code -> Link to repository that has an application with simple testing infrastructure"
Now the take-home assignment has more value and actually gauges how well the candidate would do in an actual working environment. When the candidate gets hired, his feature actually gets merged into the assignment and a new feature is assigned to new candidates.
5) Your interview process is ridiculous, and I refuse to do more than the bare minimum when I am not even guaranteed an interview in exchange for my time investment.
I am an experienced programmer. I refuse to do take-home tests as a pre-screen for an actual interview, unless I know for certain that a position is one that I would want to take (e.g. I know someone who works there, and I know that it's a dream position. This basically never happens.) Moreover, if I have done a full interview loop and you insist on screening me based on inanity such as "he didn't write tests for this time-limited toy assignment", I will gladly move on to the next company that isn't ridiculous.
Take-home tests are screening devices. If you draw inferences other than "this candidate can/cannot write code" from a take-home test, you are using them incorrectly.
I dislike take-home tests less than I dislike whiteboard interviews, so I try to be flexible, without being a pushover.
This might seem like a crazy idea, but its actually not. The previous companies that I have worked for all offer paid volunteer hours which could go directly to this initiative. The cost of hiring is around 30k per engineer (conservatively), which could help train someone living paycheck to paycheck for an entire year.
I spent the past year and a half starting a non-profit experimenting with this idea and invested all 200k of my annual salary to paying students. The coding tools and environment is set up like a baby version of Google's engineering infrastructure. Students progress are tracked by their merge requests and the complexity of the features that they have built. Students build tools that they use on a daily basis so they are heavily eating their own dogfood. Hopefully, one day I'll be able to build my engineering team by directly hiring from this non-profit. https://garagescript.org
Some people spend an entire week on the coding challenge, which really set the bar unrealistically high. Once I turned in a project 2 hours after receiving the assignment and got rejected because they think I didn't even try. Every functionality worked flawlessly, but they want tests and for me to treat it like a real production work. But how do you motivate yourself to treat such a trivial take-home (which will never be maintained because its a take-home assignment) with the perfection you would in production code? In production you have much better insights like how your component impact others, how users will be using your app, etc.