31–40 of 40 posts
They really are not because of the asymetric effort. It takes minutes for a company to assign a week of work. A fair system would be a test-employment contract of some kind, where it's understood there are no rights beyond payment for the assessment task.
When I was a CTO, we paid for it.
It's a question of who benefits from these tests.
Clearly, the company is in the driving seat, and should therefore be the one committing resources, or at least committing an equal amount of effort/resource by paying for the tests to be performed.
Leetcode-ish and strict timeboxing are awful and can't possibly provide useful signal beyond "can program in some manner". Nobody can do their best work in 1 hour timed and limited, only in the web IDE which isn't the same as their dev environment, no looking up anything, no progress on part 2 without completing part 1 and similar unrealistic restrictions.
They encourage the worst in coding. Globals, dumb temporary names, no comments and done-vs-maintainable style? Ship it. I only need to deal with this code for an hour and then it's thrown away. I'm not going to make my `important_thing_to_remember` variable anything longer than `i`, and I'm going to use `foo[0]` from that ridiculous regex I bodged together instead of splitting it up and building it from pieces where I name the capture group so Future Me can understand it.
I'd much rather have a test for 1h of reasonable work, and let me take 2h if needed to solve it and then refactor to make it maintainable.
95% of tech companies do not require 10-15 hours of take home interview work. Edit: adding additional context, any company working with a recruiter will constantly be told by the recruiter repeatedly that the company should simplify and shorten the interview process because if you don’t, you risk losing candidates to other companies. Recruiters put extreme pressure on hiring managers to make the interview process as…
I’ve rejected time-consuming tests if I thought it’s either not a good match, or I get the impression that there’s a ton of candidates and my odds are low.
In an instance for one of their engineering positions, they requested ~40 hours worth of work via a combination of system administration, development in C/Golang, and uploading to a git server where they could review the work.
At the time, I was a full-time student and declined given time constraints.
We’ve had more success with a simple timeboxed coding exercise for junior developers. Developers are supposed to implement a simple wireframe design of a single page that downloads some weather data from an API an shows it. Developers may create it in their favorite library/framework.
I do have one serious question: how to decide what good code is for an interview? It's already highly opinionated, but I can write code that's all dependency injection to the extreme and it would be considered overengineered. I could write a single file project with no DI and it would be ok (one off, 2 hours max), but it would not simulate a real situation. These two things are both valid approaches but they pull the code in opposite directions.
In a real scenario, we have a fixed deadline so it is possible to determine how many design points are available and work on those.