- 1 Should an experienced programmer know about algorithms?
- 2 Do you use algorithms in your daily work at Syncron?
- 3 As a Principal Software Engineer, what do you recommend to people who would like to acquire or refresh their algorithmic knowledge?
- 4 The number of algorithms described in the literature can be overwhelming – which ones are worth paying attention to first?
- 5 Do you verify knowledge of algorithms in the Syncron recruitment process?
- 6 What else would you recommend Syncron for?
The art of programming requires everyone to know code, but what about the scary algorithms? Many programmers believe that they don’t need algorithms in their day-to-day work, and the most experienced professionals only have a distant memory of them from university times. Łukasz Siczek is one of those programmers who think otherwise. As a Principal Software Engineer at Syncron, he would like to share his perspective on why knowledge of algorithms is important in a career and how this applies to his daily work.
Should an experienced programmer know about algorithms?
Many experienced programmers do not work with algorithms on a daily basis. They design complex systems and implement key features. They claim that knowledge of algorithms was only needed at university.
My experience has shown me that this is not the case. I think understanding algorithms is necessary for every programmer. Let us note that any code that implements a feature of a given application uses algorithms that are most often embedded into the programming language. It is worthwhile to consciously select tools for a problem. Only then can we prepare the best solution.
We want our applications to have as many users as possible. With increased system traffic, there may be areas that run noticeably slower. In such a case, a very common solution is to increase the computing power supporting the system, which involves additional costs.
The expenses for infrastructure maintenance are often downplayed when compared to the programmer time costs. This is not a mistake in the case of small systems, but when we are talking about complex applications processing terabytes of data, the costs resulting from non-optimal solutions can turn out to be astronomical.
This is why at Syncron we take a different approach: we are able to analyse the design of the application and propose an algorithm that is more computationally efficient and does not require changes to the infrastructure. As a result, the system will run faster without the necessity to increase computing power, making it possible to invest the money in a better way.
Do you use algorithms in your daily work at Syncron?
Yes, our main system, Syncron Inventory, is designed to help huge enterprises manage their warehouse processes and product supply chains. Our customers are constantly striving to provide services to their clients as quickly as possible, while minimising the need to store large quantities of products in warehouses, which generates high costs. When carrying out this task, our programmers work with the Data Science team, which is responsible for developing prototypes of new algorithms for predicting demands for given products, etc. Developers implement and adapt them to the existing code, while maintaining quality standards.
In addition, the product we build in Poland must be adapted to handle a very large volume of data. As an example, I can reveal that the database of one of our most important customers occupies more than 9,000 GB. Therefore, when designing new features, it is imperative that our developers consider the size of the data on which the system will operate. I think we stand out in Poland when it comes to the above. Most of the systems developed in our country are not designed to handle large amounts of data.
As a Principal Software Engineer, what do you recommend to people who would like to acquire or refresh their algorithmic knowledge?
The answer is not clear, because in today’s world we have virtually unlimited access to knowledge – including free knowledge. We can find a lot of great articles on this subject on the Internet. However, studies at a college or university will be the most proven source of knowledge about algorithms. It doesn’t necessarily mean attending lectures – my alma mater provides materials for the course ‘Algorithms and Data Structures’ on its website – you can find the link at smurf.mimuw.edu.pl.
For those who prefer the traditional way of acquiring knowledge, I can certainly recommend the book entitled ‘Introduction to Algorithms’ published by PWN in 2012.
Theory is one thing but practice is also very important. Learning algorithms – like mastering programming skills – is all about working with code. We can practice our algorithmic skills using online platforms to master coding, where the solution to the task requires the use of an optimal algorithm. Examples of such sites include en.spoj.com and hackerrank.com.
The number of algorithms described in the literature can be overwhelming – which ones are worth paying attention to first?
In my previous answer, I pointed out a general and very broad source of knowledge about algorithms.
Coming from more than 10 years of my experience as a programmer, I can indicate the following algorithms to focus on first: sorting, searching, data structures: List, Queue, Map and Set, as well as computational complexity, i.e. evaluating and comparing algorithms with each other.
For example, choosing the right data structure for a particular problem can significantly reduce the computational complexity required by the system.
Do you verify knowledge of algorithms in the Syncron recruitment process?
We tailor recruitment to a specialisation/specific role (Back-end/Front-end), however we expect every programmer to have knowledge of the basics of algorithms.
This is specifically important in those teams that develop modules of our core Inventory system focused on predicting certain phenomena, such as Forecasting (the aforementioned cooperation with Data Science) and when processing large volumes of data.
One of the recruitment tasks is to come up with an efficient algorithm to solve the described problem. During the interview, we ask the candidate to indicate the computational complexity and to test the correctness.
When recruiting for positions with less exposure to the algorithmic heart of the system (e.g. Front-end or DevOps), we choose tasks that do not require algorithmic knowledge. During the recruitment meeting we focus on evaluating the correctness and readability of the solution, while discussing the computational complexity of the code.
What else would you recommend Syncron for?
In my opinion, attention to quality is one of Syncron’s greatest strengths. As a product company, we know that we will be working with the code we develop for many years to come. Due to the above, we place a very strong emphasis on automated testing and the code review process, and here we engage the most experienced professionals from the team. This process is an excellent opportunity for development, especially for younger team members.
Syncron offers a flexible working model. When the pandemic began in March 2020, as a company we very quickly switched to remote working mode, which did not result in a decrease in the productivity of our developers. As of the beginning of 2022, we have a working model that we call Flexible@Syncron. Each of us can decide whether we prefer to work in the office or remotely. None of the above options is imposed.
If we decide to come to the office, depending on the day of the week, there will be treats waiting for us: fresh fruit on Mondays, sandwiches for breakfast on Tuesdays and Wednesdays, and on Thursdays in the afternoon we can catch a sweet treat, known as Fika in Swedish. In addition, playing board games together or watching films are examples of our office integration.
The location of the office is also unique. It is near the picturesque and popular Grzybowski Square in the centre of Warsaw, where we can be eyewitnesses to scenes from famous Polish films and TV series, for example “Psy 3. W imię zasad” – the escape scene with Marcin Dorociński.