My goal writing this post is to emphasize you to deepen your knowledge in the field you are currently in, instead of trying to move to new fields too quickly. If you are a frontend engineer yourself and think what you do are basics, read my story!
My software engineering career has pretty much started in January 2018. Coming from a mechanical engineering profession, it was hard for me to easily get a job in software engineering. At the time, I successfully landed a trainee job at a small company that had a frontend solution for their clients that was built with Angular. At work, I was confrontend with Angular, UI Architectures and Client-Server Architecture. Learning Angular was pretty fun, because the framework itself developed very quickly and there were tons of things to learn and apply to the application I was maintaining.
After two years as trainee with a solid knowledge with Angular, I decided to move on and get a job as a software engineer at a company that deals with multiple projects, so I can learn from different environments. Luckily, I could land a job at an agency that helps customers expand their digitalization strategy by creating React frontends for their needs. Meanwhile I finished my study and received my bachelors diploma in computer science. After one and a half year at this company, occasionally looking at my local job market, I noticed a trend in full-stack developers being eagerly employed by mid to large companies. There were double more full-stack jobs than frontend jobs. As a fresh baked software engineer, I wanted to get future proof by gaining knowledge as a full-stack engineer, so I can always easily find a job once I need a switch again. But I had pretty much no knowledge about creating full-stack applications. From university I learnt all the basics like relational databases, service architectures, MVC and even .NET and C# basics, but I had no practical hands-on in years. So I decided to deepen my knowledge in C#/.NET in my spare time by creating leisure projects and learning online.
Mid 2021 I started applying for various job descriptions that were looking for a .NET full-stack engineer. In total I had three job application interviews that, almost predictable, all rejected me. Here are the reasons why:
The first one wanted me to create a small solution for visualizing IIS logs that were saved as text files. So I created a solution where the files get parsed, written into SQL database, read from with Entity Framework, mapped to a data transfer object with a mapper, sent to the client through an API endpoint via JSON and nicely displayed in the browser. I thought, that's what full-stack developers do. I handed in my solution in time and was invited to the company to present and discuss my solution. After presenting my solution, the responsible guy started to ask me questions. These were questions like:
- What does LINQ do internally?
- What does line number so and so do (on an automatically generated .cs file)?
- What are the differences of objet and value types?
- What can be potential caveats of your application when you need to handle millions of lines of logs?
- What are memory leaks?
- What is garbage collection?
- What is encoding UTF-8?
The moral of the story was, that he asked me lot's of questions about backend development which I could barely answer. There were pretty much no questions about frontend engineering. So my impression was, that these guys were actually looking for a backend engineer that knows a bit HTML/CSS and not a full-stack engineer. After getting rejected, I moved to the second interview.
The second interviewer didn't require me to create a small application, but during the interview they wanted me to create a UML class diagram of a problem description within 15 minutes. So I tried my best to create an agnostic diagram and try to solve the problem. They asked me questions about my solution which were related to creating a relational database out of it. Overall, they further asked me questions like:
- What does the keyword virtual do in C#?
- What are the differences between abstract classes, interfaces and class inheritance in C#?
- Does an abstract method has to be overriden or not?
- What is the difference between SQL and No-SQL?
They mainly asked me conceptual questions like class modelling, relational databases and so on. Again, there were little questions about frontend engineering and UI architectures.
The third interviewer had pretty much only technical questions about .NET and SQL Server. These were questions like:
- Can you inherit from multiple classes in C#?
- What are SQL Server functions and procedures?
- What is a left, right and inner join?
With this interviewer, there were equal amounts of questions for frontend and backend. I pretty much could answer the frontend questions perfectly, but the backend questions almost none of it.
After getting rejected from all three, I was extremely frustrated and felt like that I was stuck creating frontends forever. At the beginning, I had great interest in also doing backend development, but I highly overestimated my skills and didn't really know what a backend engineer needs to know. After calmly thinking and re-considering the feedbacks I received, I thought about the constellation of these interviews. As can be seen, they didn't want to know that much about my frontend engineering skills, just as if they were looking for a classic backend engineer only, who has some frontend skills. I could have been miserable in creating frontends and still land a job as a full-stack engineer, if I could answer their backend questions well. For me this meant that in the industry in my area, or at least the companies I had an interview with, still didn't recognize frontend engineering as an own discipline with an enormous complexity, that even has it's own bachelor programs nowadays. Becoming an expert in backend and frontend at the same time with a certain amount of deepness was no option for me. So I had to set my focus and move on.