During the interview, I will ask the interviewer, how do you build your own knowledge system on a daily basis, and how do you make yourself higher, faster and stronger? Most engineers have not thought deeply about this issue, and they are basically piecemeal and random.
In the spirit of not letting you come here in vain, I, who like to be a teacher, will tell the story:
The first stage conscientiously builds a complete knowledge system
When I joined the software industry more than ten years ago, I just piled up the original English books that explained the basic knowledge of database principles, operating systems, TCP/IP, networking, algorithms, etc. Practice, after entering the industry, read all kinds of classic works of C++, read the original text of various protocols, and lay the foundation seriously.
Many engineers say that they usually read recommended blog posts or news on some IT portals. I say that this is typical piecemeal and not exciting enough.
At this point, I will give an example of why you should read novels, because short and medium stories are like sticking you with a needle,
and novels are like hanging you in a sandbag and hitting you with a mace from all directions. You, hearty
. To build a usable knowledge system, you have to read. The book has a system structure. You care about it or not. At this stage, you can't use
it
.
What is a body of knowledge?
A few years ago, Yao Jiandong, the former Alipay architect, once gave a sharing lecture on how technical personnel plan themselves in our company. He discussed this:
Techniques and techniques include:
- computer basic theory
- Computer Model: Memory/IO/Clock/CPU…
- algorithm
- Special technical fields:
- data mining
- data management
- Intelligent Recommendation
- search
- ……
- language and tools
- Language and Related Systems
- Development tools, analysis tools, code management tools
- HTML/CSS/JS/Ajax
- Common frameworks and third-party class libraries
- Debug and Test
- Debug Method and Philosophy
- positioning problem
- BUG management tool
- unit test
- Integration Testing
- Performance Testing
- Safety test
- Compatibility Testing and Methods
- JS/Ajax tests and methods
- Service Layer Testing
- Web Tier Testing
- Networks and Systems
- TCP/IP protocols and models, HTTP/SMTP and other protocols
- Linux system, network analysis tool, system analysis tool
- Capacity, Traffic and Load Balancing
- Application deployment, specification, planning
- Safety
- Monitoring and Failure Analysis
- Disk and Storage
- Shell
- DNS and Domain Names
- cache, reverse proxy
- Image server (mass of small files)
- Requirements mining and analysis
- Requirements document format
- needs interview
- needs analysis method, needs analysis tool
- Domain knowledge and experience
- System Analysis and Design
- UML language and models
- Analysis mode
- Design Patterns, Domain Driven
- System Analysis Document Format
- System Design Document Format
- Functional and non-functional requirements
- Data and Systems
- database
- Scalable strategy, expansion strategy, backup, disaster recovery, performance, security, high availability...
- Data Design and Paradigm, SQL/NoSQL, Cache, Distributed File
- Architecture design
- Architecture mode, the evolution history of typical Internet company architecture
- Architecture principles, common strategies
- Architecture Design Method
- non-functional understanding
- Extensibility
- Scalability
- stability
- consistency
- performance
- Throughput
- Capacity forecasting and planning
- Architecture system and related technologies
- Process and Management
- Analysis process
- R & D process
- Review process
- Testing process
- release process
- rollback process
- document management
- knowledge management
- project management
The above is actually a list of basic knowledge for practitioners. You can follow the map and read related books.
In the second stage, follow a topic to drill in and exercise your pre-research ability
Regardless of the company's business or what you like to do, you can abstract general topics, and then go into it as a thesis. This thing has to be practiced repeatedly and consciously.
The way of doing things is:
- Abstract topic - such as distributed lock, distributed parallel computing engine, CSRF-proof FormToken automatic generation framework, timed task management and scheduling platform, distributed tracking, etc.
- Learn from students who have done well in their homework - targeted in-depth understanding of how other companies in the industry analyze and solve problems, put together various solutions, and stand on the shoulders of giants
- Analysis of specific application scenarios, technology selection
- Take into account high availability and scalability, do design review
- Do tests to prove yourself reliable, sort out knowledge points, and hold technical sharing sessions
- On-line commercial use, summarizing experience and lessons, and holding experience sharing meetings
One focus is on aggregating and sharing. In 2005, in response to the needs of the carrier-class unified messaging service, I went to study the SIP protocol, did various experiments, analyzed the packets, wrote a series of slides, and shared them publicly, which was very popular for a while:
- SIP_to_Freshman_by_zhengyun.ppt
- SIP Traversal NAT_by_zhengyun.ppt
- SIP Architecture Lecture Notes and Message Interaction Demonstration_by_zhengyun.ppt
- Example explanation of SIP multi-party session message_by_zhengyun.ppt
- Authentication of SIP Security Framework [NTLM and Kerberos]_by_zhengyun.ppt
- Item-by-item explanation of SIP messages_by_zhengyun.ppt
Why write and speak?
Because there is a learning pyramid theory as shown below:
What we read can remember 10% of the learning content,
We remember 20% of what we hear,
We can remember 30% of what we have seen,
We can remember 50% of the things we have heard and seen - such as watching videos / watching exhibitions / watching demos / live viewings,
We remember 70% of what we said - such as participating in discussions/speaking,
We remember 90% of the things we said and did - like giving a presentation, telling others, experiencing it, doing it.
This is also the management method I explained in "What Wowo R&D has done right in the past few years": we consciously train everyone after joining the company, so that everyone can speak publicly and clearly. Therefore, during the trial period, newcomers must do a technical sharing and a technical review, and face challenges from all parties; there must be a sharing session in the middle and end of the pre-research; usually, technical lectures should be organized regularly.
Stage 3 Crazy Answers to Technical Questions
The knowledge system is slowly built, and abstract topics related to business are also being explored.
But that's not enough.
Because the world you are exposed to personally is too small to be a challenge, and you may not realize how much knowledge and skills you lack, it is not conducive to your ability to analyze, ask, and solve problems.
So, be proactive:
Crazy to answer questions
.
I used to answer almost every question in the verticals (including language and business) that I focused on in the first few years of my career. I spread my knowledge to the outside world, and I gave out my email address and MSN (MSN was very high at that time), and many netizens would send emails or add me as friends to ask various development problems. The problem-solving process is written in Microsoft KB (KnowledgeBase) style and published on my blog.
Think about it, you can only encounter one problem every few days on average, and doing so, you will encounter several or even a dozen every day. First, it will make you brainstorm, and second, you will be exposed to more new knowledge.
From 2005 to 2006, I learned JavaME (or J2ME as it was called) for work, and client development on Symbian phones in the early years. During that time, I scanned Chinese forum posts every day, trying to answer all questions, especially those bugs or glitches. For those that have not been solved for the time being, such as streaming media real-time playback, such as the secondary menu interface imitating OperaMini, they all searched up and down, and finally released the ideas and source code.
At the same time, I often organize frequently asked questions, organize them into volumes and publish them. For example, the J2ME problems I have sorted out:
- [J2ME Q&A] Explanation of the error reported by the real machine MontyThread -n
- [J2MEQ&A] WTK initialization WMAClient error XXX has no IP address explanation
- [J2ME Q&A] untrusted domain is not configured question response
- [J2ME] "Cannot open socket for LIME events" error resolved
A few months later, I became the super moderator of the J2ME Chinese Forum. Through this process, I would like to tell you that when answering questions from netizens, if you have the right skills, such as don’t keep answering novice questions repeatedly, try to overcome those difficult problems or bizarre failures, you will never waste your time.
Why?
Because you are to believe in:
Everything you learn, every hardship you suffer, will come in handy at some point in your life.--Penelope Fitzgerald, "Offshore"Everything that you've learnt and all the hardships you've suffered will all come in handy at some point in your life.
Phase IV RCA/Summary
Now is your time to turn lessons learned into wealth.
What is a good technical leader?
When you talk about any business requirement or business scenario, you immediately abstract it into several modules/systems/topics, and then talk about how the industry solves it, how we analyzed and solved it in the past, and now we have this How should the situation be designed, what problems may be encountered, and what precautionary designs should we do, blabla.
How to do this?
First, write the RCA report.
I said before, "Since 2011, Wowo has insisted that every mistake must be checked, rectified when wrong, and every mistake must be written, and every new employee should be told to face the mistake, disclose the technical details, and share it with everyone. , in the long run, every accident and online missed test will become our wealth. This is our RCA (Root Cause Analysis) system. Up to now, nearly 200 detailed RCA reports have been collected. 』
The RCA report format is:
- Background knowledge (Optional)
- problem phenomenon
- Sphere of influence
- problem causes
- Problem Analysis Process (Optional)
- Solution
- Follow-up measures: such as how to repair online dirty data, such as how to make up for the impact on users, etc. (Optional)
- lessons learned
- RCA types: such as code issues, implementation issues, configuration issues, design issues, test issues
Second, write a summary.
In other words, always pull the list.
You can talk and have information. You have to write them yourself to make a deep impression and remember them at critical moments.
Well, this is what I tell the interviewee to become a master of the four stages.
Click the link to see
what
a technical director does.