Had the exact same experience. I actually got the role, but the feedback provided asked why I didn't build out something fully featured, despite them stressing to me the importance of doing it within 4 hours.

The worst part was that after working there I found them to be terribly unproductive and it would have likely taken a team there a week to build what they were suggesting...

But yeah as you said, either ignore the time constraints if you really want the role or just politely decline due to the red flag / inconsiderate nature.

It’s self reinforcing. Other people spent more than 4 hours on it and lied, so their expectation of what can be achieved in 4 hours is warped. It’s really just a way of selecting for liars, although that goes for most interview tactics.

well, obviously you failed their test but you were the best option they had.

I had a company ask me to put together a performance improvement plan involving proposed changes, instrumentation and engineering changes. They expected me to look at all their existing code, talk with engineering and other employees and put together this plan in 6-7 hours, an already ridiculously large time frame. I told them that allotted time was way too small for what they wanted and withdrew my application. It felt like they wanted me to put together a plan they could implement without paying or hiring me. Worse, I'd be working around their schedules to have these conversations so it wasn't really a take home assignment.

I wish I had saved a copy of the assignment. It was ridiculous.

So was the company the best in their field? I sometimes see small / badly managed companies pull such interview processes and it is ridiculous. You would expect they would hire 100x engineers with these tasks but I wonder what they are exactly looking for.

No. They were just starting out trying to sell their open source product. In fact, I had interviewed with a different company solving the same problem whose tech I thought was way more impressive.

My theory is that they’re looking for compliant, docile employees who won’t have the courage or the liberty to refuse unpaid overtime demands or complain about shitty stressful work conditions.

By having such an abuse and convoluted requirement for applying, you’re selecting for people in this situation. Then all you have to do is hire the best on the technical solution and you’ve got one more employee you can abuse in your company :)

Paid interview FOR THE WIN.

> ... as I wasn’t paid for the interview and I didn’t feel it was fair to me to spend any more time on it than that.

I have been paid for an interview, a coding interview where I fixed a bug and added a feature while my pair (future colleague!) chilled .. I think he surfed and I'd ask him clarifying questions occasionally? Anyhow, I got paid like $400. Best interview ever.

That's amazing. I got a $30 gift card for one interview. It wasn't much, but TBH in the interview gauntlet I've put myself through it was nice to get even the most basic recognition that my time is money.

Hey, that’s still a win. It sounds like they respected your time and knew that you’re a rare bird.

I'm in FE, and FE interviews can be like this so much. "Here's a takehome for something that in reality would take a week to complete but do it in an hour and don't spend more time on that!"

And I'm like.. an hour is not long enough to implement any reasonable webapp... I have no idea if other people went over or not, and it almost feels like a test of commitment (if I was serious I would take the actual 4 hours it would take and pretend I did it in 1 or something like that).

Yeah even a basic to do list or calculator web app can take several hours if it’s your first time with the specified framework, build tool or CSS library.

Given the diversity of FE it’s quite likely for a take home project to hit one of those criteria.

> ... if it’s your first time with the specified framework, build tool or CSS library.

Depending on the position they may been testing specifically to filter people out who are using a tool for the first time. If I'm hiring a Senior Flutter Developer then it better not be their first time using Flutter.

Unless we're talking about something truly enterprise (Magento at 4 million lines of PHP dependency injected MVVC hell comes to mind) or very obtuse (hiring ocaml devs to work on their compiler) senior means senior engineer, I don't care what you worked on to be honest. Senior perl engineers can flip to ruby in month and be totally proficient. A good Java programmer with 10 years experience will have plenty to bring to the table in C++ .

If you are a senior developer and haven't seen half a dozen frameworks, tool sets, or languages under your belt. What value are you in 2 years when we shift gears

I don't know about Flutter, but my issue with these takehomes in a React world is that React is extremely basic. It is only a view renderer, and leaves up to you all difficult questions of: routing, CSS, components, data fetching, state management, even things like how files are organized and named are up to you. As a React candidate, your takehome probably touches on all of these topics, and you (rightfully) probably want to express some kind of proficiency in most/all of these areas. The more senior you are, the more likely you have opinionated ways of doing these things. But in an hour long span, you are left with two uncomfortable options:

1. Write it all yourself. Express those opinions as clearly and bug free as you can. Try to get it all in as much as you can and give up on finishing all the features in the spec. Definitely give up on the UI looking nice -- despite what anyone says, default HTML is not pretty.

