It sounds like you have gone with the breadth approach so far. Maybe go deep on a couple of things where there are problems at work. You mentioned "little bit

It sounds like you have gone with the breadth approach so far. Maybe go deep on a couple of things where there are problems at work. You mentioned "little bit of mysql" dive on that a bit more. There is a huge amount of tuning that can be done on SQL queries to make them faster. If you have small data sets that are expected to grow over time, they may be fast now but will slow down. This is usually the biggest bottleneck on any web app. In the early, wild west days of the internet, people stuck SQL code, Javascript, CSS and HTML into one PHP page (or Perl script or whatever). Good idea or bad idea? Those types of things have driven a need for separation of concerns. That is why MVC, MVVM, etc. have come about. Usually you are stuck with whatever design pattern your tooling uses. Maybe have a discussion with your manager about what is driving the need to use micro services and docker containers? Typical useful answers are scale, traffic and reuse. If you get more of a blank stare or jumbled type of answer "monoliths are bad" then it sounds like someone wants to get buzzwords on a resume.