Every summer, we welcome students or recent graduates to work on real projects alongside experienced software professionals. This year, Timo and Waltteri joined our team and quickly found themselves contributing to both customer work and internal development initiatives.
During the summer, they worked on AI-related projects, explored machine learning methods in a customer case, built internal tools, and gained hands-on experience with modern technologies and software development practices. In this article, they share how they ended up applying to ATR, what the recruitment process was like, and what they learned during their summer with us.
How We Ended Up Applying to ATR Soft?
Timo: In the beginning of 2026 I was applying for software developer trainee job postings. I knew that I would finish all the required courses for my degree during the spring, so I was about to run out of excuses for the procrastination of working on my master’s thesis. ATR wasn’t on my radar yet, but by luck a relative had noticed a LinkedIn post by ATR about the summer positions and linked it to me. I checked out the job posting and ATR’s website and quickly decided to apply.
Waltteri: I got an email notification about the position back in January, because I had applied for the same position a year before and signed myself up for the ATR mailing list. The position was exactly what I was looking for, since I was closing in on graduation, and had no work experience from my field yet. ATR was already quite familiar to me as a company, because they were an active collaborator with my student organization throughout my studies. I also had the privilege of knowing a few ATR Softers beforehand, which made the decision to apply very easy for me.
How Did the Recruitment Process Go?
Timo: In March I was invited to an interview at ATR office. The email contained clear instructions for when and where to be and what to bring along, and what I’m always grateful for, detailed directions for finding the correct door in the large office building. Naturally, I was a bit nervous going into the interview, but the relaxed atmosphere eased off any stress I had. The interview felt more like a casual conversation than an interrogation. We had good discussions about various topics, such as the future of software development and artificial intelligence. Overall, the interview went well, and I felt optimistic about my chances.
There was also a small programming test after the interview. It had a few time-limited tasks that I solved perhaps not with the cleanest code, but working solutions, nonetheless. A really nice touch was that the solutions were reviewed by a human at ATR and I received personal feedback about them. Next week, I received a job offer from ATR, which I gladly accepted. After signing the contract, I had the opportunity to meet some of my future colleagues on a coffee break. All in all, the recruitment process was fluid and with clear communication at each step.
Waltteri: The recruitment process started off with an on-site interview in March, where I got to hear more about ATR as a company and employer. The interview went well, as the atmosphere was the perfect combination of professional and laid-back. The recruitment process also included a brief programming test, which I did with Python. I had no idea what to expect from such a test, so I was quite stressed about it at first. However, after starting the test I was quickly able to focus and managed to perform decently.
About a week after completing the test, I got a call that I had gotten the position. After signing the contract, I got to meet my future co-workers over coffee at the ATR office, which was a nice opportunity to introduce myself to everyone before my first day on the job. My overall experience with the recruitment process was positive and straightforward, which was a pleasant surprise compared to some of the multi-stage recruitment processes I had encountered previously.
How the Summer Went and What We Worked on?
Timo and Waltteri: For most of the summer, we worked on a real customer project that started with a workshop with several participants from both ATR and the customer. The workshop’s goal was to identify and document cumbersome manual tasks and other pain points in the customer’s processes. From these gathered issues, one would be chosen as a candidate for building a proof of concept that would solve the issue or document obstacles preventing a solution. The purpose of a proof of concept is to test a prototype of the intended solution as early as possible to avoid spending unnecessary amounts of time working on something that will not be feasible in the end. Especially with AI solutions that are reliant on data, it’s beneficial to rapidly find out whether the current data is appropriate for the task or not.
The workshop, and thus the whole project, was artificial intelligence themed, so the goal was to use AI methods in the solution. In this context AI would include not only large language models, but also machine learning models in general.
The chosen topic was predicting integration service outages. The customer had numerous integrations between different services, each with their own logs about flow of data and alerts raised. With these logs we started working on data exploration to get to know what we were dealing with. Based on our findings and the fact that the customer had documentation of approximate start and end times for the outages, we decided to try to find out if supervised machine learning could be used to predict them.
We used feature engineering to supplement the logs with additional data such as change ratios for traffic and alarms and other features that we saw as relevant to the potential formation of outages. With the newly created features we trained models with various combinations to see which ones would perform best. Unfortunately, we concluded that the data quality wasn’t quite high enough for confidently predicting the outages.
We still wanted to push forward in finding some kind of solution to help the customer, so we moved on to unsupervised learning. In unsupervised learning the model’s goal wasn’t to predict the outages, but instead to flag anomalous activity in the logs. These anomalous events could then be compared to the estimated times of previous outages to evaluate whether the systems are behaving strangely near or during the outages. In the end the data seemed to have quite a bit of noise that would get flagged as anomalous, so it wasn’t directly usable either.
Even though the issue couldn’t be resolved in a straightforward manner, we still made valuable findings about the customer’s data and were able to propose steps to improve the logging and documentation to increase the potential of machine learning methods in the future.
During the summer we also worked on several internal projects that were mostly AI themed also. We set up a local LLM on an on-premises machine, created an application for anonymizing names from documents with the local LLM, and used an embedding model to find duplicate or related tickets based on freeform strings.
Another project we worked on during the summer was the digitalization of the visitor check-in process at our office. In line with our ISO 27001 certification, visitors to the ATR office are required to sign an NDA and have their visit logged. This has been done manually with pen-and-paper forms, which can be tedious with larger events with many participants. It would’ve been possible to acquire an established SaaS-solution for the job, but nowadays it can be smart to utilize modern tools like AI-assisted coding to build and develop small-scale applications such as this in-house.
We got a lot of freedom and responsibility related to selecting an appropriate tech stack and designing the architecture and visual outlook of the application. Defining the scope proved out to be trickier than we had originally planned, but the creation of a proper project plan and short daily meetings were very beneficial for the development of the application. We also got to learn a lot of new things, especially about the deployment of applications into Azure via Terraform.
How Is It to Work at ATR? Would You Recommend?
Timo: It’s great that even as a trainee you are given responsibility in both internal projects and actual customer projects, but at the same time there is always someone you can ask for help if you need guidance. The work culture at ATR is human-centric and the employees are trusted. I feel that this kind of environment allows people to remain more functional and encourages personal growth. The colleagues are amazing and it feels natural to chat with anyone during breaks. I would definitely recommend ATR as a workplace.
Waltteri: Working at ATR has been everything I hoped it would be. The overall atmosphere at the office is great, and I truly feel valued as an employee. The people at ATR are very warm and easily approachable, which has made working feel less like a chore and more like an opportunity to learn something new. Learning is also encouraged by having monthly learning days, which is a great benefit to have as a trainee. Overall, I would definitely recommend working at ATR.
