Can you tell us about the use of algorithms in your work? What was your personal process of learning about algorithms? I'm still a bit scared of algorithms. In addition to that, do you think you should spend more time in college learning about applications or theory?

Today I'd like to talk about my own process of learning algorithms and how they are used in real work.

Before, we thought that big data is always better than good algorithms. That is, as long as the amount of data is large enough, even if the algorithm is not that good, it will still produce good results.

A while back, the Geek Time app published a geek news article, "Algorithms are more important than data, and AlphaGo Zero beats the old version." The news was that DeepMind, Google's artificial intelligence team, had released a new version of its AlphaGo computer program, called AlphaGo Zero, which was able to quickly teach itself Go from a blank slate without any human input, and beat the previous generation of AlphaGo 100-0.

AlphaGo Zero's biggest breakthrough was the implementation of a new algorithm, called AlphaGo Zero, which was able to learn the game from scratch. AlphaGo Zero's biggest breakthrough was the realization of the "blank slate theory.

AlphaGo Zero's biggest breakthrough was the realization of the "blank slate theory," which states that a baby is a blank slate that can be learned and trained to improve its intelligence, and that Turing, the pioneer of AI, believed that if you could machine-build an AI similar to a child's, and then train it, you could get an AI with adult-like intelligence that would surpass human intelligence.

The self-taught AlphaGo Zero is a realization of this theory. According to David Silver, AlphaGo's lead researcher, algorithms are more important than so-called computation or the amount of data that can be found in AlphaGo Zero. In fact, AlphaGo Zero uses an order of magnitude less computation than past versions, but because it uses more principles and algorithms, it is instead more powerful.

This shows that the importance of algorithms in the era of big data is becoming clearer every day. A qualified programmer must master algorithms.

I don't know how people start to become proficient in algorithms and data structures step by step. In my sophomore year of college, I was first exposed to Data Structures, because I had never had any training in this area of thinking, and at that time, I had more trouble learning this course. I had less exposure to programming at that time, so I didn't have a lot of real-world experience that allowed me to appreciate and appreciate where the "beauty" of a good data structure and algorithm design lies.

When I started learning, I was even a bit of a rote learner, and I didn't really know what would actually go wrong "if you don't design it this way". The various time and space complexities were also just math games to me that couldn't be incorporated into real-world problems. As for "the time-space complexity of each worst-case and average case with various orderings", why were they so important, I thought at the time, maybe because they would be tested on the exam.

I didn't realize that I would be re-engaged with algorithms at a later date. Maybe it was because Rice University gives such high scholarships that each graduate student is required to be a teaching assistant for five semesters without pay . Coincidentally, I was picked twice by the algorithm teacher to be a TA. So, as fate would have it, I was forced to go through a copy of Introduction to Algorithms no less than four times. As a result, I have basically done the exercises in the entire book, and some of them more than once. The process of learning algorithms was the process of reading Introduction to Algorithms over and over again.

So what is the point of learning algorithms?

First of all, algorithms are the key to interviews in China. I'm not sure about the situation in China, but as far as IT companies in Silicon Valley are concerned, not only do phone interviews favor algorithms, but at least two rounds of on-site interviews are about algorithms and programming.

Bigger, older companies, like Google, Facebook, Link, Dropbox, etc., write programs directly on the whiteboard. Smaller, newer companies, like Square, Airbnb, etc., are required to write runnable programs on the spot, while Twitter, Uber, etc., do both, depending on the situation.

There are other parts of the test such as system design, but if the algorithms do not have a good foundation, the first hurdle will be very difficult, and the algorithms should be familiar enough to be able to write a positive solution on the spot in a short period of time, so a lot of people need to brush up before preparing for the interview.

On one occasion I was an interviewer, interviewing another person on the phone, and was using Codepad *** to enjoy it, asking the other person to write a runnable regular expression parser. 45 minutes passed, and the other person didn't write it. I routinely asked, "Do you have any other questions you'd like to ask or learn more about?" The other person, presumably frustrated that he couldn't write the program, asked back, "Do you guys write regular expression parsers every day at work?"

For a moment, I was speechless. After some thought, I replied, "Not every day. Then I'll give you another 15 minutes to prove to me what else you know, or any reason why I should give you a further interview?" The person on the other end thought for a moment and silently hung up the phone.

Honestly, I have reservations about the extent to which algorithms are currently favored in interviews. Answering algorithmic questions well doesn't make you a cow. There are times when cowboys lose their horses because they don't want to brush up. But apart from the algorithm test, there is obviously no better way to prove a candidate's strength; however, how to optimize the interview process is also a topic of endless discussion, and every discussion is bound to end in vain.

