Is working experience really so important?

When I browse the recruiting information in the website, I always see the following requirements:”The candidate must have more than 3 years experience in C++ programming” or “The candidate must have more than 3 years experience in iOS development”. I would like to ask the recruiter:”Is working experience really so important?”

In my opinion, the working experience is not a good measurement to decide whether a candidate is fit or not, and use this rule just like using the lines of code to judge the program is good or bad. Frankly, the grammars of every programming languages are similar, and the important thing under the programming languages are the thinking: what is the essence of object-oriented thinking? why does this programming language introduce this feature? etc. These things can’t easily be judged by the years of working experience. If a man doesn’t think deeply of this work, even if he has worked more than 10 years, what’s so special about that?

4 years ago, I came to my current company. I didn’t have any working experience about my work, even hadn’t heard about SS7. But after a month, I found the SS7 protocol stack was very like TCP/IP: they both have routing functions, transport management, etc. After 3 months, I had worked smoothly and not weaker than other veterans. From this progress, I learned there are many commonness among the different knowledge, so long as the man can drill down the work, he can soon become a qualified engineer.

One day, a famous company want to find an engineer who had more than 5 years experience in C++ programming. After reading the information, I sent an email to the recruiter and told that although I hadn’t use C++ for many years, I can soon master it, and the most important thing is the man’s ability, not the number of age. Not surprisingly, the recruiter politely rejected me: “Sorry, sir. You don’t have the required related experience, so we can’t consider you ……”.

An Awful Project

A simple server program whose function is just receiving protocol packets from clients, then paring them, and inserting the paring results into database. Why is the implementation so complicated and awful?

(1) For every protocol message, the server need listen to a specified port. Now, there are only 5 protocols, how if we need support 100 or 10000 protocol? Do we need to listen 100 or 10000 ports? Yes, We can’t wait for that day. Because if we need support 10000 protocols, we have become Bill Gates.

(2) Every protocol message has a different header.

(3) A lot of copy-paste code, and this will cause so many duplicated code that if there is an error, you need find everywhere and fix it.

(4) A lot of dead code.

(5) Many functions are so long (more than 1000 lines) that I don’t know whether they can be maintained after 5 years.

(6) Depend on 32-bit/64-bit architecture.

(7) The client and server is coupled so closely that upgrading one program must consider the other.

I think we can use a unified header for every protocol and server only listen to one port. Every message arrives the server with the same header, so this can avoid many duplicated codes. What the server needs to do is use “switch … case” to parse every message according to the header. This can also decouple client-server programs.

A good architecture is the base of the house. If there is a serious defection in base, I am not sure whether the house can be stable.

Read Li Na’s autobiography

During this mid-autumn vacation, I read the Li Na’s autobiography (http://item.jd.com/11052054.html). Previously, I can only know Li Na from reports and news written by journalists, but from this book, I recognize a real Li Na.

She is also a common girl, and has the same feelings as other people. Below her success, She endures more pains and pressures than common people. We can give her more toleration and applauses rather than criticisms.

Good luck with you, Li Na!