Algorithm Problems are not the Only Standard to Evaluate Programmers
Many companies have started their interview process recently. A few days ago, a good friend of mine applied for a job at an internet company known as “Engineer’s Paradise”, but unfortunately failed in the first round of interviews. The reason might be that he spent an hour on a tree algorithm problem. I think it’s too rigid to judge a person’s ability based on a single algorithm problem. Of course, such companies may have too many applicants and don’t have time to carefully evaluate each one.
Tonight, a classmate took me to visit Tsinghua University and we took a detour to Tsinghua Science Park. I guess I can say I’ve been to the door of this company that countless programmers aspire to. On the way back, I was thinking about the possible drawbacks of pure algorithm problem interviews. On coolshell, I saw articles with similar views to mine, “Why I Oppose Pure Algorithm Interview Questions“, “How I Hire Programmers“, and “Further Discussion on ‘How I Hire Programmers’“. So I plucked up the courage to share my simple & naive views with you all. All kinds of brickbats are welcome.
Are Algorithm Problems Practical?
Algorithms are undoubtedly important, and a programmer who doesn’t understand algorithms will have a hard time writing efficient programs. However, in my humble opinion, the algorithms in algorithm problems are quite different from those used in academic research and engineering practice. Algorithm problems are like “brain teaser” style primary school Olympiad problems, if you have done similar problems, you know the solution routine, if you haven’t, it’s hard to come up with ideas in a short time. But real mathematical professional knowledge is far from primary school Olympiad problems.
For example, the maximum flow problem in computer competitions has stumped many people. This problem seems to come from reality. But how many research directions use maximum flow? Which product uses the maximum flow algorithm? Perhaps only some niche fields can use it, and at this time, the naive maximum flow algorithm is not enough, you still need to check the literature.
Coolshell has a more appropriate example, let me quote it here. “Find the second largest number in an array”, this problem obviously has an O(n) solution from a pure algorithm perspective, but an experienced engineer is more likely to sort the array and then take the second one. Because in actual products, there are few situations where you only need to find it once. Instead of O(n) for each search, it’s better to sort it in O(nlogn), maintain the ordered data structure in O(logn) when inserting and deleting elements, and finding the second largest number is O(1). This kind of data structure doesn’t even need to be coded by yourself, you can just use a library. More importantly, future requirements may not be to find the second largest but the fourth largest, can this “find the second largest number” code be reused?
What this example wants to illustrate is that in engineering, few people use fancy but complex algorithms, they are usually simple and just works. If all the employees of a company are racking their brains to design “low asymptotic complexity” algorithms in their products, the engineers may feel very challenged and fulfilled every day, but whether the code is maintainable is not certain, and there may be a fatal bug one day.
Is a Good Programmer One Who Can’t Solve Algorithm Problems?
Of course, algorithm problems are not useless, they are like primary school Olympiad problems, they serve as “mental gymnastics”. Statistically speaking, compared with those who have not studied Olympiad, those who have practiced OI/ACM do have a lot of differences in thinking and problem-solving. That is to say, those who can quickly and accurately solve algorithm problems are definitely good programmers. However, there are many types of “mental gymnastics”, and any type of exercise can strengthen the body. We cannot arbitrarily assert that those who have not practiced OI/ACM are not good programmers. In fact, most of the young engineers who have made important contributions in the field of computer science had OI/ACM in their school days, but they did not participate.
Computer science in university is not just about learning algorithms, there are many other important contents, such as computer architecture, operating systems, compiler principles, computer networks. A person who doesn’t understand the maximum flow algorithm can completely master programming language design, and a person who can’t write a compiler can completely master various OJs (Online Judge). There are also some undergraduates from EE and Mathematics departments, they don’t even understand what linked lists and trees are, but they have already published papers at top conferences in the field of computer science. How can people who don’t understand data structures organize and process so much data?
The reason is that today’s programming languages are becoming more advanced, libraries are becoming richer, and computing resources are becoming cheaper. They may not know that Python’s dictionary uses an O(1) hash table, they may not know that the sort in C++ STL is O(nlogn), they may not know how SQL queries can get results without scanning the whole table, they may not know how many sheets of paper would be printed out if the call stack of Hadoop was printed out… But they stand on the shoulders of predecessors, even if they waste some computing resources, they can still produce brilliant results.
Here is the point. Everyone has their own technical field of expertise. A good interview should fully showcase each person’s technical field of expertise, rather than measuring everyone with the “algorithm problem” ruler.
Another Form of Exam-oriented Education
Using pure algorithm problems to assess fresh graduates has another major drawback: the danger of turning university computer education into exam-oriented education. All students who aspire to be programmers practice these problems. Those who practice more and do better get the offer. If so, most professional courses are no longer important, software project practice is no longer important, and learning communication skills is no longer important.
Interviewer? Examiner?
The reason why algorithm problems are so prevalent, in addition to being simple to judge and having a high “recognition rate”, is also related to the “examiner” mentality of the interviewer. Two years ago, when I was interviewing for the student union’s technical department of the juvenile class, I had this condescending “examiner” mentality. On the surface, I wanted to recruit people with good technical foundations who could “get to work” as soon as they arrived, but in my heart, there was actually a voice: Look at you freshmen, you’ve never heard of XXX! Therefore, the “interview questions” I came up with at that time seem ridiculous now: (The following pictures show some of the questions)
After the interview, I was “very satisfied”, actually satisfying my little vanity. I forgot that those who came to the interview were all freshmen, they were not here to apply for a job, how could they possibly have the same abilities as me? Moreover, most of these so-called “abilities” were actually developed in the technical department during the first year, just a year’s difference in experience, what’s so great about that?
Later, when I chatted with my colleagues in the technical department, I gradually realized that everyone has unique experiences and skills, and many of the things they did during their middle school years were very surprising to me. Why didn’t they mention it during the interview? It must have been my “questions” that scared them, feeling that “once you enter the juvenile academy, it’s as deep as the sea, and from then on, the second is the passer-by”, so they didn’t dare to talk about their unique experiences and skills.
Algorithm problems are very suitable for interviewers to play the “examiner” tune: I already know the answer, waiting for you to make mistakes, I watch the joke. After a few people have been interviewed, the interviewer will feel much smarter than those who come to the interview. Therefore, to avoid pure algorithm problems becoming the only standard, the first step is to put down the “examiner” frame. The purpose of the interview is to find future collaborators, not to validate one’s intellectual superiority.
Let the Interviewee Lead the Interview Process
Joel said in his famous work Smart and Get Things Done that whether the interview passes should depend on whether you are willing to work with the person in front of you. Even if a person is technically strong, if you are not willing to work with the person in front of you, you should not pass him, rather than thinking “let him pass, maybe other groups will like this person”.
Based on this, one solution I envision is to let the interviewee lead the interview process. The interviewee imagines this hour as a time to persuade a client, and the task is to persuade the interviewer to work with him/her. If you have strong algorithm skills, you can choose to answer algorithm questions; if you have rich project experience, you can discuss past projects, write a few lines of related code; if you have deep academic accomplishments, you can discuss past research topics. No matter what form, you have to prove your ability to the interviewer within an hour. The interviewer is not just a spectator, if the interviewee cannot fully prove his/her programming ability, he/she can be asked to write a few lines of code, the question can be related to the technical field that the interviewee is interested in. This is completely different from giving a randomly drawn “algorithm problem” at the beginning.
The reason for proposing such a bold “reform plan” is because I have experienced this type of interview: (For details, see my “MSRA Interview Summary“)
- The interview started with self-introduction, and the interviewer was looking through my resume.
- Because I wrote some interesting projects in my resume, the interviewer asked a lot of technical details, and I also had the opportunity to talk about the development experience, technical challenges and insights of these projects.
- The interviewer asked me which professional course I learned best. Here is to give the choice to the interviewee, let the interviewee show their best side.
- Because the answer at the time was the operating system, the interviewer asked me to explain the memory management mechanism. At that time, I said that I didn’t understand the one on Windows, and the interviewer said to talk about the one on Linux, talk about what you know. If the interviewer uses the “algorithm problem” mode and asks me to explain the memory management mechanism on Windows, the consequences can be imagined.
- In order to verify my coding ability, I was asked to write a small program related to the operating system and architecture. If this is considered an “algorithm problem”, it is more targeted than problems like “merge two ordered sequences and find the Kth largest number”.
- The interviewer introduced his research direction and asked me about my views on reading for a doctorate. This can be considered a “two-way interview” process, which also makes the interviewee feel enough respect.
After a round of interviews, not only did I feel that my abilities were fully utilized, but I also felt respected. Excellent companies and excellent engineers are a two-way choice, and the cold algorithm problems will make the interviewee feel that this company is also cold.
Not One Less
Although it is idealized, I hope that an excellent company should not miss any excellent engineer who comes to apply.
We see that most of the advanced algorithms in algorithm problems cannot be directly applied to research or products, and those who cannot solve algorithm problems may not be bad programmers. Nowadays, programming languages are getting higher and higher, libraries are getting richer and richer, and computing resources are getting cheaper and cheaper. Engineers may not be meticulous about performance issues, but are devoted to their own interesting niche areas.
Therefore, I hope not to use algorithm problems as the only standard to test programmers, try to give more interview process to the interviewee, guide him/her to fully show personality and style. Change a mood, maybe we can appreciate different scenery.