Does a programmer need math
I first wrote a line of code 10 years ago. Since then, every day I am amazed at how many opportunities development has opened up for humanity. I got into development by solving algorithmic problems and participating in programming competitions.
I completed my first commercial project 7 years ago. Then I realized that it is not enough to write a working efficient code in a short time. An engineer must know architectural approaches, adhere to style and write readable code in a trite way.
But the article will be more about the first: about writing working efficient code that will last a long time. It will be useful both for beginners who are looking for opportunities for professional growth, and for experienced professionals who know several languages, can slam any bug and pull any project, but strive to develop new projects.
The eternal holivar on the topic “does a programmer need math” is being changed and turns into a more dangerous dispute for the industry. Increasingly, on forums, conferences and in the minds, the thought flashes: “Does a programmer need to know algorithms and data structures?”.
And this controversy exists. It is doubtful that when developing a product, you will have to implement quick sort or a dictionary yourself. Advanced data structures will be useful for no more than 10-20% of engineers. And even if a person is included in this percentage, he will object: “Everything is Googled and learns in a couple of days.”
The opinion of the opposite side is expressed as follows: “In 5-7 years, 80% of the tasks that are necessary when developing a product will be able to be performed by schoolchildren of 13-14 years old who have completed high-quality courses. But companies need engineers who can solve the other 20%.
” This can be knowledge in mathematical statistics, and in algebra, and in programming theory. But the foundation, in any case, is built on the knowledge of algorithms and data structures.
Therefore, interviews in FAANG or MINT for 60% -100% consist of Problem Solving tasks, most of which require knowledge of algorithms to solve. Now this trend is also moving to middle-size companies in the world and in Ukraine.
From personal experience I can say that I wrote in C++, .NET and Python. And regardless of the language, I used the knowledge of algorithms.
Algorithms for interviews
Each company has its own approach to interviewing and evaluating candidates. The purposes of hiring also differ. But there are things that unite them. I’ve interviewed for various companies of various sizes and directions.
Somewhere algorithms and problem solving were a key factor, somewhere – an auxiliary one. Tasks can be of different levels of difficulty. For example, the simplest one I’ve seen is to expand a string without using additional memory.
One of the tasks was to be able to quickly calculate the maximum value of the xor function on a prefix tree (boron). Its complexity was more in the non-obvious solution than in the implementation.
A good interview problem should have several possible solutions besides the optimal one. It is impossible to know everything.
An example of a bad problem that I met in an interview is finding a solution to a system of ordinary differential equations. In reasonable time it is impossible to get closer to the solution if you do not know the Runge-Kutta algorithm.
The same type of interviews are usually designed just not to test the ability to memorize rare algorithms, but to effectively use standard ones. What is the difference between approaches in different companies?
Large corporations
Giant companies do not care what language you know or how many frameworks you have learned. Microsoft, Google or Tesla don’t need “executors” of which they have tens of thousands.
These companies need people who can invent and create a new product, optimize an outdated one, and further push these companies up. Multiply this by the number of candidates and the required resource for selection.
As a result, we get “algorithmic” interviews. This approach is criticized, trying to change and improve. For example, questions about soft skills or system design. Such interviews sometimes weed out worthy candidates, but they continue to be conducted and prove their effectiveness.
Like it or not, you need algorithms to get into a company like this. The difference between large and medium-sized companies is that in the former, Hard-level tasks are less common, and knowledge of advanced algorithms is not required, because they recruit many candidates and it is simply unprofitable to miss a good engineer due to ignorance of a particular data structure.
It is not even the knowledge of algorithms that will help to pass such an interview, but the number of typical tasks solved. It is important to understand that the right decision does not always guarantee a successful interview.
Just like a non-optimal solution does not guarantee failure. People want to work with people, not coding machines, so they want to see how you think and speak. Trial interviews are very helpful in developing this skill.
You can conduct them with a friend, colleague or on various resources where you can conduct and pass interviews with random people. The classic manual for getting into large corporations is the book Cracking the Coding Interview. And if you want to get into one of them, then I advise you to read.
Medium companies
The experience of the best is adopted by the organizations chasing them. There are at least 3 companies in Ukraine that focus on problem solving interviews (DataRobot, Ring Labs, Grammarly). An even larger proportion include them in their interview process as ancillary.
At a certain stage in the development of the company, it will need speed, optimization, and new cool features. Is it possible to come up with something new without knowing and understanding the existing one? The answer is obvious.
In some medium-sized companies, there may be tasks that require targeted preparation. This is possible due to the specific requirements of the project and limitations in the number of candidates recruited. When you recruit 10 people, not 1000, then you really want to select the best of the best.
Startups
Any successful startup is not only a cool idea, but also a high-quality implementation. At the very beginning of the journey, when PoC (Proof of Concept) is being written, both architecture and optimization can be ignored. In this case, when developing and expanding a startup, you will have to allocate time for rewriting / refinement / refactoring.
It would seem, what does the algorithms have to do with it? Problem solving problems also develop the ability to quickly write a solution to a problem without thinking about the architecture.
And this is often what you need to get started: write “something” that will work in the shortest possible time. Therefore, “sports programmers” are treated with caution. Yes, they will write anything for your product in minimal time. Will this code be supported by someone else? The answer to this question is vague.
On this wave, we can recall an article about the Ukrainian startup Looksery, which was founded by people associated with the Olympiads. They recruited their own kind: winners and participants of the ACM ICPC (Student Team Olympiad), finalists of the IOI (Olympiad for Schoolchildren), guys with a high rating on CodeForces or TopCoder. How this story ended, I think everyone is aware, or can find out at the link above.
On the other hand, startup interviews are the most unpredictable. Sometimes it can be one interview about experience and “what you want to do”, and after that – an offer. Otherwise, it can be a lengthy process with 8+ interviews of varying difficulty.
Outsourcing
Outsourcing is more difficult. Out of all types of companies, I interviewed the least in outsourcing, but talking with many colleagues / friends who work in various outsourcing companies, one can draw conclusions.
I have never met people who were asked to outsource problem solving. In small / medium / large – it does not matter.
This is due to the fact that outsourcing needs to immediately throw the developer into battle. It is important for them that he understands the language, frameworks that are used on the project.
Also, the candidate must pass an interview with the customer, who is also not profitable even for 2-4 weeks to train an employee. Let’s add here a large percentage of legacy code, which is not something to optimize, but difficult to maintain.
As a result, we will get an interview that tests your memory, experience, anything, but not the ability to solve problems. In addition, a large outsourcing company has its own academies, where they prepare Trainee, Junior positions for themselves. It is beneficial for them to shove a couple of frameworks into the student’s head than to try to teach him to solve useless tasks on the project.
If you have stories about outsourced problem solving interviews, share them in the comments. Let’s hope for the best.
Using algorithms in real development
During my career in various companies in three countries (USA, Germany, Ukraine), I, one way or another, came across algorithms. Sometimes this is an implicit use using standard libraries, sometimes it is an explicit implementation.
Even ordinary inheritance is, in fact, a graph of relationships between classes. It turns out that every day at work, programmers use some kind of algorithm or data structure. Hash tables, sorting, search algorithms and other popular algorithms are already implemented in most popular languages.
And the better understanding of how these algorithms are implemented internally, the easier it will be to find an effective application and not encounter unexpected bugs that are difficult to track down.
Two of my favorite examples, which have come up more than once, are exclamations: “Why is it taking so long?” when using hash tables. And the second example is a test flake when sorting is used.
Typical example
Given: long strings with the following structure: “{time}. {a lot of information about what happened at that point in time}” (structure may vary). For each row, you need to calculate some value. For example: how many times it was viewed, edited, etc.
The programmer decides to use the standard dictionary, HashTable, unordered_set, depending on the language. But “under the hood” is the hash table.
The code is written, the tests are passing, we got the approval – merjim and launch it into production.
And on the prod we get that the request is being executed for a long time, updating the data generally takes a couple of minutes. The programmer is confused and panicking.
What is the problem?
In that, theoretically, obtaining a value by hash in.
How I Came to Learn Algorithms and Tips
To be honest, I’m lucky. I came into development and started learning architectural and technical approaches after learning algorithms and solving 1000+ problems on various resources.
And my path looked something like this: you see a problem -> you don’t know how to solve it -> you study, implement, modify the appropriate algorithm.
This path is long and laborious, especially when combined with real work. But there are resources that help streamline this process.
LeetCode.
There are many tasks and collections from easy to hard levels. For each task, a discuss is available, where people share ideas for solutions and implementation in various languages.
InterviewBit.
Here the tasks are divided into levels and topics. You can also set the number of days before the interview and see your progress. Plus, tips and solutions are provided for each task.
There are also resources that offer learning in a more playful way. For example: Codewars or Code in game.
If you want to take it to the next level, learn advanced algorithms and solve related problems, then you should take a look at competitive sites such as Topcoder, Codechef and others.
I also advise absolutely everyone to read the book “Algorithms. Construction and Analysis” by Thomas Kormen.
It describes in detail most of the popular algorithms. In addition, the book is written in clear language and is easy to read, both in the original and in translation.