I think most 2-4 hour take-homes can be condensed to 1-2 hours with some thoughtful choices. A few ideas I've used:

- Provide starter code and setup instructions so candidates don't waste time on boilerplate.

- Abbreviate requirements to what actually matters. E.g. do you really need 100% test coverage on a take-home? Ask candidates to write a few tests and then tell you what else they'd do given more time.

- Use an open-ended, time-boxed format instead of having end-to-end expectations. IMO a hybrid format where a short (1 hr) take-home is followed by a live discussion/pairing afterward can be the core component of a hiring process.

I'd love to hear more about the Ramp process. Do you mind sharing what sort of practical problems they used?

I interviewed for a backend role and the problems were greatly simplified versions of day-to-day backend SWE work. For example, use a server to complete a task. The focus was on how you make the requests and handle any edge cases that might come up, and the server was actually live so you could tinker and get immediate feedback. Hopefully that’s not too vague :)

Edit: to be clear, the interview was live with an interviewer. So it wasn’t a take home in the scheduling sense either.

I agree that take homes can be simplified with your suggestions above, and that certainly makes a better experience for the candidate. The hybrid format is also great - future interviews become an extension of your previous work, so it’s more comfortable than having to context switch for a new challenging problem each round.

I didn’t find this in your linked database, but I also enjoyed GitHub’s take home. I only recall spending 45-90 minutes on it, and the setup process was seamless. A recent blog post describes their approach here: https://github.blog/2022-03-31-how-github-does-take-home-tec...

Yes! I spoke to Andy (the author of the article you linked) when he posted this. I'm a big fan of this approach. And the software we're building is quite similar to the interview-bot one that GitHub uses internally. Why shouldn't every eng team be able to benefit from tools like theirs?

I'd love to add GitHub's take-home to the library, but I feel the article describes the exercise without sharing the actual prompt. If there's a public link to it, lmk and I'll add it.

You’re right, I don’t think their exercise is public. I just wasn’t sure if you knew about it and felt it was good enough to call out.

This is awesome to hear! I did check out your website but wasn’t sure how closely it tracked with the GitHub method.

Honestly, I had a thought to build something like this after my GitHub interview but wasn’t sure how much traction it would get. It’s cool that you’re working on it and that my random thought was validated; best of luck!

> Even 2-4 hours is more time than conventional Leetcode-style initial assessments,

Hard disagree on this one. Unless your day-to-day work includes many leetcode style problems, you need to put in significant time training on leetcode if you want to pass the interview.

You should be able to complete a take-home based on your current skill set. Yes, it may take 4-6 hours (or 8-10), and yes, that is a big ask of a candidate, but leetcode can take 5 to 10x prep time and you still can muff the interview.

Is there literally any other field where there's an expectation to essentially do fairly intense studying to pass interviews that apparently have very little to do with day to day jobs? Maybe they exist I've never encountered them. The limit of my "studying" for an interview is to just learn a bit about the company, their strategy, etc. either by online research or by talking to people I know connected with them.

ADDED: I suppose one could argue that the Bar exam is a bit like that but that's a credential as are degrees which are not necessarily all that overlapping with the real world.

> ADDED: I suppose one could argue that the Bar exam is a bit like that but that's a credential as are degrees which are not necessarily all that overlapping with the real world.

Yeah, I think most other professions where one might imagine them doing something like a stereotypical software interview, use that instead: a credential obtained by a (perhaps very difficult!) test, maybe with periodic re-tests or required refresher courses to keep the credential valid.

I have a suspicion that a big part of why top-comp software companies keep their interviews so incredibly unpleasant has more to do with discouraging job-hopping among them (so, suppressing wages) than with its being the best process for hiring good developers.

> I have a suspicion that a big part of why top-comp software companies keep their interviews so incredibly unpleasant has more to do with discouraging job-hopping among them (so, suppressing wages) than with its being the best process for hiring good developers.

You have to wonder if this has backfired. ;) Plenty of people job-hop every 1-2 years, and it's pretty common knowledge which companies ask which level of LC difficulty for which level.

It's probably pretty common within a certain cluster. A bunch of other people probably see the barriers and just pass. Or my experience is that others just find grass is distinctly not greener and move on.

Is there literally any other field where there's an expectation that you will work for free 4 hours in order to be considered for the job?

Tons of them. How much time do you think the typical actor or dancer spends auditioning and preparing for the audition? How much time do you think people in many creative fields spend putting together portfolios? And if I'm going to interview with just about anyone, I'm going to spend at least 4 hours prepping for an interview.

I'm not a big fan of take homes in general but a time-consuming job search and interviews is absolutely normal beyond low-skill jobs in a time of labor shortages.

I hard disagree with your disagree :)

1. Some candidates only need to brush up to be in interview shape.

2. To mitigate the need to spend time to prepare, simply use initial assessments to get back in shape. That is, apply to and interview at companies you don’t want to work at first to get more practice problems. If you pass, you get the added benefit of more leverage when negotiating your compensation!

3. As another commenter mentioned, as Leetcode style interviews are shorter, there should be a threshold where $prep_time + $leetcode_interview_time <= $take_home_interview_time. Of course, the threshold adjusts up and down based on your initial level of preparedness.

> That is, apply to and interview at companies you don’t want to work at first to get more practice problems.

If you have enormous amounts of time to waste you might as well do a take-home.

I honestly hate spending 4-6 hours of my time on a pointless take-home, but I suck at leetcode and I absolutely refuse to spend any time on learning it, so they’re the lesser of two evils.

The difference is that you are spending 4-10 hours of your time trying to pass the process for 1 company. If you instead invest 4-10 hours doing leetcode prep, you are studying to pass the process for LOTS of companies. Economies of scale is a huge factor here

Is your 4-6 hour estimate a total of all jobs a candidate applies for?

If you are interviewing for 10-20 jobs in a particular week, a 2-4 hour take home test is a full time job 40 hours worth of work.

I would accept a 2-4 hour time commitment but only much later in the interview process, when much of the interviewing was done and the list was whittled down to 2-3 serious companies.

Seriously, if a company wants me to spend more than an hour of my time on something for them, they better be including a check as well.

Less competition for everybody else looking at the position, then.

The test might be longer, but I don’t have to spend time studying and practicing something I’ll never use on the job. I use the same knowledge I build up while working