An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job.
Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.
Guess what? It wasn't. They rejected me as soon as I de-anonymized to allow them to see my resume.
Arthena, a Y Combinator funded company, did this to me. It truly was a waste of time.
To top it off the interviewer then sprung a surprise leetcode problem on me that had to work and was required to be written in a language ill-suited to the task. I bombed it and the interview ended. No one ever even ran my submitted program.
mvn clean package worked.
Turns out the guy was running mvn exec:java.
Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here?
But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.
I would be (and have been) one of those people. Why? In short, likely because your take-home tasks are tedious, boring, and unrepresentative of real-life work. They are not whiteboarding, but they aren't necessarily any better.
I have done take homes as a candidate, and also have reviewed them on the hiring side. Most of the time, as a candidate, any take home I have done has been wasted time. Nothing I feel like I could count as a significant contribution, or something I could add to my resume. Take homes usually have some boring cookie cutter problem, with your most nitpicky code reviewers as the judges. Or it's something that's grotesquely oversize that's expected to be done in two hours (hedging with "but feel free to use up more time if you want"). As a reviewer, I see that it also leads to candidates doing ridiculous things like overusing decorators or metaclasses in an attempt to impress the reviewers.
Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter.
My mini-conspiracy theory about this is that most companies are so embarrassed about their codebases and internal process that they don't let prospective employees look at them until after they are hired.
It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it.
The employer is going to ghost 80% of their candidates anyway, and if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
If none of their codebases are easy to jump into, then that might be a red flag in of itself. One thing I suppose I have been lucky about is that I have worked for companies that have some (albeit very minor) open source presence. I'm not talking new features. IMO a small fix to an existing codebase can be as minor as adding a new CLI flag, or lightly modifying some existing behavior. In many cases, it's what you'd give a new intern as their first fix.
> if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
Well the gain is that you learned to work with a real-life codebase. The thesis of my comment is that take-home projects do not often approximate a real life codebase well.
I disagree that the goal of an interview experience should be to necessarily give the candidate a new portfolio accomplishment. It's cool if it works out that way, for sure, but that can't be the expectation. I'm mostly interested in incrementally improving the status quo which also isn't focused around an interview day that bolsters your portfolio as an engineer.
I will say my favorite and most memorable interview experience was a phone screen followed by a take home to implement bottles and kegs (a fizz-buzz game) in javascript, a language I was/am not proficient in. Come onsite day, we worked though a ux design problem and a database design problem, we pair debugged some ruby code, and then we wrote a multiplayer back-end for my fizz-buzz client, something I'd also never done before. It definitely ticked the "add something to your portfolio" box but also wasn't stressful in the same way flash 1-hr whiteboard sessions are because I was bringing something to the table that we expanded on during the day-long session.
I have never seen a take-home project yet that I could do this with. Also they come with scary "You may not show this to anyone else, ever!" disclaimers which are more off-putting.
1) It's less time spent talking with potential coworkers. Which for me, coworkers (and how we work together/get along) determine about 90% of how satisfied I am with my job (assuming pay/benefits are standard).
2) You're still going to require me to take a day off and stand up in front of a whiteboard anyway eventually. Every take home I've done is an early stage filter. The final round is still a whiteboard panel.
You can learn a lot about a person by what questions they chose to ask you, but only if it's not a thing tacked onto the end of a long interview. If they haven't gotten much time to ask you questions, they only have your interview questions to go on. Which you know are not representative of the kind of work you do (but then, why are you asking them?)
So because you only ever talked to them about things that could readily be had off the shelf, and this is the only information they have, they can't know if you're bad at interviewing or some psycho who spends all their time reinventing wheels and then demanding that other people be impressed by your insanity.
The chances of the latter are bigger than you think. So if it's down to you or another opening, they'll take the other opening, and then you've wasted everyone's time.
Didn't hit it off with the last interviewer so it was a no-go.
If a take-home is required I'd at least expect a code review over it and focus the rest of the interview process on soft skills rather than trivia questions that are answered essentially by the take-home exercise.
1. 2 pms - collab and project management questions.
2. Trivia Q&A with 2 devs and tech projects
3. Lunch with Dir. Eng, and senior dev.
4. Whiteboard leetcode with A researcher and a junior dev.
5. Systems design with Dir. Eng and a senior devops
6. Chat sessionr for questions with VP of Eng.
Of course from their perspective I could be getting someone else to do it for me or something. Or maybe the take-home leaked (which becomes more probable as the company grows).
At my current employer, that’s exactly how we approach hiring. I send the candidate a take-home that broadly covers the basic tech skills they need to be effective in their role (implement a simple test api, some questions about scaling web apps in production, and a possible architecture sketch for a described system). It’s expected to be around 4 hours of work. If they pass that, the interview is free of technical topics - we just talk about your past experience and assess whether you’d be a good fit for the team.
Is this not how other take-home assignments work?
I'm interested to know who your employer is, if you're comfortable saying.
Most people take issue with the repetition of similar tests and evaluations for multiple companies. If A, B, and C were considered different stages of a technical interview, candidates are repeating A and B too often, whereas applying A and B once would suffice for several companies.
It's a problem that is realized when opportunity cost is compounded when interviewing multiple companies and it's not something that a single company alone can fix. A more "Docker-ish" solution where using one of "A" to lay the foundation for many company interviews (and not just the ones expecting you to practice Leetcode) might curtail the problem of using more time and resources than necessary.
But more than that, there is also a cognitive dissonance with the beliefs of how to reform a broken system. Programmers largely oppose industry-wide regulation while also expecting the vetting process to be more consistent and make more sense. This is a tough nut to crack because we seemingly want to have it both ways.
...of programming (because the regulation would never be able to catch up to the state of the art), sure. Of HR practices? I don't think I've ever heard an engineering lead lament that their company's restrictive HR practices prevent them from testing candidates the way they want.
> and it's not something that a single company alone can fix
Sure they can: micro-credentials. Someone needs to be the CompTIA of tiny programming challenges, where you prove once-and-for-all (in a proctored situation) that you can solve FizzBuzz or whatever, and get that fact recorded in some database.
Hopefully, candidates could then put their MicroCredentialsCorp username on their resumes or into companies' application forms or what-have-you; and then first-stage HR automation (the same kind that matches resumes to keywords) could run through a bunch of RESTful predicate-endpoints checks like https://api.example.com/u/derefr/knows/fizzbuzz (which would return either a signed+timestamped blob of credential JSON, or a 404.)
Hopefully also, allow anyone to create a test (maybe have the end of that HTTP route just represent the username+repo of a GitHub repo where an executable test for the micro-skill lives?), such that these micro-credentials can live or die not by central supply, but rather by market demand.
(I think someone suggested doing this with a blockchain once, but there's really no need for that.)
I don't think any of the major companies would accept such a solution. I mean, they make people who already passed their own interviews once re-interview if they leave and come back or apply again too long after they pass and decline. If a company isn't willing to trust its own interview process as a once-and-for-all test, why would they even consider doing so for a third party test?
We could scale this to 3 months on 80% salary (whatever the company is comfortable spending on throwaway) with the full salary after the test period, with maybe even back pay and a little ceremony to make it a big deal. That would kick my ass for three months, cost me nothing long term, put a big smile in my face and let any company hire me without 15 interviews.
Next stage is a technical interview of 60-90 minutes where we a) try to find what their strengths are and how deep they go, and b) ask them to explain how they solved the take-home.
b) is critical. Of course it tests for the skill that is critical in teamwork: communication ability, but it also lets us catch cheaters.
After this it's HR and reference checking.
It's worked well so far.
Got failed for a number of the most trivial reasons - it didn't meet PEP 8 (it was two white space errors, as I didn't have pep installed on my home laptop, so I missed them).
A load of stuff about not mocking tests (setting up that would have doubled the scope of the project). The spec and said if you don't have time, then describe what you would have added in terms of tests - which I did). I did provide the most difficult to implement integration test to prove the system worked.
There was a complaint providing an HTML webpage rather than a JSON endpoint (the spec described it as a "page" and said not to bother with styling - so implied that it was HTML). Plus a couple of other equally ridiculous complains.
Don't waste your time with takehome tests without speaking to someone in engineering first. Sennder is the company if anyone else wants to avoid, I think we should be naming and shaming such companies.
I'm a huge fan of giving people tasks that somewhat resemble a real world problem they'd likely encounter or at least aligns categorically with their proclaimed resume feats and more importantly on top of that giving them the same environment they're comfortable working in on a daily basis which might be on a laptop in a quiet room from 6am to 10am in the morning.
However, I'm usually instantly met with the "oh well we don't want to expect too much of our interview candidates" mentality as if asking them to do a "take home" (rather than telling them to figure out how to take a day off of work for an onsite panel) is somehow grotesquely disrespecting their time and would make the company look bad if the broader community even got a whiff that it had been considered. I'm so confused. People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down.
I've concluded it's a generational thing and the problem won't be fixed until we get a wave of hiring managers that weren't schooled on the Google interview process. But, also note it's a self perpetuating issue too so :shrug:.