1. Require developers to code on demand during an interview (personally, I have a hard time with this; the pressure of an interview is not a normal working situation).
2. Allow someone to do it on their own time, under no time pressure. (I advocate paying them for their time at a fair market rate).
Do you see another way of a senior developer demonstrating their abilities without hitting either of the two above?
For the junior folks, sure: have them burn through homework.
In my case, I do a lot of writing these days and, if someone were to ask me to write a thousand word analysis on some topic I was familiar with, I certainly could knock that off in a few hours. But, assuming I agreed to do it at all as part of the interview process--I'd be far more inclined to just give them a bunch of links to my work--I'm going to put the effort in to come up with a tight, polished product.
Also, I highly suspect companies who are having trouble hiring senior devs are having issues stemming from not paying enough for their given situation.
Companies like Square and Stripe have project-centered rounds during their onsite that allows them to assess these skills without giving a take home.
I'm not going to jump through stupid hoops, but I love jumping through interesting hoops.
Aren't you already spending many hours researching a job as the part of the process? Aren't you already taking a full day off work for the interviews? Why is that time all fine to spend, but not fine to spend a couple of hours on doing an assignment?
Coding tests are just an early stage filter for experienced people - so those companies get dropped early on.
You don't want to get your developers together for any random loser who'd never want in your team anyway. So the coding is a late stage filter.
At least for me it's always been.
And Martin any professional should adapt to the systems in place - and I wouldn't use terms like "random luser" might have some blowback.
And if they're not interested in putting any time or effort into a new job, it seems to me they're probably not that interested in that new job in the first place.
But it seems weird to me that so many people here consider a whole day of interviews to be totally acceptable, while some actual coding is not. Compared to some of the interview horror stories I often read here, this seems vastly preferable. I actually get to show what I can do in a realistic setting, and I get to explain why I do what I do. I get to meet the other developers and talk to them.
And with the best programming tests, I actually get to learn something new. For the best one, I had to learn React (which I had no experience in), build a game board on which you can put obstacles, and write an algorithm to find the shortest part through the resulting maze. (I ended up rejecting that job because it was too far away and not enough pay, but I'm still really happy I did that coding challenge.)
I do agree about a daylong set of interviews with 4 or 5 people that's also a filter id use.
In my experience, these sort of tests do often seem to be used by the more interesting, more competent kind of companies. The first company where I encountered this (14 years ago), had only highly competent developers, many of them committers to various open source projects. About the recent one where I wrote a customised version of A* (because of the presence of wormholes, which made it not remotely rote for me or for most people, I'd expect), I of course don't know how it would have turned out had I taken the job, but if they select for this kind of thinking, I see that as a very positive signal about the kind of work they do and the kind of people they hire.
At companies that didn't have this kind of test, the quality of their developers was a lot more hit-and-miss.
At least for permanent employees; I've never encountered this for freelancers.
I certainly didn't get asked coding Questions when I went to BHRA (ranked 1 or 2 in its field) research organisation.
I was told in my first week "oh there is a book on Fortran in the library" teach yourself it
But it's very likely different for research institutes. I'm talking about companies.
I've never had a full day interview for a company I'd actually want to work for (based on what I've learned while grinding through the interviews) so I'm beginning to take requests for those (along with requests for advance coding exercises) as a recruiting smell.
My team has full-day interviews and I'm curious to see who has been self-selecting out of this.
Anyone with any level of self-confidence, worth and respect.
I suppose there are distributed companies that just do things over video link these days (and I've interviewed people over a video link when necessitated by travel schedules or people being in different locations). But some number of in-person interviews over the course of 4 or 5 hours is absolutely standard in my experience.
For permanent jobs, it's usually an hour long interview followed by a programming assessment; either take-home and then presenting to their developers, or codility. But for freelance work, none of that. Just a talk and they hire me. But of course if I turn out to be useless, a freelancer is easy to fire.
(I don't like video interviews much.)
As for hiring freelancers, I'm not involved in hiring programmers but we use external people for various other things. We've try to use people we have experience with but it's mostly not a big deal. If we don't like the work they do, maybe we're out a few bucks but we just don't hire them again.
If I'm unemployed, then full day is fine. If I'm really keen to get out of my current job, or really keen to work for you, then I might do it. But if I'm just exploring opportunities, or I have other options in progress, then I'm not taking a day off just to interview.
With any interview when it might be really obvious 10 minutes in that it's not going to work. If I've scheduled that during my lunch break, or for an hour before/after work, then that's a small cost.
If I take a day off work to interview, then that's costing me in the order of $1000. If I don't know whether I want to work for you, then why would I do it? And I definitely can't do that for 5-10 different roles that I might apply for.
A full day is also quite hard work. Interviews are stressful. Dealing with people you don't know, trying to make sure you don't do/say something stupid, it gets exhausting.
I generally expect 4-6 hours worth of interviews before an offer, but the typical process stretches those over a few weeks, which allows the candidate to fit them into available blocks of free time, and gives the candidate oppotunities to think about how things went, what questions to ask, whether this seems like the right fit, and pull out at any point.
We have had a perpetual shortage of developers though, it sounds much harder to land a job in the US.
But even when the interview process was mostly a formality because I knew many of the people and they knew my work, I still had some on-site interviews.
I'm pretty sure on-site interviews are the norm for the vast majority of professional jobs. Including, or perhaps especially, for the most senior positions.
I'd much rather do a take-home test than spend a full day getting grilled in interviews.
I should clarify that I was thinking more of outfits that respond to my enquiry with "Hi $candidate, please do this generic exercise after which we'll deign to look at your CV". Bonus points awarded/deducted if the requested exercise is for something already available on my github profile.
And 4-6 hours is typically my free time (not free computer time, total free time) for a week.
So essentially about 4 hours of time. What makes this different from a company that wants 4 interviews from different managers, which likely takes up more time plus all of it being fixed time slots, versus having one hour of work that you can work on at your own pace?
In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code.
This follows no industry standard, and I can count multiple experiences where they were too inept to “grade” the homework assignment, thinking it didn’t work when it did, or that the problem set was impossible.
The reason senior engineers in particular turn down homeworks is because they’ve been burned by them before, and the average hiring engineer tends to know less than they do (but as the hiring manager, can’t assess it, mistaking competence for arrogance or ineptitude).
When a company is not willing to invest the same amount of time to interview as they ask of the candidate, it’s a strong signal of how serious they are as a quality employer.
When job hunting as a senior, hearing about take homes (esp. early stage ones) is the young person’s dating equivalent of considering a relationship with someone divorced twice and a felony. You just get conditioned to pass up kissing frogs.
Everything else is simply busy work for all parties because it doesn’t tell you anything you don’t already know, plus it scares away quality candidates.
Does anyone know if having different tracks is legal?
You don't even really need a probationary period in an "at will" state.
At some point, you either trust the credentials from universities and certification bodies, and take what the resume says at face value, or you have to try to reinvent some wheels, and re-discover that eliminating the phonies and mimics is a very difficult problem that even the experts can't solve entirely.
I don't know what the conversion factor is between running a fruitless job search filled with cargo-culted bozo tasks, and just randomly picking the first vaguely suitable candidate off the stack and letting them run for a few months, but I suspect that filling the position quickly and painlessly is probably worth about one month of having a 0%ile employee, or six months of a 20%ile, or keeping a 40%ile employee until they retire. This rests on the presumption that some work done right now is worth more than the same amount done some time in the future, and that higher %ile-ranked candidates will be less tolerant of any stupid hiring games.
At my current employer, our recruiting manager has a preliminary talk with the candidate and if there seems to be mutual interest in continuing in the process, she sends a simple task. The task was defined by the technical team, it should be short (no more than an hour) and it has nothing to do with our work.
Once she receives the submitted task, we ask everyone in the tech team to make a review. We do have a "gold standard implementation", but we know that no one will get it and we don't care. We had cases of candidates that misunderstood the task and we had no issue with giving them a second chance or simply asking what was unclear and what would they do differently had they had got the intended requirements.
We just want to filter the obvious "no hires" from the ones with potential. The recruiting manager communicates this even before the task is submitted to them. I am yet to hear any story of any candidate that was interested in the position but walked away due to the way that the process is conducted.
Thank you for making my point. Why would you ever hear about it?
This is the "British Rails" fallacy in action. (A long time ago, the British Rail organization had heard complaints that residents of a local community weren't satisfied with the once-daily train service it received. Its response was there was no need for a second train, because at the times considered, no one was standing on the platform waiting to board it).
Nice coconut earmuffs.
Seems like the one that does not want to listen is you.
The take home task is only communicated during the preliminary interview with the recruiter (i.e, it is not something that is required to start the application process) and we do get feedback from candidates that have withdrawn their application. And while we had cases of people that withdrawn for various reasons (company size/culture, process adopted, being too "startupy" for a German company, or even simply getting a better offer somewhere else) the take-home task is yet to be mentioned as an issue.
In the end, your reasons for being against take-home tasks are not really against the idea of take-home tasks, just some of the implementations you've been through. Your "point" does not stand.
It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters.
I also avoid anyone who wants me to do a coding exercise for a few hours over the weekend.
If you want pay me for that time, and make it not a dig and fill hole exercise - find a OSS project that needs some contributions. Decide that you and your team will do thsoe via your ongoing interview process that hires people before the need arises, so you can all take your time selecting and onboarding people.
Value your own time, or no one will
It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).
I could set up one of our OSS projects with first-contribution issues and help walk someone through but I suspect most people would rather not spend the time. If it takes 4 hours with back-and-forth in the PR (simply because I may be asleep when you commit and you when I comment) that's a big request of any person.
The main antagonism here is that the hiring company wants to minimise its effort in getting great devs, and the devs want to minimise their effort in getting great jobs.
The first point to note is that constant marketing is the first, best solution to this. I would definitely put more effort into joining a well-marketed company (StackOverflow?) than J.Random Inc. So both me and J.Random Inc had better put some effort into standing out from the crowd.
OSS is one seemingly good way to do this - and having a reasonable Github account is something I would say should get you through most interview filters (ie if you are looking for a Python dev, and they have commits to say a flask extension or bits of salt-stack, then you can blip over the Fizzbuzz and whiteboards.)
But marketing is simply a way to get past other people's filters. "Networking" is good, whatever that might mean, and being a good citizen works. but these are as always, long term, constant application efforts. And of course, costly.
Secondly get over the "we only hire the best of the best of the best". If that's true then like the SEALs you clearly have a six month training programme that takes the best and shapes them into effective teams, fully paid while they learn - yes? And the training staff for this programme are pulled off current fee-paying projects to keep up the standards yes? Otherwise your best-of-the-best is so much auto-trumpet blowing. So please leave that at home. Focus on process not heroes.
The interview by takehome project is a big problem.
Yes it clearly weeds out candidates - mostly by making the ones with options elsewhere go elsewhere. (Even Google, with its firehose of applicants, seemed to realise this was a dumb idea and instead used the MIT graduate program as a filter instead).
My main issue with interviews-by-homework is it is usually a hole-dig-and-fill session as the problem has been done by dozens of people before (often you can find their solutions on github). My time is then valued at less than zero. As a filter before we get to interview, it really is just an artifical hurdle. All you are saying is that "we have soooo much choice we can make you dance before talking to you" - if it works for you great. Your marketing is working (see above)
IMO a better approach is to find different existing properties that you can filter to get applicants to the interview.
Sometimes these are "Alpha Male" filters like 1st class honours at MIT. Other people on HN stand by different filters - I seem to remember someone saying one of their best hires had taught themselves coding whilst getting off drugs in a Glasgow slum. How you filter for that is harder than the MIT problem but I bet its a less tapped seam than MIT.
Overall, a good interview process is probably focusing on the wrong end of the problem. If you have a new open position and then you start looking its too late. Be a good OSS citizen, be involved in the community of developers (OSS and elsewhere), find ways to reach out to unusual developers, or people not marketing themselves, and keep the process going constantly, with suitable investment. The general Big Co idea of "you cannot put out job ads before you have a signed off budget and position" tends to make this a problem. A solution would be to take the expected Agency percentages for each new hire (between 5-20%) and put it into a centralised "developer evangelist" team that just gets people through the door.
This way when you need to open a new position, you will have four people in mind you already want to hire, and you can just go to Starbucks for an interview.
But coming fresh and new into a company, it's hard to just have your opinion or taste taken seriously - especially where that opinion will be unpopular (ie your code base needs rewriting from scratch)
So FU money is needed to avoid the tendency "just to go along with it for a bit"
Hire rich people is hardly a great line, but it will have benefits.
Hiring desperate people with no other options does not sound like you are winning of course
What if 9 great companies give just 2 hours of homework and 1 gives none?
I rarely start anything these days without thinking about the problem thoroughly. It results in longer development times, but better designed, and more robust software, or so I hope.