There were 7 interviews total, if you include the HR-related phone calls.

This included:

• 2 LeetCode-style tests
• An 8-hour take-home assignment
• A "system design interview," which was actually just a UI design interview, not a system design interview. I'm still not sure why they labeled it as such.

This took place over the course of about 2 months.

After all was completed, I got a phone call from the recruiter saying that I aced every single technical interview. However, they didn't hire me because I didn't know the "definition" of the "event loop" in Node.js.

It's true, I didn't know exactly what it was called in my interview with the hiring manager, and I could tell immediately he thought I was a moron. However:

A. You can literally Google what terms mean. B. The event loop, and my understanding of it, is a concept I leverage successfully on a daily basis at my job, and I successfully used it in the coding assignment THEY sent me, which they said was one of their best submissions.

So my advice to DataDog would be to make the interview with the elitist, gatekeeping hiring manager occur at the beginning of the process, instead of at the end. This way, misunderstandings like this can be avoided, and 2 months of my time won't be wasted.

The first LeetCode problem was the coin change problem. You can use a greedy algorithm to solve it since the denominations include a 1 dollar coin. If you solve it fast, they follow up with a very easy tree navigating problem.

The second LeetCode problem was related to RegEx, where they invented a regular expression to match strings, and you build an algorithm that performs the match. It's much easier than it sounds; just think it through.

The take-home assignment takes between 6-10 hours and involves building an application that displays statistics about your current and historical CPU load. They provide many good hints, so focus on making it pretty and flashy.

The "system design" interview is just a UI interview in disguise. They'll describe an application, and you just have to come up with what the UI looks like, and ask questions about tradeoffs and user requirements. Don't dive into system design details, because they will ask you to get back on task with the UI specifics.