2. Use OSS libraries. Are you actively up to date on OSS libraries handling these things? If you're a working React professional, you probably are not, because you're using whatever system your company uses. Do those OSS libraries properly express what you think is good code? And what does it say about you to use those OSS libraries? Do you look like someone who actually understands React and understands those tradeoffs, or do you look like the kind of person that creates the type of React app that HN is always complaining about, one with a billion dependencies?

Sorry if I sound ranty. It's not directed at you. I've just been dealing with a lot of these this week.

the worst part about it is that when they give a time limit they make it sound like they're doing you a favor.

"we have a takehome, but don't worry! it's just a quick little thing that should just take an hour to throw together. we're not like those other companies that give you a huge task"

Exactly. Then I've been wondering, how many people are actually going over the time? Are the reviewers actually checking any time stamps?

What can they realistically check?

I see two data points they could have: time when the template was downloaded (assuming it’s a unique link only you can access, and you didn’t download it > once/all downloads are logged) or emailed, and the time it was submitted.

All other time stamps can be spoofed.

No, I agree. I just mean like when they say, hey this will take 2 hours, how do they know? Do they even care? Or just everyone cheats and does more than the allotted time?

I did one take home that was timed in coderpad. I thought that was a little more fair.

They have no idea how long they take. They come up with a task first and then slap a time limit on it afterwards so they don’t feel bad about asking too much.

This is explicitly what bootcamp graduates are asked to do. It’s possible, they were just filtering out candidates that can’t work that fast.

Yes, I had a very similar experience.

Honestly 2h from scratch is a rush to do anything? However simple it is, you're asking for an 'entire' greenfield project, of course I have skipped things and missed corner cases.

Especially when bootstrapping takes the most time on projects. 2 hours to code up a game of War, ok. 2 hours to spin up a useful laravel site? Ehhh

I once had a recruiter send me the project template in a .zip for the take home with the instructions to take less than 3 hours (the email wasn't timed to start right away either). No server with countdown, no forking from github, just download this zip and then email back in less than 3 hours. I thought to myself: will they check the download time from the share drive (if they even can)? will they just pass me by default for starting one day after the email delivery? Open up the zip. You need to add 6 endpoints, 2 of those are some fairly complex aggregate queries and I had to take a quick refresher on the legacy ORM they were using. For the frontend, bootstrap a react app from scratch and implement 6 flows (some even required you to go beyond the api tasks). They even encourage going above and beyond and adding unit testing and some integration tests for the UI! So then it was obvious the metagame was cheating and you'd be compared against people cheating. Are people sending edited git history? doing it in groups? what was the catch?

I obviously noped out, but am still wondering if they are aware that all the people working there 100% cheated on their take homes.

I always do exactly one commit with a commit time of exactly when they sent me the take home. If I actually had to fork something I would create the Github account specifically for just that take home and fork it right before pushing. Creation and modification date of files are the same.

Either they don't care or they see it and figure I must be some sort of whiz. I say that because the amount of people that don't know how git works or that file attributes are arbitrarily changeable is amazing.

And no not specifically to "cheat". Just on principle. If they require BS I give them BS. Else it's just fun. Sometimes the people actually hiring/doing the interview are also not the ones that care for this but HR/senior leadership only.

  always do exactly one commit with a commit time of exactly when they sent me the take home

  If they require BS I give them BS

So, that's editing git history to fit a narrative. I'm not judging though! I guess it really depends how bad you want the job after all. But personally I wouldn't even agree to a process like this that ensures cheating is the only way to be competitive. No company that does this is paying nearly enough to make up for the possible reputational damage, and not counting the hazzle.

What do you mean editing? I only commit at the end. I happen to set the date and time explicitly :) For all anyone knows my timezone was still off from traveling when I committed.

