Guide to Take-home Coding Challenges
fullstackinterviewing.com
fullstackinterviewing.com
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.
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.
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.
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?
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?
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.
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.
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
I dislike take-home tests less than I dislike whiteboard interviews, so I try to be flexible, without being a pushover.
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.
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.
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.
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.
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.
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.
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.
Someone really good will already have a full time job, a limited number of "sick days" to use for interviewing and is probably somewhere in the interview process with at least 3 other companies -- probably closer to 5 or 7. Then they might have family responsibilities on top of that.
I budget 4, maybe 6 hours if I really like you, on any company in the application process -- tops. Almost 100% of this time is taken up by interviews. You want me to give your company a whole weekend of my time on some chance that you might hire me? In addition to hours of interviews? That already tells me that I don't want to work for you -- especially if I haven't at least interviewed with 3 technical people already. It's one of the clearest negative signals I know of.
If I work 13 days in a row without a day off, I'm going to be a crabby asshole at my job and probably blow all of my other interviews until I recuperate. Your company isn't worth that.
After some years of experience, I can't see myself doing one of these again pretty much ever.
If you’re interviewing with 7 (!) companies at a time, maybe be a little more discerning about where you’re trying to work. Everybody wins if you’re specific on that point.
Oh please, honestly. I'm not a terribly good programmer, but after 2+ years at one company, my inbox was flooded with emails from recruiters representing companies with very interesting opportunities (and like 10x as much crap). Then there's the friends and former coworkers who have been regularly asking me to come work with them.
Once I made the decision to leave my last company, I talked to about 9 companies over a 1.5 month period, and it only lasted that long because of Christmas & New Years. At least 5 of those went through multiple interview rounds and I was juggling 4 different, attractive offers before picking one. This is just from the 9 that I decided to talk to...
I live in a major market and there's a lot of demand here and in my focus areas. A lot of companies that you don't think have interesting problems actually have fascinating problems to work on once you talk to them. Probably much more so than GOOG, FB, AMZN, etc.
You talk about being discerning, but how do you know if you can deliver value until you have a conversation with them? You end up talking to that many companies at once because once you start the process with them you have to be respectful and see their process through to the end, but you don't stop interviewing while you wait for a decision.
- 4-5 year expected commitment.
- 4-5 man-days between both parties.
Anyway, talking to a company is rather different than interviewing. Sure, explore opportunities. But no need to write a line of code until they’ve made an attractive proposition. I’d be surprised to see that happen 7 times within a week or two.
It's very interesting how even the Internet mega-giants haven't solved distributed working enough that they can avoid paying the massive premium for people to move to SF.
The author raises that point:
https://www.fullstackinterviewing.com/2018/02/02/the-ultimat...
But takes the wrong view on it in my opinion. The answer simply can't be "Just spend as long as it takes".
That point is the thing that led me to build a tool that enforces time limits on challenges via a custom git server. I used it to interview around 100 candidates at a company I was running at the time and it was an excellent approach.
I've since productised it as https://takehome.io/
If you want the benefits that take-home coding challenges can bring to your hiring process, but are concerned about treating your candidates humanely, I urge you to check it out.
What are your thoughts on timed coding problems like Codility or Hackerrank?
My contention is that it doesn't matter if the time limit is unrealistic (within reason) so long as it's consistent.
ie: the challenge is not "Show me the best solution to this problem" but rather "Show me the best solution to this problem that you can achieve within an hour".
As long as everyone is under the same conditions, the playing field is level.
It's part of a holistic approach, too. The coding challenge is not the only part of the interview process. I suggest that there be an initial interview to assess experience, fit, explain the job, etc. Then if everyone is still interested, the coding challenge. The candidate's response to the challenge then forms the basis for a discussion in another, technically focused interview.
It's not about saying "You gave the wrong answer" but "Talk me through why you solved it this way" and "If this criteria in the challenge changed, tell me about how that might change your response"
The Codility and Hackerrank style problems are okay, but I don't like how constrained they are. I also think it's pointless having someone outside your organisation grade the results. What matters is not having a candidate who is "the best hacker" but having someone who fits what you need. If your team values robustness and debuggability above all else, you _don't_ want someone who can punch out 3 kinda-right prototypes before lunch. If you're an ideation agency, the inverse is true.
That's why takehome encourages companies to create and administer their own challenges rather than the samples. They should fit the kinds of problems your organisation faces, not contrived ones.
I like what you said about the importance of companies administering their own challenges as well. I've encountered some like that and they do tend to be a better reflection of the types of challenges and problems the company is facing.
But there is a problem. In the past when I have worked on take home challenges which usually take 3 hours or thereabouts, I have done them in 3 sessions of 1 hour each in the evening after work:
1 hour: think about the problem in detail making some notes for scenarios, edge cases, high level API design etc 2nd hour: first rough cut working draft with some test coverage 3rd hour: polish it up with more tests, docs, a README and sending it out.
I think `takehome.io` should account for time boxing across multiple sessions, else it might be pretty much useless for working engineers who do it across time boxed sessions :-)
PS: I apologize in advance if you already have this feature, but is not so readily evident on your product home page.
I don't have that feature, because I would argue that a problem you attack in three 1 hour stints across a span of 72 hours is a 72 hour problem.
Writing software is so much more than just typing. I tend to do my best coding in the shower or driving, nowhere near a computer. As soon as the challenge has been loaded into your brain, the work starts and the timer starts. How much of that time you spend in front of the keyboard is up to you.
Incidentally, I also think that a time limit of longer than an hour is probably too long. Uninterrupted multi-hour blocks are pretty hard to come by. Even if the time limit given isn't enough time for you to complete a perfect, working solution to the problem, it should be enough time for you to do enough work that we've got something meaty to talk about in the next interview.
It can be done in 2 hours in the most simplistic, undeliberated way using legacy practices, but 8 if you're a perfectionist. Come in somewhere in the middle, but stop at 4 hours no matter where you're at.
I don't even require that the exercise is completed, but I want you to speak to your thought process and where you went/were going when you hit the 4 hour mark. The ability to understand our space, make good decisions, and show progress toward executing on them is ultimately what matters in the end.
I don't mean to shill, but I think it'll be a great fit for you.
I totally understand the value of coding challenges, but I've been endlessly surprised at companies that expect me to expend more than 4 hours of my life interviewing for a chance at a job that will be paying maximum 50k. These are small companies, hardly the big 4. It's really an imposition.
For this reason and this reason alone, I will continue to advocate for take-home coding challenges.
(1) IMHO, the best practical solution is a pair-programming interview using a real bug or feature the company has already solved.
You will never know what someone is capable of in a few hours. People who think that works are just fooling themselves and turning away good talent.
I guess the goal is to fine tune your interviewing process based on how past candidates turned out.
The irony of it is putting processes like this is actually turning away good talent, but they wouldn't know, because they aren't doing any analysis; they just read an article somewhere.
Has "traditional interviewing" undergone any scientific study for determining if it "works"?
Also, there is no distinction between a full time job and a temporary contract in terms of survivability in the US. Most states are at-will states, and not being able to do the work is a fire-able offense. Just about everyone knows this.
Most people who have been in the business a while aren't willing to move to a new city, again unless you are willing to pay ungodly sums of money. If you are hiring right out of college and junior-mid's, this technique is better suited, but still, you're competing poorly in a seller's market.
I mean, just because you are hiring and paying a salary doesn't mean 20 other companies in your area aren't doing the same. What makes you better? Certainly not market rates and certainly not your exhaustive and mostly ineffective interview process.
You want a good person, ask your tops if they know anyone good, then try to lure them away with an offer of 1.2x - 1.5x market rates, depending on the return you expect from them. Trust your tops and don't put them through this silly process. Have the top interview them with you in the room. Spend about an hour with them to make sure they aren't some weirdo. Trust me, they'll respect you more if you respect their time.
I get that other developers get paid well to program so a lot of them are put-off by doing their job for "free." However, There's a simple solution of which has already been mentioned: cater the challenge to be completed within a few hours. Time-lock it and urge the applicants to only spend X number of hours on the challenge.
Like I have mentioned in another comment, I've been part of in-person interviews that lasted all day on top of an HR and technical phone interview. If I could cut down the in-person interview to just "personality fit" then that would be my preference.
1) I spent 6 hours on it. I didn't do some of the "optional" parts (unit tests specifically) because I felt like 6 hours was enough to "show I can program" i.e. what it was supposed to do worked. Result: I got grilled over why the optional parts weren't there and didn't get an offer.
2) I spent 15 hours on it. I did everything I could think of on it including 50ish unit tests and more than what was asked for. Result: I got and accepted the job. (note: I had laid out my salary requirements before hand).
Is this "great"? I have an active github/open source profile. To me in both cases they basically wanted to waste my time and mental effort, and see if I would do it. That.. can't be ideal.
Oh, you had dinner plans tonight? You want to see your kids before they go to bed? Sorry, our engineering team generally works 11am-8pm. You need to be in the office.
I know many companies don't explicitly require tests, but for them if a candidate submits a take-home challenge without them, its an automatic rejection. Do you think that if you had included tests in that first challenge that you would have gotten an offer?
Interviewing all candidates in a pair programming setting risks weeding out all the people who are great at the job, but get anxious in a paired interview scenario.
A job interview is already pretty stressful and anxiety inducing. Adding somebody looking over your shoulder while you type into that mix can be really rough on some people.
Whiteboarding is only good for those who are fresh out of college.
I like the idea of take home projects but it shouldn't come right after a phone screen or even the first real interview. More like as close to the last step as possible.
And then there's the question of what other professions ask candidates to work X hours for free. Let's assume our field is too special and not get too deep into the rabbit role ;)
Also, you're likely to be homogenizing your applicant base. Expect to see many more young people and recent grads versus people with kids.
Ultimately, it's not the applicant's choice what the parameters of the interview process are (I commend you for working to make it better) - given that, why shouldn't an applicant try to give themselves an edge in the process?
- did every dev at the company pass it at some point? (If so you should know fairly accurately how long it takes)
- does it replace the majority of the interview time? (If not you probably don’t actually get why it’s important)
This is why you put a timer on the take home, it is better for everybody involved.
Here is the breakdown of the worst one I've been part of:
* Initial phone screening with HR (~1 hr) * Technical interview over phone (~1-2 hr) * In person technical interview (~8 hr)
I kid you not, I had to take an entire day off work to be part of a grueling in-person interview where I met multiple teams.
This is also not taking into account the amount of time I had to exchange emails.
I would take a take-home assignment in the comfort of my own home, spanning 16 hours instead of an all-day in person interview.
More senior and skilled people will decline to participate, because they know they can get a better return using the time otherwise spent on the coding challenge to network for more and easier opportunities.
So now you've done a great job of raising the floor of your interviews for little direct cost, but you've also lowered the ceiling.
Absolutely this. No top would put up with this unless the company is paying an ungodly sum of money.
A better option might be to just hire me as a consultant for some real ticket of yours and let me work it in off hours. Then we both win.
The last take home was a 6 hours exercise. I did not really see it at an huge opportunity cost.
I would have trained 10 times that for a whiteboard entirely unrelated to my day to day job.
We are also looking at ways we can make this exercise easier for everybody by providing a template with some of the basic boilerplate already written for the applicant.
It is difficult to find a happy medium between a trivial exercise and something you can work on for hundred of hours but I think we have something fair.
I find it interesting that you put your limit at 4 hours. It is not that much smaller than 6. Anecdotally 6 hours is the maximum timing .. if an aplicant said they only had 4 hours that day but delivered something solid in that time frame I would vote for them.
4 hours means that I can do it within half a day on weekend and then spend the rest of the day with something else - going somewhere. At minimum, I can send kids outside with someone and be 4 hours alone at home to focus. Or I can do it 2 hours one evening and 2 hours another one - two days.
6 hours means that I spent most day with it. Expecting them to be outside 6 hours in row is a lot and so is blocking one room for that long. It would also mean 3 evenings not just 2.
> At the same time we are now looking for less senior engineers.
That is cool. (Really, all too many companies like to pretend that juniors don't exists or cant learn or just should magically become seniors instantly. Meanwhile, junior can the right person for the job.)
Makes sense, thanks for answering. Yeah for 6 hours you probably need to leave work a little bit early or work until late at night (if you want to fit it in your work week).
The way we setup the take home, you can't work on it for several evenings in a row : we have a 24h timer starting when you first see what you have to do. So you can do it over a full day if you want (like 2 hours in the morning and 2 more in the evening) but you can't work on it 60 hours over a week (that's the main potential issue I can see with take homes .. it encourages you to spend a lot of time in order to show off)
>Really, all too many companies like to pretend that juniors don't exists or cant learn .
Yeah, in all fairness a junior is a lot of work. You basically make the bet to lose 20% (made up number) of productivity for a year in order to mentor somebody in the hope that this person will stay for a while and grow.
However, we already spend so much time interviewing people that honestly I can't be convinced that only hiring 'best in the world' engineers is such a great idea.
I completely disagree with this assessment and I'll even reverse it: turning down a job opportunity simply because they requested a take-home challenge could shut you out of good opportunities.
Furthermore, no matter the interview style, there's going to be a bias.
Some people are great at white boarding, so they naturally want to take those as well as conduct them. Some interviews are all about personality fit, great, everyone will work together well.
I'm a senior engineer and would gladly accept a take-home challenge.
Ultimately as an interviewee I'd like to spend the least amount of time demonstrating the most amount of my abilities while at the same time getting a firm grasp of the company and how they conduct themselves. I firmly believe that take-home coding challenges could play a part in that balancing act between measuring competency and not wasting my time.
The response was that an interval tree was the correct data structure to use in order to pass the performance component of the assignment and that they were not interested in continuing with me any further. In hindsight I should have reached out to validate whether an interval tree was "too clever", and I think that was a more important factor in my failure than anything.
This can restrict your pool of candidates quite dramatically, as most US companies seem to have their engineers sign such agreements.
1. The challenge was timed, and limited to 3 hours. This is critical, because it respects the applicant's time. 2. Similarly, other interviewing was limited to a very brief "are you actually a developer at all" phone screen and a 30 minute personality interview. 3. I was allowed to choose the framework and language I was most comfortable with, demonstrating that the employer was interested in how well I worked, not in how well I knew the particular framework chosen for their product. I think it probably helped that I used the same stack advertised in the job description, but I appreciate the flexibility being there.
Interviewing is a separate skill from software development. A take-home challenge isn't necessarily going to tell you everything about a person, but it seems to sort candidates into high/medium/low skill levels with a higher degree of accuracy than a paper or whiteboard tech interview.
Interviews, technical or not is a psychological process. Ask them about their previous projects, ask them what their favorite projects were and why. Ask them what their least favorite projects were and why. Ask them what the hardest thing they've worked on to date was and why.
It would be like personal projects but with a few guarantees on top, like that the candidate got the work assigned by someone else, and s/he did it under some time/other constraints. And there would perhaps be a public free-form feedback from the other comapny (no rating). So the next comapny has to judge the work itself without ability to pre-filter based on whatever rating the previous one would have given (to avoid bias, because the scoring would be non-objective/non-standardized).
But I would still not like the take-homes. :)
It's not a reflection on your or the article, it's more of a reflection of how silly tech interviews are these days.
Furthermore, for entry level positions -- candidates right out of college -- how do you measure competency?
Interviews need to test for certain characteristics in a limited amount of time. Even if there was some way to say "here's the code I've wrote, e-mails I've sent, and videos of me leading team meetings in the last year", no company would have the time to look at those materials.
As such, we're stuck with the common question formats trying to determine if you communicate with your interviewer well (understanding what's being asked, explaining your thought process and what you're trying to accomplish, talking about anecdotes and building rapport) while also showing off some technical understanding of implementation and design. No one's yet found a better system that's more respectful of both the company's time and the candidate's time.
These "take home projects" are an interesting variation that I'm not going to dismiss out of hand, but it's hard enough to take 8 hours out of my day for an interview loop - adding more hours in the evenings isn't something that scales well to interviewing with a bunch of places.
Do you think this issue is less pronounced with the move toward companies providing compensation guidelines up front?
I would choose a take-home coding challenge over any white boarding challenges.
Even though most of us are not real engineers who studied BEs, the title has more prestige than developer (or god forbid, programmer).
This will theoretically let me gauge their attention to detail. Ideally I think it would show me how familiar they are with the programming language the snippet was written in as well.