Do any companies not do coding challenges?

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.

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.

> 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 was on both sides at RedHat. It differed team by team. My last interview was just a discussion about past experiences :)

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.

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.

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.

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).

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.

Personal references / intros will minimize BS coding tests and challenges.