21–30 of 40 posts
At VMware while looking for systems level engineers our team would give out a take home programming assignment and it was the most accurate measure of how good someone was. We’d give everyone the same test so it was easy to compare and it was quite niche so you couldn’t google an answer or ask someone else to do it. Not everyone has time to do it, but enough were that we found great candidates and didn’t hire any dud…
I've done a bit of research into this topic as my startup is building a platform that combines leetcode and traditional take homes. I have come to conclude that it's not only unethical, but it's not in the best interest of the company. We landed on 1h "take homes" as those that maximize the completion rate. It was also clear that take homes, or work sample tests, are amongst the most valid signals for future on the j…
Absolutely not.
The test is easy: the person who is giving the assignment would themselves be annoyed, inconvenienced, and feel pressurized if they got given a similar assignment when looking for a job themselves. You know "do onto others..."
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.
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…
That might be true. But the primary beef is with the average case, not the tail end.
The main point is -- way or another, a lot of these companies end up giving out assignments just end up taking way too much time to get reasonably correct. More specifically an average of about 2x the time estimate that apparently just ... popped into their head when coming up with the assignment (and which is of course almost never actually verified in any other way than handing the assignment out to a bunch of candidates and seeing what happens).
Along with the clunky websites ("Hey could you fill out the exact starting and dates for every position you've every had, and pick the country from this big long drop-down, even though it's always the same country for every job? Along with the supervisor's name and the reason for leaving? It's not like we really care or are anyone's like to even look at these fields, we're just asking because, like, umm, they just changed us over to this new ATS and we haven't bothered to figure out how to configure it yet"), the jaggy communications ("An update on your application ... except it's just a link to a survey we'd like you to fill out, because we know you really care about our application process and you have lots of free time that you're happy to donate to us"), and all the other delays and silliness ...
And without even getting into the ghosting rate (even though they all insist they strive very hard not to do this) --
It all just takes up way too much time.
Next question?
I've done a bit of research into this topic as my startup is building a platform that combines leetcode and traditional take homes. I have come to conclude that it's not only unethical, but it's not in the best interest of the company. We landed on 1h "take homes" as those that maximize the completion rate. It was also clear that take homes, or work sample tests, are amongst the most valid signals for future on the j…
>It was also clear that take homes, or work sample tests, are amongst the most valid signals for future on the job performance. Absolutely not.
[1] https://psycnet.apa.org/record/1998-10661-006
[2] https://www.opm.gov/policy-data-oversight/assessment-and-sel...
I worked in a company who put the candidates to work the entire day on the code base
In our experience, not everybody gets the code correct (at least according to our test cases). It then turns into an interesting exercise to ask the candidate how they would fix the code to deal with the failing case.
When I was in a startup consulting company, candidates were asked to prepare a talk on a topic of their choice for 20 minutes and allow another 10 minutes for questions. I suspect that many candidates did not realize why they were being asked to do this -- we need to know whether they could get their message across in a limited amount of time, and be able to manage an audience that was throwing them off track. The smarter ones would realize when they were being side tracked and ask the question "Can we deal with these questions later as I'd like to be respectful of your time?"
I think that all candidates should realize that in nearly all cases, they are being asked questions, and to do things, for a reason. It may not be the reason that it appears to be on the surface.
In the US in almost all cases the interviewee will not be an employee of the company and writing the code within the scope of their employment, and so the code will not automatically be a "work for hire".
That means that the interviewee will own the copyright of the code they write. This is something you will want to think about if you are the employer and considering coding requirements during interviews whether take-home or in-person.
It could be bad news if some interviewee's code ended up in production (accidentally or on purpose) and you did not own the copyright.
If you want to own the code that interviewees write, there are two approaches. The most reliable approach would be to get them to sign an agreement assigning the copyright of anything they write for the interview to you.
This will require a contract so don't just wing it. Get your company's lawyer to write it.
The other approach is to try to make it a work for hire. If you succeed then the copyright is yours as soon as the interviewee writes it.
For this you need three things:
1. A written agreement signed by the interviewee and the company saying that the code will be a work for hire.
2. The code must be specifically ordered or commissioned.
3. It must fall into one of 9 specific categories of works.
#1 should be easy, but get your lawyer to write the agreement. #2 should also be easy if you do a decent job of specifying the assignment you give the interviewee.
#3 might be difficult. For a long time software was not thought to fall into any of the categories and so could not be a work for hire unless developed by an employee. But a few years ago some courts decided that it could fall into a couple of them. I haven't kept up with developments since then and so don't know if this is now settled.
The usually recommendation I've seen is to have your work for hire agreement also include a copyright assignment agreement in case the work turns out not to be a work for hire.