Ask HN: Do any companies not do coding challenges?
28 comments
I'm in a company that didn't. Basically we have an aggressive schedule and not enough candidates, because nobody wants to join a startup. A few bad eggs slip through the filter, but probation contracts make them easy to root out. I'm not sure why more companies don't just adopt a 'hire fast, fire fast' system.
Lots of programmers in the industry are already good enough anyway. I've seen programmers who can't reverse a linked list who can still output decent code. Similarly you have some extremely technically skilled ones who can't build a feature in reasonable time.
Lots of programmers in the industry are already good enough anyway. I've seen programmers who can't reverse a linked list who can still output decent code. Similarly you have some extremely technically skilled ones who can't build a feature in reasonable time.
> I'm not sure why more companies don't just adopt a 'hire fast, fire fast' system.
Because it will vastly limit the number of skilled developers you can attract.
Let's consider two scenarios. In the first, a developer performs a coding challenge. The company is fairly sure that the developer is qualified to work there, and the developer is fairly sure she has the talent to stay employed there.
In the second, a developer is hired for non-technical reasons, and she quits her current job knowing that if things don't work out, she'll be looking for another job in six weeks.
Fuck that. Job hunting is stressful, and there is no way I would join a company if I didn't think I would be there for at least a year. I wouldn't even send my resume to a company with a reputation for that kind of fast turnover.
Because it will vastly limit the number of skilled developers you can attract.
Let's consider two scenarios. In the first, a developer performs a coding challenge. The company is fairly sure that the developer is qualified to work there, and the developer is fairly sure she has the talent to stay employed there.
In the second, a developer is hired for non-technical reasons, and she quits her current job knowing that if things don't work out, she'll be looking for another job in six weeks.
Fuck that. Job hunting is stressful, and there is no way I would join a company if I didn't think I would be there for at least a year. I wouldn't even send my resume to a company with a reputation for that kind of fast turnover.
Hire fast doesn't mean no coding interviews. There can probably be 1-2 coding challenges, but the whole process shouldn't take more than a few hours total. They should be just hard enough for an experienced dev to pass without having to study, but it should filter out the people who spend all their time studying and yet can't build things. What happened to the days we were happy with FizzBuzz as a filter?
I just think there's a lot of waste going from 90% confidence to 95% confidence.
I just think there's a lot of waste going from 90% confidence to 95% confidence.
Lots of companies do this, but no one calls it "hire fast, fire fast." It's called "contract-to-hire." If you're talking about enforcing a bell curve on your existing employees, then that's called stack ranking and it's a despised and discredited practice.
"Hire fast, fire fast" is something I used to think was a good idea but it relies on management having the balls to fire, in the case I saw they never did grow the balls and the competence of the team cratered as incompetence became the new team culture
I wonder if there could be a sort of “hard” probation zone. You get to work cranking out low priority bugs for a mmmm Chung few days, but no real interaction or maybe even like a 14 day contract. Seems like something culturally you could create, though the social implications might be quite rough.
Many don't. You can always just refuse and move on.
I've wasted a lot of weeks on these things. They are a major risk for the applicant because the slow the job search down considerably. The large time investment makes the application process prohibitive for people already working full-time, which is bad for the hiring team because employed people looking for a change are often the most competent candidates.
I would never agree to a coding challenge anymore without some assurance I'm on the short list of candidates. i.e. Ask to schedule a code review meeting with the hiring team, or insist on a traditional interview before you do the challenge. If that's a problem for them, then you can be sure that they aren't going to hire you no matter what you submit.
I've wasted a lot of weeks on these things. They are a major risk for the applicant because the slow the job search down considerably. The large time investment makes the application process prohibitive for people already working full-time, which is bad for the hiring team because employed people looking for a change are often the most competent candidates.
I would never agree to a coding challenge anymore without some assurance I'm on the short list of candidates. i.e. Ask to schedule a code review meeting with the hiring team, or insist on a traditional interview before you do the challenge. If that's a problem for them, then you can be sure that they aren't going to hire you no matter what you submit.
> Coding challenges are a useless metric IMO. They also waste time.
I agree to some extent, here are some that don't do these interviews [0]. But unfortunately, I find that all tech companies and strangely non-tech companies are trying to normalize the coding interview tests. Pre-interview challenges are useless, since a candidate can easily cheat them by searching-copypaste-refactor the optimal solution from another computer into their own editor and submit it as their own. Doing this easily fools many assessment tools all the time, despite their 'machine learning detection' claims.
But nowadays, it is the on-site interviews which is the new normal. But depending on the sort of company you are applying to, I would ask questions on where they actually apply them or use them in their so called 'engineering challenges'. FAANG, large banks and several fintech companies is certainly justified. 10-15 employee startups based on a mobile app? Hardly. I would expect that larger companies that have their own technologies, programming languages or libraries will ask these coding challenges and if an interviewer cannot justify the use of these questions other than 'to see how you program' then I just end the interview gracefully.
I would instead ask the candidate to send a link to some relevant open-source projects or significant contributions that meet the technologies I am using. No silly hello-world/git-flow/test projects. I can easily eliminate 90% of candidates by checking that you have a patch and are mentioned in the AUTHORS file of an open-source project, which is more quicker than these programming tests designed to hopelessly find 𝔶𝔢 𝔞𝔫𝔠𝔦𝔢𝔫𝔱 𝔩𝔢𝔤𝔢𝔫𝔡 𝔬𝔣 𝔶𝔢 յօ𝔵 𝔡𝔢𝔳𝔢𝔩𝔬𝔭𝔢𝔯.
[0] - https://github.com/poteto/hiring-without-whiteboards
I agree to some extent, here are some that don't do these interviews [0]. But unfortunately, I find that all tech companies and strangely non-tech companies are trying to normalize the coding interview tests. Pre-interview challenges are useless, since a candidate can easily cheat them by searching-copypaste-refactor the optimal solution from another computer into their own editor and submit it as their own. Doing this easily fools many assessment tools all the time, despite their 'machine learning detection' claims.
But nowadays, it is the on-site interviews which is the new normal. But depending on the sort of company you are applying to, I would ask questions on where they actually apply them or use them in their so called 'engineering challenges'. FAANG, large banks and several fintech companies is certainly justified. 10-15 employee startups based on a mobile app? Hardly. I would expect that larger companies that have their own technologies, programming languages or libraries will ask these coding challenges and if an interviewer cannot justify the use of these questions other than 'to see how you program' then I just end the interview gracefully.
I would instead ask the candidate to send a link to some relevant open-source projects or significant contributions that meet the technologies I am using. No silly hello-world/git-flow/test projects. I can easily eliminate 90% of candidates by checking that you have a patch and are mentioned in the AUTHORS file of an open-source project, which is more quicker than these programming tests designed to hopelessly find 𝔶𝔢 𝔞𝔫𝔠𝔦𝔢𝔫𝔱 𝔩𝔢𝔤𝔢𝔫𝔡 𝔬𝔣 𝔶𝔢 յօ𝔵 𝔡𝔢𝔳𝔢𝔩𝔬𝔭𝔢𝔯.
[0] - https://github.com/poteto/hiring-without-whiteboards
What's wrong with 'to see how you program', though? Why is FAANG, large banks, and several fintech companies are justified to use coding challenge and on-site interview, but not 10-15 employees startups> Considering those 10-15 employees startups need good programmers who can act as cofounders while mature companies already have mature filtering mechanism for recently people joining.
Also, about the open-source projects, not all candidate do open-source projects. Most of them write proprietary codes all day and don't have a chance to contribute to open-source projects. (Disclaimer: I'm one of those unfortunate people, as much as I want to contribute)
Also, about the open-source projects, not all candidate do open-source projects. Most of them write proprietary codes all day and don't have a chance to contribute to open-source projects. (Disclaimer: I'm one of those unfortunate people, as much as I want to contribute)
> What's wrong with 'to see how you program', though?
* Dear dentist, can you please show me how you fill cavities?
* Dear lawyer, can you please show me how you law?
* Dear surgeon, can you please show me how you operate?
* Dear accountant, can you please show me how you do taxes?
* Dear architect, can you please show me how you design?
* Dear dentist, can you please show me how you fill cavities?
* Dear lawyer, can you please show me how you law?
* Dear surgeon, can you please show me how you operate?
* Dear accountant, can you please show me how you do taxes?
* Dear architect, can you please show me how you design?
Dentists, lawyers, surgeons and accountants have professional bodies issuing licenses or certifications. Those licenses verify that the candidate in question has at least met some arbitrary skill level in their respective field.
The software industry, for better or worse, have collectively rejected having such a professional body, which means companies looking for software engineers wind up having to evaluate programming skills individually.
The software industry, for better or worse, have collectively rejected having such a professional body, which means companies looking for software engineers wind up having to evaluate programming skills individually.
I think the more important factor is those professions consider themselves high status and wouldn’t put up with incompetent-until-proven-otherwise interviews.
Programmers as a group don’t stand up for themselves.
Programmers as a group don’t stand up for themselves.
* Dear writer, can you please show me some writing samples?
* Dear graphic designer, can you please show me your portfolio?
* Dear welder, can you please weld these test coupons?
* Dear actor, can you please audition for the role?
There are plenty of professions where a demonstration of relevant work ability is a normal part of the hiring process.
The problem with many "coding challenges" is that they take a long time to do - basically, are unpaid paid work. Writing samples and artist portfolios are compiled from work the candidate has already done; the closest we have in software is "looking at someone's GitHub" which has its own set of problems. Welding tests and actor's auditions are distinct because they don't take that much of the candidate's time, and quickly demonstrate if they are suitable for the role or not.
* Dear graphic designer, can you please show me your portfolio?
* Dear welder, can you please weld these test coupons?
* Dear actor, can you please audition for the role?
There are plenty of professions where a demonstration of relevant work ability is a normal part of the hiring process.
The problem with many "coding challenges" is that they take a long time to do - basically, are unpaid paid work. Writing samples and artist portfolios are compiled from work the candidate has already done; the closest we have in software is "looking at someone's GitHub" which has its own set of problems. Welding tests and actor's auditions are distinct because they don't take that much of the candidate's time, and quickly demonstrate if they are suitable for the role or not.
What's wrong with those?
I was on both sides at RedHat. It differed team by team. My last interview was just a discussion about past experiences :)
Those have been some of the best interviews in my experience. I've also never been disappointed by the leadership or management of my soon-to-be boss when they demonstrated in an interview that they had the emotional intelligence to make a hiring call based on a mature discussion (like oh, I don't know, almost every other industry) rather than demanding a few hours of monkey tricks in Leetcode to convince them.
Look at any engineering company that isn't primarily a software engineering company. They still have lots of really cool software problems that need solving, but tend to have a lot more sane working conditions. Just don't expect to get paid top end silicon valley salaries.
I interviewed at a small place that gave me a take home project, pretty small and flexible in nature.
They then asked me enough about it for me to show it was my work.
No whiteboard challenges or anything.
I very much preferred that as I'm not good at on the spot abstract coding challenges.
They then asked me enough about it for me to show it was my work.
No whiteboard challenges or anything.
I very much preferred that as I'm not good at on the spot abstract coding challenges.
In my experience they nearly all require them. I've also encountered a couple cases where they said they didn't, and then someone gave me a coding challenge anyway.
I've always been bad at these, which is super frustrating for me, but it's the way it goes. I gave up trying to fight it and instead started making notes of which problems I did poorly at, and started practicing those. Going through the cracking the coding-type problems helps too.
I've always been bad at these, which is super frustrating for me, but it's the way it goes. I gave up trying to fight it and instead started making notes of which problems I did poorly at, and started practicing those. Going through the cracking the coding-type problems helps too.
In my country it is not that common. Usually the companies that ask you to do them have a culture of well... nothing good. Even if I pass the test sometimes that just sets high expectations which I might not be able to meet (at least not in the first month of probation).
Don't get me wrong, I am not against such challenges, as they could be useful. It's just that my experiences with companies that do these have been bad.
Don't get me wrong, I am not against such challenges, as they could be useful. It's just that my experiences with companies that do these have been bad.
Anyone have actual recs for companies?
Even startups now seem to rely on coding challenges that have no relevance to roles they're recruiting for. Or even worse, they'll trim down a take home and just use that as a "real world" coding challenge (while watching you do it and expect perfection in 30 minutes or less).
Even startups now seem to rely on coding challenges that have no relevance to roles they're recruiting for. Or even worse, they'll trim down a take home and just use that as a "real world" coding challenge (while watching you do it and expect perfection in 30 minutes or less).
It slows down job opportunities. A person should not be solely hired on their programming capacities in regards to a challenge, especially if topics that come by in these challenges have nothing to do with the company's vision.
TLDR:
I don't use coding exercises in any capacity to hire junior developers onto my remote team of freelancers.
--
When I hire Clojure juniors, I have a set of questions that I've put in the job posting that they will have answered prior to me speaking with them.
I still speak to the person if they completely ignore the request to answer the questions.
There are probably 20-30 questions, some are objective, others are subjective, and a lot of questions are meant to evoke somewhat passionate answers, or at the very least, allow someone to display their passion.
Some have to do with qualities I would expect a certain type of clojure developer to posses.
Others have to do with the shape of our system, such as specific questions about tools in our stack.
The last variety are questions to gauge where on the spectrum of learning someone is at in regards to specific software development topics and practices.
I never disqualify candidates who don't have much experience with our stack, all I need to see (in their github repo) is that they write Clojure competently, and I need to understand from speaking with them and reading their questions, that they are a competent and interested individual.
I give most people I speak with a fair shot with the intention of improving my team's on-boarding process, which hopefully improves with every successful new hire, in other words, they bring the core competency required to participate in our environment and we fill in the gaps with respect to our architecture, methodology, and our stack.
I don't use coding exercises in any capacity to hire junior developers onto my remote team of freelancers.
--
When I hire Clojure juniors, I have a set of questions that I've put in the job posting that they will have answered prior to me speaking with them.
I still speak to the person if they completely ignore the request to answer the questions.
There are probably 20-30 questions, some are objective, others are subjective, and a lot of questions are meant to evoke somewhat passionate answers, or at the very least, allow someone to display their passion.
Some have to do with qualities I would expect a certain type of clojure developer to posses.
Others have to do with the shape of our system, such as specific questions about tools in our stack.
The last variety are questions to gauge where on the spectrum of learning someone is at in regards to specific software development topics and practices.
I never disqualify candidates who don't have much experience with our stack, all I need to see (in their github repo) is that they write Clojure competently, and I need to understand from speaking with them and reading their questions, that they are a competent and interested individual.
I give most people I speak with a fair shot with the intention of improving my team's on-boarding process, which hopefully improves with every successful new hire, in other words, they bring the core competency required to participate in our environment and we fill in the gaps with respect to our architecture, methodology, and our stack.
Curious how'd you define "junior"?
As someone with about a year and change of experience out of college and 1.5 yrs of professional "co-ops" during college - I still consider myself very junior but feel at a disadvantage to NCG's. Especially since my team at a FAANG was flushed giving me a weird work history :/
As someone with about a year and change of experience out of college and 1.5 yrs of professional "co-ops" during college - I still consider myself very junior but feel at a disadvantage to NCG's. Especially since my team at a FAANG was flushed giving me a weird work history :/
It sounds like our worlds are different, I don't work for a FAANG, but in my world:
A junior is someone who has put time and effort into learning our programming language, but may not have previous industry experience with it. After speaking with them, I'm either convinced or not that given a reasonable burn in time they can become an independent and productive member of the team. I like to see a work history with other stacks of course.
There's really no concrete basis on which to judge what anyone is truly capable of, especially in our industry, sometimes it comes down to giving someone a fair chance and hitting the eject button if it isn't working out.
As a remote independent person who hires other remote independent people, on a contractual basis, I think I'm allowed to take more humanitarian liberties when I have hiring decisions to make, due to the structure of remote work and the qualities that independent people tend to have.
Hope that helps.
A junior is someone who has put time and effort into learning our programming language, but may not have previous industry experience with it. After speaking with them, I'm either convinced or not that given a reasonable burn in time they can become an independent and productive member of the team. I like to see a work history with other stacks of course.
There's really no concrete basis on which to judge what anyone is truly capable of, especially in our industry, sometimes it comes down to giving someone a fair chance and hitting the eject button if it isn't working out.
As a remote independent person who hires other remote independent people, on a contractual basis, I think I'm allowed to take more humanitarian liberties when I have hiring decisions to make, due to the structure of remote work and the qualities that independent people tend to have.
Hope that helps.
This definitely helps!
I think my biggest blind-spots have to do with system design / tooling. At least in terms of grappling with what changes are / are not reasonable (basically knowing what tasks to stretch myself on - but somehow gauging when I think the scope of a task is wonky and avoiding those to not screw myself)
Do you have any tips for finding companies that might be as open to "moderate juniors" like you've described?
I think my biggest blind-spots have to do with system design / tooling. At least in terms of grappling with what changes are / are not reasonable (basically knowing what tasks to stretch myself on - but somehow gauging when I think the scope of a task is wonky and avoiding those to not screw myself)
Do you have any tips for finding companies that might be as open to "moderate juniors" like you've described?
Search for easy wins, shun refactoring, and always try to build the next thing better, rather than going backwards to retroactively "fix" working (but perhaps less than ideal) things.
I can't really advise on finding companies. I haven't had to search for one myself in a while. Like I said, I'm a freelancer, so I just go with the flow until I can find a new opportunity.
Good luck, believe in yourself more and don't worry so much about categorizing yourself!
I can't really advise on finding companies. I haven't had to search for one myself in a while. Like I said, I'm a freelancer, so I just go with the flow until I can find a new opportunity.
Good luck, believe in yourself more and don't worry so much about categorizing yourself!
Personal references / intros will minimize BS coding tests and challenges.
Any companies out there that bypass all this nonsense?