One thing that I find interesting during my past two years, is that: when hiring for big corps, you will be focused on things like false positives, false negatives, the “depth” of your interview so people’s level can be properly assessed etc etc. For these, you would find time-boxed well-designed tests, either taking home, or onsite, to be valuable (and ideally have a “guide” so the candidate won’t get lost).
However, hiring for startups (smaller companies), I find alignment may be more valuable, and use that as lens to look into various take home tests startups put out. The problem they put up with can be all-or-bust (thus, no level assessments, you either finish it, or not). Or it could take well beyond 3 hours. These are the filters to find people who are interested in what they do, and don’t mind spend time on the problem.
I did not go through all of these but they seem a lot better then the take home tests I’ve seen which are “simple” things like create a website with a form that submits to a database. Not only does that require me setting up a git repository just for the convenience of being able to save my code, but the amount of setup for even simple projects is immense. Usually there’s a “gotcha” kind of catch where it seems simple but one requirement throws you off. Then there’s the “don’t spend more than a couple hours on this” which turns into literally a day. And since you’re being essentially graded you have to make sure your code is clean and it is so artificial it becomes difficult. Most projects I have that I’m adding features to already have the plumbing setup so what seems like a 30 minute tasks isn’t when you don’t have the advantage of Material UI hooked in, Typescript setup, a make file. All things that are not hard in themselves but a lot to ask for in an interview setting. And you have no idea what aspect of the project the reviewerer will focus on. Do they care you do CSS inline and quick because of the time restraint or do they want you to use something like Svelte? What about unit testing or the myriad of other things I’d consider a competent programmer to at least know what to do.
I’ve actually never had an offer extended for a job that required any kind of take home test. Luckily now I’m very senior and actually in basically upper management but I’ve found that interviewing programmers in a conversational style works the best. Can they hold a conversation? Do they read or keep up on tech news? Do they have a GitHub or any other thing that shows they’ve at least once did some side projects?
I respect the fact that this is a job and I don’t expect people to live and breath software development but I’ve had much greater success with this approach even if I’m not getting some savant programmer who crammed leetcode. I guess larger software companies who just need a lot of devs, or especially junior devs don’t have the same convenience but I feel this is kind of a typical engineer approach to trying to codify something where a simple conversation usually works just as well.
That’s the question, right? In the case of CHPTR‘s quiz, I wasn’t sure if it was hosted knowingly on trytapioca or if it was scraped and duplicated, which seems murkier. But I can still imagine a situation in which a company that doesn’t intend on sharing a challenge widely would be irritated to find it on the site.
The only time I took the option of doing one of these I met the requirements in something like 20 lines of PHP. They didn’t like it because it didn’t do anything that wasn’t explicitly stated in the requirements, nor did it run in some kind of framework, it was just straight PHP pulling data and running with it.
I used to assigned take-home tests during the first round of interview, and discuss the solution in later rounds. Be side the problems itself, I also asked candidate to upload their results to github or gitlab like an open source project. I will check how they wrote the README, the commit message and the project structure. That provides a full view of their engineering capabilities.
We did similar but with a private Perforce server with a private branch for the candidate. We were hiring junior-mid level engineers with 0.5-3 years experience, and this was amazingly valuable, the task was to add a feature to a sample game project. We ended up hiring pretty much anyone that submitted working code. Over half just straight up wouldn’t work, sooo many people would forget to do the equivalent of git add, and not submit their new files.
I’m not sure I’d ding someone too much for the failing to submit the files bit… I think I’d at least give people a heads up that they were missing and a second attempt if that happened.
Perforce is not very commonly seen outside of bigger companies and in a jr role I wouldn’t expect that many people had seen it before. It’s also a model that is kind of different from git and not as familiar any more. Screwing up your first ever attempt at a commit in a new SCM you’ve never seen isn’t that out of the norm, is it?
Eh the best hires we ever got from this process told us that they explicitly deleted everything and re-synced (either force syncing, or creating a new workspace, or what ever) to make sure their stuff worked fine from scratch. Just an attention to detail kind of thing, which ended up being reflected in their work long term.
Perforce is the standard in our industry, so aside from those that were coming from small indie studios almost all of them had at least exposure to perforce (much more-so than git!)
One thing that I find interesting during my past two years, is that: when hiring for big corps, you will be focused on things like false positives, false negatives, the “depth” of your interview so people’s level can be properly assessed etc etc. For these, you would find time-boxed well-designed tests, either taking home, or onsite, to be valuable (and ideally have a “guide” so the candidate won’t get lost).
However, hiring for startups (smaller companies), I find alignment may be more valuable, and use that as lens to look into various take home tests startups put out. The problem they put up with can be all-or-bust (thus, no level assessments, you either finish it, or not). Or it could take well beyond 3 hours. These are the filters to find people who are interested in what they do, and don’t mind spend time on the problem.
I did not go through all of these but they seem a lot better then the take home tests I’ve seen which are “simple” things like create a website with a form that submits to a database. Not only does that require me setting up a git repository just for the convenience of being able to save my code, but the amount of setup for even simple projects is immense. Usually there’s a “gotcha” kind of catch where it seems simple but one requirement throws you off. Then there’s the “don’t spend more than a couple hours on this” which turns into literally a day. And since you’re being essentially graded you have to make sure your code is clean and it is so artificial it becomes difficult. Most projects I have that I’m adding features to already have the plumbing setup so what seems like a 30 minute tasks isn’t when you don’t have the advantage of Material UI hooked in, Typescript setup, a make file. All things that are not hard in themselves but a lot to ask for in an interview setting. And you have no idea what aspect of the project the reviewerer will focus on. Do they care you do CSS inline and quick because of the time restraint or do they want you to use something like Svelte? What about unit testing or the myriad of other things I’d consider a competent programmer to at least know what to do.
I’ve actually never had an offer extended for a job that required any kind of take home test. Luckily now I’m very senior and actually in basically upper management but I’ve found that interviewing programmers in a conversational style works the best. Can they hold a conversation? Do they read or keep up on tech news? Do they have a GitHub or any other thing that shows they’ve at least once did some side projects?
I respect the fact that this is a job and I don’t expect people to live and breath software development but I’ve had much greater success with this approach even if I’m not getting some savant programmer who crammed leetcode. I guess larger software companies who just need a lot of devs, or especially junior devs don’t have the same convenience but I feel this is kind of a typical engineer approach to trying to codify something where a simple conversation usually works just as well.
I wonder if these companies agreed to have their take-home tests posted on this site or if they were just scraped.
Should they have to agree?
(That is, should one object to featuring on a “collection of X” website if one publishes an “X” to the public Internet?)
That’s the question, right? In the case of CHPTR‘s quiz, I wasn’t sure if it was hosted knowingly on trytapioca or if it was scraped and duplicated, which seems murkier. But I can still imagine a situation in which a company that doesn’t intend on sharing a challenge widely would be irritated to find it on the site.
The only time I took the option of doing one of these I met the requirements in something like 20 lines of PHP. They didn’t like it because it didn’t do anything that wasn’t explicitly stated in the requirements, nor did it run in some kind of framework, it was just straight PHP pulling data and running with it.
I used to assigned take-home tests during the first round of interview, and discuss the solution in later rounds. Be side the problems itself, I also asked candidate to upload their results to github or gitlab like an open source project. I will check how they wrote the README, the commit message and the project structure. That provides a full view of their engineering capabilities.
We did similar but with a private Perforce server with a private branch for the candidate. We were hiring junior-mid level engineers with 0.5-3 years experience, and this was amazingly valuable, the task was to add a feature to a sample game project. We ended up hiring pretty much anyone that submitted working code. Over half just straight up wouldn’t work, sooo many people would forget to do the equivalent of git add, and not submit their new files.
I’m not sure I’d ding someone too much for the failing to submit the files bit… I think I’d at least give people a heads up that they were missing and a second attempt if that happened.
Perforce is not very commonly seen outside of bigger companies and in a jr role I wouldn’t expect that many people had seen it before. It’s also a model that is kind of different from git and not as familiar any more. Screwing up your first ever attempt at a commit in a new SCM you’ve never seen isn’t that out of the norm, is it?
Eh the best hires we ever got from this process told us that they explicitly deleted everything and re-synced (either force syncing, or creating a new workspace, or what ever) to make sure their stuff worked fine from scratch. Just an attention to detail kind of thing, which ended up being reflected in their work long term.
Perforce is the standard in our industry, so aside from those that were coming from small indie studios almost all of them had at least exposure to perforce (much more-so than git!)