This is great! Having an integrated environment with the tests included and solutions in a separate notebook is quite valuable for training to pass technical interviews.
I see a lot of people posting about how they dislike the technical interviewing process. The sentiment seems to be that for a certain class of popular developer role it's entirely unlikely that they will ever need to remember how to implement a heap or red-black tree to be effective at their job... so why use problems like this in an interview?
I think these sorts of questions should be used by teams that want to set the minimum standards on the team. I'm reminded of a rule used at the Recurse Centre: never feign surprise when someone asks a question (I paraphrase). The idea is that if someone asks you a question about something you think is fundamental, like Bash for example, don't immediately feign surprise and say, "You don't know bash?" It's not helpful. Instead take it as an opportunity to teach them something awesome. However this doesn't generally work in a professional setting where you're required to know Bash in order to function at your job.
If on my team we're responsible for the operation and maintenance of several millions of dollars worth of infrastructure that runs our customers' applications then there are certain minimum requirements for operating effectively within this team. I expect you would know Bash at a minimum. I should also expect you to know the network stack of the OS we deploy on, how TCP works, what a hypervisor is, etc. We may write most of our application code in a high-level language that abstracts these details away but that doesn't preclude you from understanding them. It's just a convenient tool. You have to know how to manage complexity and avoid premature pessimization in order to be effective and that means you will be interviewed using technical questions to screen for that minimum level of knowledge.
However I think most companies do tend to use this tool poorly. I've interviewed with startups that build consumer web applications that ask questions about radix sort and k-d trees. That's what I call, overkill. This trap is easy to fall into if your motto is something glib and banal like, "We only hire the best." If you don't quantify what "best" is you're just going to negatively filter out potential candidates and hire on bias. You have to scale the screening process to only test for that minimum competency and choose how much risk you want to take in teaching new hires.
If I'm hiring a more junior developer to our team I expect that we're going to mentor that person and make them a better engineer by working with us. They can ask questions that may be outside of our minimum standard. However if I'm hiring for a team-lead position I'm much more likely to not accept a candidate who cannot fly through our screening process. Working with them is going to be difficult and if it's 3 in the morning and they're causing more problems than fixing because they don't know how the TCP re-transmission protocol works then we're going to have a problem.
The conclusion of all this is: tweak the screening process to set the minimum standards required for effective communication on the team. Don't set the bar unnecessarily high: define what the bar should be and assess the risk of mentoring junior developers. You need a good mix across the spectrum for an effective team.