They say you have an hour to do each coding session which is absolutely not true. They give themselves an introduction, and at the end they cut it short by 10 minutes so you can ask them anything. So really only about 40-45ish minutes in total coding time. I did finish these well within the allotted time, but it's actually so stressful that I rushed parts. You're kind of fighting the clock, but also needing to balance making good design decisions, whilst also communicating the whole time. They will consistently interject the whole time, making you feel like you need to also justify certain decisions made. That would be fine, BUT then why give this restricted time? No product company in the real world would give you 40 minutes to do a POC for these tasks (perhaps the more simpler feature flag task), all the while someone there prompting and asking why and interjecting at every step. The industry has moved away from these types of interview processes, many more experienced engineers than myself are getting better job offers elsewhere without having to do these types of tests. Maybe they feel justified in doing these at their scale because they really want to get the cream of the crop? I just would argue they are excluding many talented engineers in the process Incoming slight rant: This process really did irk me, mainly because the interviewer specifically told me the recursive task was "in-depth" that they didn't expect me to get it done in the allotted time, but I did it with time to spare (it functioned perfectly to their written specifications might I add), and that seemingly didn't appear to count for anything, instead I was marked down for not having semantic HTML (honestly fair enough) and a few other things. Fair enough, but honestly given that it is 40 minutes, how is the engineer supposed to determine which specific corners they want cut? You want me to have perfect semantic HTML at the cost of an incomplete task? Just how incomplete should have I made this in favour of your standards? I say "your standards" because as I started the task, I started safely typing the data my component would receive and he cut me off immediately saying "we don't have time for typing"... Okay so you don't have time for Type Safety, but YOU DO for semantic html? In the real world you need to make time for BOTH, but at this stage you're the one setting arbitrary standards of what is more important and not by telling me to hurry up and skip actually designing a safer component... I guess this can work as a test, but at the very least, they should be explicitly clear on what you DON'T want us to spend time on in the very beginning of the brief. Just say "don't worry about typing, don't worry about error handling for xyz, don't worry about styling" etc if you don't want to see how we handle these things in favour of other things (but again, you should be interested in the WHOLE picture). I'm not so neurotypical, so you telling me "we don't expect you'd be able to finish this within the allotted time" isn't so straight forward for me, it's hard to tell if that could mean reward me for going "exceeding expectations" if I did finish it in the allotted time or not. Just some actual clear guidelines for something as abstract as "do a task, but we are giving you an impractical window of time that no company on earth would give you" would be nice :)