Use code GSBLAZOR20 at checkout to get 20% off our new Getting Started with Blazor course: https://bit.ly/4c9g8YA

Become a Patreon and get special perks: https://www.patreon.com/nickchapsas

Hello, everybody. I'm Nick, and in this video, I will review a codebase that was submitted as a coding test for an interview and got destroyed by the interviewer for how bad it was. Was it really that bad?

Workshops: https://bit.ly/nickworkshops

Don't forget to comment, like and subscribe :)

Social Media:
Follow me on GitHub: https://github.com/Elfocrash
Follow me on Twitter: https://twitter.com/nickchapsas
Connect on LinkedIn: https://www.linkedin.com/in/nick-chapsas

Keep coding merch: https://keepcoding.shop

#csharp #dotnet

Nick Chapsas

Nick reviews a candidate's take-home assignment for a .NET developer role. The candidate's solution included a basic REST API with in-memory database and unit tests. Feedback from the interviewer was harsh, citing issues with project organization, use of Entity Framework, and REST API principles. Nick provides insights into these criticisms while suggesting alternative approaches and improvements that could have been made. He also mentions practices that could impress interviewers and the importance of following coding standards.

"I Lost a Job Because of This Codebase"

Very good video, thank you for this.
I would like to add :
Placing “/api/” in front of a route is not a bad practice, whether you’re designing an API using REST principles or following a RESTful approach. The API should accurately reflect its intended functionality. So if the route is an API, prefixing by “api” is a good point.
However, it’s important that this intention remains broad and resource-focused. For instance, avoid using “/api/route/create” and instead prefer “/api/routes”. This aligns with the RESTful principle of using HTTP methods (POST, GET, PUT, DELETE) to define actions, rather than embedding them in the URL. It’s particularly relevant if you’re aiming to implement HATEOAS, where the API itself provides links to guide clients on available actions. By focusing on the resource rather than specific actions in the route, you create a more generic and flexible API, which in turn facilitates maintainability, scalability, and evolution.