And yes, lots of companies have an interview process that states these things. The process makers are not the same people as are interviewing/going to be your team. I know from the other side where I have in the past internally had to advocate for proper take home practices. They really wanted to extend the take home and to say "should take 4-8 hours" (meaning really it's 2 days of work) . I told them that's BS and I wouldn't be with them right now if that was the practice back when I interviewed.

The worst thing that can happen is that they think you are cheating and they never even call you back. Bullet dodged. The best thing that can happen is that they do call you in for an interview and the interviewer tells you that you're so far the best sport and apparently know your git very well and you bond over it.

> I always do exactly one commit with a commit time of exactly when they sent me the take home.

Amazing I'm mixed on companies looking at start and end times. I think it would be ridiculous for them to actually check, but at the same time I'm curious how many people are going way over the time limit. I wonder if I should go over the time limit or not.

> And no not specifically to "cheat". Just on principle. If they require BS I give them BS. Else it's just fun.

Maybe this is controversial to say, but in reality, we're all "cheating" because we have to.

they can definitely enforce a strict time limit by only showing the exercise on a website that starts a countdown and telling you so. I'm okay with that. What I'm not okay with is being ambiguous about this and expecting me to game-theorize the risk-reward ratio of competing with people cheating.

I would rather feel the metagame is that you are being free labor for an actual problem/task they are having in the company.

Was this us (Fly.io)? I'm not sure how many companies give the 2 hour guideline, but we definitely do.

We don't fail take homes because of edge cases though. There are things we expect people to handle in the challenges that are important, but I don't think more/less time really influences those.

Please don’t tell me that the compensation ranges I’m seeing for fly.io are accurate - between $130k - $170K.

Those are standard enterprise CRUD salaries. I’m not trying to be demeaning. Those are the kinds of jobs I had most of my career until 2020. But they are a dime a dozen and I definitely wouldn’t do a take home test for one.

Most of our jobs are ~$120-215k base salary. The equity compensation is typically 3-4x that.

I value “equity” in a private company at $0.

Yeah you should not work here. That's a completely reasonable stance.

From the data that I could find, it's perhaps at best 10% of all tech companies that even go public (and very possibly as few as 1%). It's far more reasonable to assume a company is the 90% or 99% of companies that do not go public rather than anything else.

My experiences are the same that equity in private companies is not significant. Worse yet, in all of my experiences the private equity I could have bought or did buy were all 100% losses.

[1] https://www.quora.com/What-percentage-of-Tech-startups-eithe...

On a different topic, I think your response mrkurt is a violation of the commentary guidelines:

- "Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."

- "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

He was responding to me and that’s a very reasonable response. When I was in the market for your standard enterprise CRUD Enterprise dev jobs, I would have taken a cash compensation of $150K - $160K and zeroed out the equity.

What I wouldn’t do is jump through any hoops like a take home test when jobs in that pay range are (were? I don’t know what the current market is like) a dime a dozen and I could just do one phone screen and a soft skills interview for half a day and get a job making that much.

Oh, I guess that could sound snarky. I wasn't feeling snarky, though. We are the wrong place for a lot of people to work.

I've been job searching for the past few months. Advertised salary ranges seem to skew lower than 6 months ago.

Don’t get me wrong. I’m not so deep in the tech bubble that I don’t realize that $120K-$170K is the the standard range that most of the 2.7 million developers in the US make. I was one of them for decades until 2020.

But at least from around 2002- 2008 and 2012-2022, if you have experience in a mainstream stack, and you live in a major metropolitan area in the US you could easily get a job that pays in that range without even coding interview, let alone a take home test.

Same happened with me. Funny enough the other candidates solutions were shared on GitHub. Two funny aspects:

1. Other candidates were clearly spending 8-9 hours on the problem. I saw their commit logs. A commit every 1-2 hours for 9 hours. Several candidates public repos were like this. The assignment was like 2 pages of requirements supposed to be done in I believe 1 hour.

2. They told me (thru the recruiting firm; I never spoke with them) that it would have been resourceful to use the other candidates solutions.

"resourceful"... Wow I'm impressed by the level of bullshittery. I wouldn't want to work as an engineer in a place where honesty and following the rules is a detriment

"works well with others ... code"

In the past when I’ve given take homes (I don’t anymore) I genuinely would have wanted you to stop after the time limit. It would definitely mean that you weren’t the right candidate if you can’t do it in the time limit, which is OK! It’s meant to signal that it’s a bad fit. I wouldn’t want you feeling like you have to work after hours in the actual job, either.

> At this point in my career, I’ll just decline interviews that don’t respect my time.

This is my philosophy now. In my younger days when I had no experience I had a lot of my time wasted by recruiters and companies - never again. Now I ask up front and politely what the interview process will be like. If there are any home projects or mentions of whiteboarding I end up passing. No big deal - I know there are probably loads of developers willing to waste their time competing for the position, but not me.

It's worked very well for me and eliminated a lot of stress when I've been looking for other positions. The only negative I can see is the strategy wouldn't work great when in between positions and really needing something, which luckily I've never had to experience. I suppose in that case I would force myself to go through with the hazing process.