Edgaras’ Junior IT Engineer experience @ the LEGO Group

While still being in the last semester of my Software Engineering studies, I had stumbled upon a few relevant job posts on LinkedIn from the LEGO Group


What struck me as a surprise was that quite a few of them were for junior positions and the technologies advertised were the current hot topics of certain IT circles today (more on that later in the blogpost).

Written by Edgaras Petovradzius
Junior IT Engineer at the LEGO Group

The main reasons for the surprise were that it is commonly known that many of the tech companies expect you to have at least a few years of experience in the field to be eligible for the candidate position. Moreover, large companies often struggle with innovation in technology, due to various reasons, e.g. “red tape”, where any change within the organization has to go through many “gatekeepers” and fill very strict requirements. However, judging from outside and purely from my personal experience that did not seem to be the entire case.


From the job post it was quite obvious that in the position one would have to heavily rely on “Microservices” software architecture, deployment of applications inside Docker containers on cloud solutions e.g. AWS EC2, orchestrating containers with Kubernetes and utilizing large array of services for monitoring and maintaining of such clusters. Inspired by all of this I did indeed apply for the position, and now after being with the LEGO Group for a few months, I can share some of my experiences as a developer and verify if what was advertised is actually true.

Allowed to choose MAC or Windows PC

At the very start, I was asked if I would like to use Windows PC or MAC, which to me came as yet another surprise. I had heard many anecdotal stories, where developers have no choice, and they have to be coupled to one or another hardware and operating system. It would be too optimistic to say that every single developer in the LEGO Group is guaranteed that choice. Still, in my case, I was fortunate to be asked and based on the nature of the technologies to be used (Things running on Linux kernel) I ended up using MAC.

It definitely took me out of my comfort zone since I had been using Windows operating system for nearly two decades and had been writing software on it for at least a couple of years. However, I have always been a firm believer that challenging yourself and learning things from scratch is an essential part of personal and professional growth, and I just jumped right into it.


Now that I have tried both, I would strongly recommend every developer trying them out for at least a short while. This will not only broaden one’s knowledge but also open up a whole new world of possibilities when deploying applications on different devices.

Foundation Platform

Having the operating system in place, I learned more about what specifically I would be working on as a developer, namely the Foundation Platform. I already knew that the was rather new, not even one year old and that just added more to my excitement since I was to be a part of something almost from the very beginning. The problem statement that we as a team were to solve with the help of the Foundation Platform was and still is:


To ease developer experience when going from code to productions.

That sounds great, but I was still keen to know more. I knew right from the start that I was to work with the container orchestration system – Kubernetes, but I was not sure how. However, I rather quickly learned that developers run their applications inside virtual units called containers, e.g. those offered by Docker and that these in turn then can be orchestrated as another abstraction layer called cluster, e.g. those provided by Kubernetes. Bear in mind that this is an extremely simplified definition. To explain containers and their orchestration in detail would be a whole additional article.

Furthermore, I learned that I would work with a range of different tools and services for monitoring and maintenance of Kubernetes clusters such as Prometheus & Grafana for fetching and displaying data about health of e.g. physical units within clusters, Elastic & Kibana for logging, Argo CD & GitHub Actions for continuous deployment and many more. This was exactly what I expected before starting in this position, and I was very excited to find out that these tools are indeed heavily utilized.


But then I was left with two very important questions to myself. What about coding, and how can I grow as a developer? And I was not left disappointed here either. Almost immediately, I got a few development tasks where I had to code in Python for the backend, utilize AWS Dynamo DB and MySQL database systems for persistence, and develop frontend with React (Typescript). Also, I used AWS CDK for Python to deploy applications on AWS EC2 instances, and this led me to yet another journey – learning more about cloud services and more specifically, AWS. However, it should be noted that we try to be as flexible and innovative as possible and from technological standpoint by not locking us in on one specific cloud provider.

It is also important to mention that in both my team and teams around me there is a vast array of experts in different technologies. I can always ask for advice in Software Architecture, Networking, Machine Learning, Data Engineering, .NET Core, AWS, Azure, React, React Native, SAP and many more since we have at least one expert nearby, or on a contact list if working remotely. Furthermore, I can request code reviews from experienced developers at any time and get constructive feedback and useful advice.


Being brave & curious is also at the core of the developers I work with at the LEGO Group. As an example, a couple of developers from my team decided to experiment with developing the platform in GO programming language. After couple of weeks, they realized that for the specific purpose, Python would be a better fit, and then the code was rewritten. One could say that time was wasted, but the learnings coming from the experimentation are valuable and good practice in how to pivot and be agile when critical decisions need to be made. It also shows that developers here are willing to try new things.

That having been said, all my questions regarding growing as a developer were answered with practical examples, and then I only needed to ask myself, how much of this knowledge can I obtain, and how can I improve to be able to learn more?


Having fun is also an integral part of working in the LEGO Group. One of the activities done periodically is the hackathon, where team members get together, think of a relevant (usually small scale) problem, and try to solve it together with the help of technology.


During the last hackathon, we tried to build a Foosball table scoring and monitoring system which would allow for displaying if anyone is currently playing (including score) and the possibility to invite other players via mobile app.


We used LEGO® MINDSTORMS® sensors to track object movements, Raspberry PI to run the application (inside Docker container), React Native to build the mobile app for displaying the score and getting notifications and finally pushing the results to the AWS SNS. It was a very motivating experience seeing everyone from Juniors to the Lead developers working together, sharing knowledge, and most importantly having fun.

After working as a developer for a few months in the LEGO Group, I can conclude that innovation and brave thinking is indeed practiced between the teams and that it’s a great place to grow – both personally and professionally. Not only do you get to work with the newest technologies, but you are also allowed to take decisions independently and receive feedback and support from great colleagues.