As I mentioned in another comment on this thread, one of the biggest issues is framing programming as a low-status, commodity activity.

I doubt Digital Ocean does this since they want good people, but a lot of firms absolutely design their hiring process to create an upper hand and lower your status before you even walk in the door -- especially if you're an experienced engineer.

Short timed tests or whiteboard hazing are the worst version of this. These are the most blatant attempts to commoditize software labor down into a fixed set of "primitives" like data structure trivia or riddles. This is what organizations like HackerRank exist to do: allow big companies to suppress wages by creating these sorts of commodization filters. They don't attempt to capture the value of creative problem solving at all -- because the company is not pricing the value of creative problem solving into the budget for the position, since it's a rank-and-file commodity job.

For this reason alone, you are better off flat out rejecting anything like a HackerRank test or similar online, interactive, short timed test. I would absolutely go so far as to even refuse to write code on a whiteboard if asked to do so in an in-person interview. It's fine to talk about how to solve a problem and spec things out. But the minute it becomes focused on actual fucking syntax, it's game over. You are now a cog.

Longer-form tests are a lot harder to evaluate from the candidate's point of view. Now you are asking for a significant chunk of my time, without paying me. And I am still at the mercy of whatever you happen to think constitutes a valid test. I might look at your take home test and thing, "wtf? this has nothing to do with real world work." Where does that leave me? Of course I want to impress the hiring staff, but I also don't want to get roped into a bad job, and a team that hires me to do real world work by using contrived coding examples is probably not a good place to be.

Personally, I think it's a lot more useful to talk about code that already exists. Either example code form the candidate, or example code that you give to them along with some time to study it.

Engineers read code more than they write code anyway, and right when you hire someone, even if you're a bleeding edge start-up, their short-term impact is a lot more predicated on their ability to read code and quickly learn a new system, not so much writing a bunch of stuff from scratch.

It's also pretty hard to fake competency when reading and discussing actual code. If you don't know how something works, you just don't know. You probably can't just google how the internals of some highly-specific ad hoc code works, unlike data structure trivia (which is yet another reason why it just doesn't matter how much data structure trivia you have memorized).

Basically, my overall conclusion is that when someone asks you to code in a short, timed setting, they are basically lighting a cigar, fingering their handlebar moustache, kicking their feet up on the table, and saying "dance monkey dance."

Unless you are literally desperate for the job, you should reject it right away. You are being positioned so that no matter how well you do on the test, you are but a lowly code typist and they will not take your attempts at negotiation seriously.