I’ve seen people chat about interview processes quite a bit in here - my company is re-evaluating a “4-5 hour take home assignment” for better methods, and curious if anybody could share what methods work for them? We are quickly growing, so we’re wasting years of cumulative dev time between all of our applicants and also wasting a lot of our dev time by having to review all of their submissions.
I like companies that give you alternative of take home task vs giving a presentation of some code you already wrote, like a OS (or otherwise hobby) project. But of course with this approach assumes is that the “take home task” is just a starting point present, review and discuss some real code with the candidate and understand their choices etc. Which in my opinion is much more valuable than checking if someone can write fizz-buzz or a helloworld restful service..
having said I’d much rather prefer the approach described here and that’s more or less what we do at Kevel. The advice above was for the case when you really have to have an interview with code on the screen https://clojurians.slack.com/archives/C0KL616MN/p1619018912073900
@trailcapital I think that as @hmoorefarley said, it's pretty common to have home assignments taking a lot more time than expected. I think that one way to address this is to curate carefully what kind of exercise must be present as options and test-drive with someone inside the team so that you can verify if it's still possible to solve it in the proposed timeframe.
our take home is fairly open ended. We do specify that no candidate should spend more than 4 hours on it - and that it is fine to submit something incomplete w/ a paragraph or two of what they were going for. Of course, there is no way to stop people from going ahead and spending 20 hours on it
I think we do a good job internally of equally valuing completed take homes and incomplete take homes, but of course the candidate will assume a completed take home == better impressioon
Yes, this is why it's important to be a narrow problem. Nubank has a roll of pretty simple exercises that capture the essence of their business and allow everyone to solve a problem as straightforward as possible. They tend to strip web APIs for instance, too much boilerplate, and focus on simple data processing using simple standard IO, at most.
For instance, "given that you have a bunch of json-lines in a file, each line representing a transaction, give-me some sort of result..."
Better than ask for a fully implemented web api. Anyone can make web server boilerplate. I think that the main objective of a test is to verify if a developer can: • Understand the requirements of the problem at hand • Communicate with the team about doubts, given that in real-life business requirements are ambiguous • Develop a proper solution using best practices as tests, segregation of IO logic, etc
And you can do that even if the problem can be solved in a REPL gist
Do companies just go straight to on-site if a candidates resume checks out? How do you avoid bringing everybody into a 4-5 hour onsite?
I found it pretty amazing how many candidates weren't able to do a Fizzbuzz at-home problem, so maybe 2 hours tops if you gold plate everything, so I think it is a useful filter
You have to be mindful that not everyone has 2 hours to spend on your finely crafted interview problem though, and if someone asked me to do 4 hours free work I probably wouldn't be too pleased about it2👍
I prefer take home assignments, even if they are 4-5 hours long. I have 2 kids (1-3 years) and would be able to find an hour here and there to complete the task. But that just my point of view.1💯
I don’t understand the 4-5 hour interview at all, be it take-home or in person. I’ve worked with some amazingly smart, talented, hard working, and committed people in my 25 year career and none of them had a 4-5 hour interview. Sure, I’ve also worked with some duds but they tended to become apparent very quickly and were either let go or they quit.2👍
Depending on the company and who they are looking for, I would suggest different approaches. In any case, being flexible and allowing time together with current employees is generally helpful.
@trailcapital Check out the pinned items for some relevant info.1👍1🙏1
One size fits all approaches are all wrong for everyone 🙂1👍
@ashnur You’re right in that time spent with current employees is critical. When I think of “interview” I think of one-on-one with one or more people being grilled about this and that technology/approach/etc… I think inviting the candidate to an informal lunch with a few people is a good addition to an interview process. People naturally bond over food so if the team and/or the candidate feel like there isn’t a good fit after that then you’ve saved everybody some time at the cost of a team lunch.1👍
I actually am in the same boat - 4 hours is not a big deal for me, since I typically enjoy these style projects and really dislike whiteboarding. However, we do get a lot of candidates who complain about the take home
So, maybe it would be good to give them choice. :thinking_face:
@ashnur I agree having different approaches could be nice. I am someone who would actually prefer the 4 hour take home than a 1 hour whiteboard session1👍
@darrell how long is an interview you’d run? What sort of things do you do to see if the candidate does have at least some technical capability?
@trailcapital The way things work at World Singles Networks is that after resume review by HR and then engineering, we have an initial phone screen conducted by HR which is to get a “human” perspective on whether the candidate seems serious about the role and whether they’ll fit in (we’re a very small company but very diverse and we deal with a global market with a heavy focus on Arab and African verticals, plus many others). Based on that screening call we may go forward with an engineering interview — typically an hour — directed by my mind map of topics (see pinned items in this channel). Not really a technical interview — we abhor on-the-spot coding challenges and “trick question” stuff — and if they do well there, they’ll usually be interviewed by senior management, again more for “human” aspects. We don’t do take home problems or any other pure technical filtering because, frankly, those methods are pretty much all broken.
I’ve used that approach for decades as a hiring manager and never had to fire anyone subsequently for technical performance reasons.
My feeling is that anything you try to do in real time in the interview, as far as quizzes/coding goes, is not going to reflect reality so it’s flawed. If you ask someone to do a trivial at home project, you have no idea whether they did it themselves or copied it from somewhere, and if you’re asking for a non-trivial at-home project then you’re a) asking folks to do free work (even if it isn’t something you can use) and b) you’re imposing a heavier burden on the candidate than you’re willing to invest yourself in the process.4👍4➕
And, just to complicate things 🙂, I don't trust my fellow programmers, especially the young and eager, technically talented, competitive people, to give a good answer on what they would like to see as a process for interviewing them.1👍
An approach I've experienced recently: take home test, then talk through parts of it in the interview, then leave the candidate alone for 15 minutes to add an extra feature, specifying that it doesn't have to be complete/well-written/etc (presumably to make sure they can actually write code themselves)
(I do not love take home tests, or writing code under interview pressure; for a previous role I did appreciate a test where I was left alone during the interview time to do it, especially as it was done in a TDD but with tests pre-written style - getting the first few green calmed the nerves)
Sounds fine, but I wonder what purpose does that test serve and is this the best way to serve that purpose?1
I think maybe it’s that what some feel is 4-5 hours ends up being 8-10.
The thing is, I can count on one hand with a three or four missing fingers the number of times a candidate came in who wasn’t technically capable. One of those times, the candidate actually recognized it himself and ended the interview early. Also, every single time we’ve had to let someone go, it wasn’t for technical reasons. That’s not to say we don’t ask technical questions but, frankly, by the time a candidate is sitting down with us, (with that one exception, of course) we usually know whether they’re capable of doing the job and we want to know if we can work together. So how long is an interview you ask? An hour, plus or minus a few minutes. Of course there is usually a phone interview (this is all pre-COVID by the way) prior to that and possibly another follow-up interview of an hour or so. We want to respectful of their time as well and feel like asking for a long interview in the middle of their day requires they take time off from their current job which isn’t a good thing to do either.5👍
Of course, sometimes that is unavoidable. I interviewed with a company in a different state and they flew me out for the day so I didn’t have a problem taking time off or in having a several hours long interview process. Though, in that case, I still don’t believe the interview lasted longer than about 2-2.5 hours.
What an awful experience. I'm sorry to hear you were subjected to that. At least there isn't any ambiguity, you know that you don't want to work with them.
I don’t understand why anyone would have a time target like that in the first place. Wouldn’t a better goal be to come up with a take home exam that tests the candidate’s skills in the shortest amount of time possible? Just my 2 cents.
I still don’t believe the take home tests are useful. Like I said; in my entire career the people I’ve worked with have been overwhelmingly qualified and they never had to take a test--be it take-home or at the office. So what are these tests really telling you that you can’t get by other means?2👍
If I can be so frank as to border on offensive, I think this idea of testing stems from the fact that schools in the US (I can’t speak to how other countries do it) have increasingly had a singular focus on test performance. In my experience with my own children, that has nearly been to the exclusion of all else. Forget learning, just make sure they can pass the standardized tests! So now we have a workforce made up of a significant and growing segment of the population that think it’s all about the tests. It’s no wonder code testing has become so popular in recent years.