Second, programming is more about algorithmic thinking than about writing specific algorithms. When it comes to the chances of actually using algorithms on the job, let's see -- the range is somewhere in the neighborhood of 10%.

Some of my friends encounter more algorithmic scenarios at work, some less. More often than not, it is the understanding of business logic, the proficient use of various features of the programming language, the grasp of the code style and patterns, various synchronous and asynchronous processing, including code testing, system deployment is formalized and so on. There are very few opportunities to design or even implement an algorithm, and even if you do, it's probably too late to learn it now.

But the advantage of being familiar with basic algorithms is that if you need to read a piece of code that contains some basic algorithmic ideas for your job, you'll be able to understand the meaning of the code much faster than someone who doesn't know algorithms. When you read a piece of bad code, you know why it sucks, where it sucks, and how to optimize it.

When it comes time to actually design an algorithm in a program, being familiar with algorithms will give you a more complete solution, and you'll be more sensitive to algorithms or more complex time-complexity problems that come up in programs. Being familiar with algorithms you can also be a better interviewer and can talk to other engineers without being despised.

Lastly, engineers who are not proficient in algorithms are never good engineers.

Of course, in addition to the basic algorithms in the Introduction to Algorithms, which have become classics, as well as algorithmic thinking (Divide-and-conquer, Dynamic programming), etc., algorithms are ubiquitous in the various technologies that we come into contact with on a daily basis.

Take the example of the storage that everyone will come into contact with, a variety of different databases or key-value storage implementations will involve a variety of sharding algorithms, cache failure (Cache Invalidation) algorithms, locking algorithms, including a variety of fault-tolerant algorithms (synchronization algorithms for multiple replicas). Although it is not usual to write these algorithms -- unless you happen to be a database implementation -- but really understand the details of the algorithm and implementation of this technology, both for the technology selection and the overall performance evaluation of their own programs are essential.

For example, when you need a key-value store in your system, which of the various alternatives should you choose?

No one solution is ever the best in every way. Take Facebook's open source RocksDB. Anyone who knows its history knows that RocksDB is a key-value store built on top of LevelDB, which can run efficiently on multi-CPU servers. LevelDB is based on Google's BigTable database system concept.

Back in 2004, Google started developing BigTable, and its code relied heavily on Google's internal codebase, which made it impossible to open-source BigTable. 2011, Google's Jeff Dean and Sanjay Gemmawalt started to re-develop an open-source system based on BigTable's ideas, and guaranteed that they wouldn't use any of Google's codebase, which led to the development of LevelDB, which is a key-value store built on top of LevelDB. In 2011, Google's Jeff Dean and Sanjay Gemwalt started to develop a similar open source system based on the BigTable idea, and promised to do it without using any of Google's codebase, which led to LevelDB, an implementation of a key-value store that is also used in Google Chrome's IndexedDB, which also provides some support for open source in Google Chrome.

I've mentioned CockroachDB in the past, but it can be seen as a distributed implementation based on RocksDB. On another level, CockroachDB is an open source implementation of Spanner. Knowing this, we know that these databases or key-value stores are in fact the same family. If you look at the underlying SSTable algorithm of LevelDB, you can see that they are both effective storage systems for high throughput, sequential read/write workloads.

Of course, in addition to the most basic algorithms in a system, there are many implementation details and system architectures that can have a significant impact on performance and applications. However, understanding and grasping the algorithms themselves will always be an integral part of gaining a deeper understanding of the system.

There are many similar examples, such as log analysis and scheduling algorithms for ride-hailing software.

Take the payment field that I am more familiar with, for example, the compression of credit card BIN parameters, the data transmission from the server to the mobile app, in order to make the transmitted data small enough, the data needs to be compressed and encoded.

Each country, such as China, South Korea, Mexico, credit card prefix format is different, how to try to compress without being too complex, so as to affect the complexity of the code on the mobile app side, or even the formation of bugs, and so on, also need to have a detailed understanding of the various related algorithms, in order to make the optimal program.

On algorithms, let's summarize:

In the era of big data, both data and algorithms are equally important, and even algorithms are more important than computing power or data volume.

How to learn algorithms? Read classic works, do problems, and then read and use algorithms in practice.

Algorithms are a knockout for interviews and can help you get a job you love.

It's more the algorithmic ideas that are used in writing programs, not writing specific algorithms.

An engineer who is not well versed in algorithms will never be a good engineer, and only with an exhaustive understanding of the various relevant algorithms is it possible to make the optimal program.