I had twenty interviews over the past year. Not all of them were successful. Typical examples of failed interviews:
There were four steps of an interview in one company: knowledge of the language, platform, architectural patterns, and algorithms. I failed only the last one, which was solving of two algorithmic problems of Easy/Medium level from HackerRank.
In another company, there were few specific questions about iOS SDK. And by “specific” I mean something like: “During my career, I have successfully solved ALL tasks without even knowing such a question, let alone answering it”. One of the most memorable questions was: “How does the Git diff algorithm works?”
Mobile Developer tasks
IMO 99% is layout, simple REST requests to a server, parsing JSON and flush it to UI. Of course, I heard about augmented reality, blockchain and machine learning, which require specific mathematical skills. I leave the abstract 1% on them. But I went through 200 vacancies and only once saw AR. There were no blockchain or ML at all. These technologies are used, yes. But do not be mistaken, they are far from ubiquitous. The typical tasks of a mobile developer are here:
- read and understand a lot of legacy code
- commit changes to it without complicating its understanding for colleagues and without creating new bugs
- request to a server, parsing, output to UI, change fonts, color, corner radius
Where most of the time go?
“Reading someone else’s code takes 80% of the programmer’s time” — the idea is obvious and not invented by me. The number of books, articles and talks about “How to make your code clean?” proof that this is really important.
You spent most of the time on understanding someone’s code, so any optimization should be started from that place. This is the bottleneck of a whole development process, thus improvements somewhere else just are not that important.
How to reduce the time required to understand b̶u̶l̶l̶s̶h̶i̶ code written by your predecessor? It is necessary to make everyone write the code clear. The meaning of the word “clear” is defined by the IT gurus and their endless discussions about best practices. Static code analyzers have been invented a long time ago, new syntax checking rules are constantly being added for them. Every famous company has a public style guide. Modern languages (Swift, Kotlin) allow out of the box Optionals, functional programming elements and other things that allow writing code more succinctly.
Surprisingly, I meet shit code every day… But its creators perfectly know how to balance a binary tree. How many interviewers asked me about style guides or experience with linters? Fucking zero.
Building an abstraction
Someone say: “But there are complicated things in mobile development too! It is very difficult to send data over the network, process the swipe-gesture or save data to the device memory. This should be done only by people with advanced algorithmic thinking.”
This point of view is opposite to the real situation. I know the history of not only mobile development. There is a clear development trend of simplification by creating high-level abstractions. Programmers find it convenient to use abstractions to do common tasks.
There was a time when we thought the line
for(int i = 0; i < N; i++) was the most comfortable pattern in the world. Now there is even no
++ operator in Swift at all. It was deprecated to prevent people make stupid off-by-one errors, using
Special people are working on tools for your projects. Creating languages, frameworks and services. These tools are thoroughly tested by developers and users. Just think about it. Stop for a minute and look at your life. It is not necessary to be a programmer to realize that the idea of doing something based on the achievements of other people is good.
If you still do not believe me:
- Spring Boot — abstraction above other abstractions. The meaning of that project — make configuration and usage as simple as possible
- C++17 — you still sure that every developer has to know the difference between lock and recursive_lock? Checkout and shut up
Everything proves that trend. The invention of OOP. C -> С++. Plane autopilot. Conveyor. McDonald’s. Car-sharing.
Do less, get more
People really want to be able to do more, contributing less effort. You can train super-specialists, and they will perform your complex tasks perfectly, implement it with assembly language without mistakes. You can train the pilot to have an immediate reflex to any event. But it will take more time and more money and will not bring any benefits.
Obviously, you are not able to achieve even an acceptable level of skills in all areas necessary for life. Therefore, the only right way is to become an expert in one of them and convert your skill to the services of other people. These are not just my stupid hypothesis, this is the evolution. Reuse someone else’s work. Outsource. Share responsibility. It is faster. It is better. This is how the world works.
The сognitive bias of people lies in the usual unwillingness to recognize a simple truth: a programmer should not overdo digging into the depth of his tools. He has to trust them.
If a security bug is found in the private library your company wrote, only you are to blame. No one will help you, because you took all the responsibility on you. Take people from important projects, send them to repair, lose money. If a security bug is detected in Alamofire… Well, a big part of iOS community will try to fix it simultaneously, because this is a shared problem.
Alamofire code is public, which means everyone can find errors in it, criticize the architecture and submit an issue. Thus, there are permanent patches, fixes, improvements. But with your own private library, you will detect a bug only after users’ data leak.
They say to me: “we will not use this dependency with 10,000 stars on Github; we do not trust it and do not know how it works”. I hear instead: “I consider myself smarter than 10,000 developers. I will implement my own wheel, I don’t need any help”. People know algorithms and sure that they are the gods of programming who will make everything much better. This prevents the rational use of time, increases risks for a company and costs of developers who imagined themselves to be gods of program design.
Popular opinion is: “Without deep knowledge of how your tools work, you cannot consider yourself a professional. In case of a problem, you can not figure out where to look for its reason. You depend on the manufacturer of your tool.”
When you just hit your finger by a hammer of a well-known company — you have only two choices:
- You start to dig into materials of the hammer, studying alloys, chemical composition. Then you buy a small quantum physics textbook for dummies and learn that the atom is not the smallest particle. You now understand a lot about how a hammer works. But your finger still hurts and a nail is not clogged.
- You realize you are a fucking retard and problem is you, and with the second try carefully hammer a nail.
Okay, forget about metaphors. A situation in which your tool crashes may occur. But even without knowing exactly how the hammer works, you will understand that reason is inside of it. If you are able to read and understand code, you get the ability to locate the place of an error. If there is your tool usage near an error, it makes sense to contact the manufacturer
Should you dig into and correct the error yourself? In my opinion, no. When your car breaks down, you go to a service center. When your health breaks, you go to the doctor. When UIKit breaks, you submit a radar. This is the advantage of our century — you could get help by professionals at any time.
But if you still really want — dig into. But only after a necessity occurs! Until that moment just run
pod update more often and do not think about anything. It is scary to not have full control, but you get used to it. You trust someone every day a hundred times. Telephone manufacturers, taxi driver, restaurant chefs, public utilities.
What is the problem
The requirement to understand the in-depth structure of all your tools is counterproductive. Regressive, I would say. A cook can be a professional without any knowledge in the knife smelting technique. A racer can be a professional, not knowing where gasoline comes from. There are no prerequisites for this, it is not necessary. A professional is a person who knows how to use his tools to produce high-quality output. Whether it is a tasty dish, the best time on the track or 5-star mobile application.
The thing is the ability to solve algorithmic problems will not help you to quickly understand code or write it in a clean way. And, there is an opinion, the code for solving an algorithmic problem is the least readable code in the world.
These companies demanded me to have a counter-productive mindset. The mindset that literally contradicts progress, evolution and rationality. At the same time, skills that could really improve the quality and speed of my work (using third-party tools and linters) were ignored and even perceived negatively.
One minute of rationality
I know that the gods of programming really exist. They create amazing things that everyone uses without any doubt. And these things are really complicated, far from just painting a button with a new color or
view.layer.cornerRadius = 4. But these people are unique, they are just tenths of a percent of the total number of developers. And please do not compare other developers with them.
Business rarely needs to create something revolutionary new. It almost always wants “like in those project” and “stable and scalable”. Business is not interested in your new wrapper over
NSURLSessionTask. If you want to develop tools, you can go to work in this area. Read complicated books, gain all the necessary skills and go to the Swift Core team, for instance. BUT THERE IS NO NEED OF ALGORITHMIC SKILLS FOR E-COMMERCE APPLICATIONS. We are not going to send fucking Tesla to space here, ok?
It is very comfortable to believe that being a programmer means being an inventor, creator and architect. Spend every day in the deepest fabrication of abstract matters and concepts. But that’s just … it’s self-deception. The industry needs code monkeys which can perform monotonous work with required quality and speed. And it is a very big question: does industry need your creative potential. Maybe you just want it to be true?
There is my question: “Do every iOS dev really needs to know algorithms?”. A man answered me with Churchill quote:
meaning that this is better than any other ways of checking a level of dev’s knowledge.
I totally disagree with that. The best answer of an ordinary developer on the question “Which ways of sorting an array do you know” should sound like: “Just call
.sort and pass comparing closure”. And no quick or bubble sort.
With the same success we can call the ability to solve integrals the main criterion of “competence”. Or, for instance, the ability to make your own motherboard. Well, that is about logic and computers too. Wozniak knew how to do it, why can’t you?
Interviewers have to check employee for corresponding with business REAL NEEDS. If the business needs me to quickly repair the bug and implement a new feature clearly, give me a test task to find & fix a bug. Give me a task to refactor a class and make it readable for others devs.
Famous and rich companies can afford any illogical shit. Require candidates to be a dovahkiin. But the problem is that other not very smart people look at these stars and believe everything. “Do they hire only Harvard graduates for scrubwoman job? LET’S ADD THIS REQUIREMENT RIGHT NOW”. This is the way the cult of a fucking cowboy engineer is created and maintained. That is why we have devs who despises usage of someone else’s decision. They just come to any project and invents their genius wheel, which nobody understands. And two years later business wonders why is it easier to rewrite a project from scratch than fix all issues.
Let’s be honest. Call me at least three algorithms that are needed in iOS. Except for the diff algorithm, which is already approved for adding into Swift.
Fuck the algorithms. Learn rules from Swiftlint/Rules.md by heart.