At a recent tech community event, during a discussion on “what’s more important, depth or breadth of technology in a CTO?” I was reminded of the “full stack engineer” that is often mentioned in the community and expressed some opinions. I may not be able to express myself clearly on the spot, so I write in the hope of sparking some discussion and preventing young engineers from going astray.
“Full-stack engineer” has long been talked about in the community, and some companies simply post jobs called “full-stack Engineer.” What is a full stack engineer?
Full Stack engineer, called Full Stack Developer in English, refers to a person who has mastered a variety of skills and can use a variety of skills to independently complete the product. To put it plainly, it is the man who knows everything. The left green dragon and the right white tiger and the old cow are in the waist. Think about how much technology is involved in a project from front to back? Take TalkingData for example, there are at least H5, JavaScript, CSS, Java, Kafka, MongoDB, Redis, MySQL/MariaDB, Vertica, Hadoop, Spark, Tychron, etc. These research and development currently requires the data visualization team, computing platform team, storage platform team, data mining team and operations team to complete. How much communication costs and salary costs would be saved if there was such an almighty king who could do all the work? This is a savior!
Thought of here, I feel ashamed of myself, more than 10 years of technology is one of the white get, if just graduated as a goal, namely learn a each month, learned a door in a door, that in less than two years to make the ultimate “full stack engineer” profession, site technical peak, overlooking the sentient beings, having a game for the hanging of pleasure? Considering that it takes four or five years of hard work to be an architect, isn’t it cool to be able to do it in two or three years?
Finally, in such self-hypnosis, with the deliberate guidance of some public opinion, a large number of aspiring young people began to walk on the road of self-cultivation of engineers in the whole stack. Not many people want to accumulate their own technical experience, or dive into the underlying code of open source technology, or do more in-depth performance comparison analysis. A lot of people jump from company to company at lightning speed, looking at things in a quick, feverish way.
In recent years, due to the continuous maturity of big data demand and the continuous development of data business, TalkingData RESEARCH and development team has maintained a high density of recruitment, and we feel this phenomenon is quite obvious. Because what we’re seeing more and more in interviews is that young people are writing more and more diverse resumes that are “proficient”, “good at”, varying amounts of “years of experience” or “long experience”… Two years of work experience is longer than a resume for 10 years, and it’s almost a modern technology tour. Don’t be too strong! Just look at the resume and want to hire quickly, and then open the current “dead body meal” non-full stack staff, the world must be clean, right?
But are things really that good?
During the interview, we will test candidates’ depth of technical thinking, understanding, learning and problem solving skills through questions and answers. Therefore, interviews for R&D personnel generally follow the following procedures:
1. Introduce your background and professional experience.
2. Choose a project that you are most familiar with or good at, and describe in detail the overall structure and the work you did.
3. Discuss the challenges you faced and how you resolved them.
4. From this stage on, we continue to challenge and ask “why?” until we pass or fail to answer.
At each step of the process, a large number of candidates fail. Typical failures include:
1. Job hopping
The most common reason given was “I want to learn something new”. Wanting to learn something new is admirable, but I can hardly imagine that normal people can master a new skill in such a short time. Especially open source technology, it is basically easy to get started but difficult to master. It is easy to find some tutorial 101, which helps you learn to install and deploy in 5 minutes. But once you use the production system, it is easy to have all kinds of sudden problems. Configuration, architecture, networking, code, and maybe even hardware – forcing you to go to various forums and search for solutions. Experience comes from filling holes. They can only be installed and deployed, but they are far from being truly mastered.
The most dramatic has seen six companies in two years. Therefore, as soon as you see the resume of the last three work experience is not more than two years, directly skip.
2. Lack of sense of architecture
Not to mention the necessary curiosity or logic of a technician (especially a big data technician), only a clear understanding of the overall architecture can more accurately understand the meaning of the requirements to be realized on the whole business line, so as to have a relatively reasonable judgment on the definition of functional boundaries and technology selection. If they are not familiar with the overall structure of the project or the description is not clear, we believe that such researchers lack a sense of the whole and the overall view, and their growth will be limited.
In fact, there are many people who can’t draw the technical architecture diagram of the whole product line, and there are many who can draw it but are confused about each module.
3. Technology floats on the surface
When it comes to challenges, it’s easy to see the depth of a candidate’s technical mastery. If you can’t name a challenge, it’s either a bull that no technology can stop, or you haven’t experienced the battle of computing bottlenecks, data silting, disk overcrowding, low memory, and architecture tuning. Interviewers have to be careful with the latter, because no matter how many techniques and frameworks they use, they can create more holes for you than they fill.
A memorable example came from a candidate whose resume was full of claims that he was good at all sorts of big data technologies, and when asked in the interview to pick a project he was best at to talk about in depth, he said, Uh… This… Let’s talk about a website project I worked on, where I worked on a Web front end… I was speechless.
4. The details can’t resist the challenge
Why did you choose this plan? What are the advantages compared with other schemes? What’s wrong with this plan? If you were asked to develop a new version of this solution, what kind of optimization would you make and why? If the amount of data increases by an order of magnitude, do you think there will be a bottleneck in this scheme? An order of magnitude larger? BlaBlaBla… These are routine problems, if you are not familiar with the technology and research to a certain degree, it is difficult to explain clearly.
Once I met a boorish young man, who just graduated and worked for a year, asked his relatives to invest and start a business as A CTO. After a year of floundering, his company was turned down and then he came out to find a job. The salary for the first year was normal. When I worked as CTO, I doubled my salary and then expected us to increase it by 50%. That is to say, after this year’s entrepreneurial process, he felt that he became a CTO, contacted a lot of technologies, and increased his value. “I can do everything”, which should be three times higher than the first year. In fact, every technology is so general that it fails without details.
In his book Outliers, Gladwell points out that “what makes a genius extraordinary is not that he is superior in talent, but that he has made continuous efforts. 10,000 hours of exercise is necessary for anyone to go from ordinary to extraordinary.” He calls this the “10,000-hour rule.”
It takes at least 10,000 hours to become an expert in a field. If you work eight hours a day, five days a week, it takes at least five years to become an expert in a field. Even if you keep working on 996, it takes about three years. This is consistent with the cognition of any experienced technical personnel: a technology, without more than two or three years of familiarity and research, is far from being proficient. In particular, the big data industry is a relatively new industry, and many technologies and methods are in the exploratory stage, requiring more time to accumulate. TalkingData has also been struggling with massive data and various big data technologies for more than four years, wending through numerous minefields. Only today can we say that we have accumulated some knowledge and cultivated a group of experienced technical experts in the field of big data. Even so, we never consider ourselves “full stack engineers” in our r&d team.
The big data industry must rely on experience and accumulation, there is no quick-fix approach, so we always control the R&D team can be more focused rather than more divergent, do deeper rather than broader.
Then again, is there a full stack engineer? There has to be. However, most of the engineers I have met who can be called “full stack” have written a lot of code or solved a lot of problems in a certain field. They have accumulated a very deep foundation of knowledge, and then they turn the knowledge into common sense, so that they can truly understand by analogy. At this point, it looks like “full stack”. But this is obviously not for inexperienced engineers.
Therefore, I hope young technicians can be more practical and do not believe in the beautiful myth of “full stack engineer”. Only lay a good technical foundation for themselves, in order to fly higher.
If you are interested in big data, passionate about big data technology, and curious about how to use data to solve problems in your daily life, welcome to join TalkingData big Data R&D team. We have enough data and technology to challenge your limits, and you won’t be disappointed!
Note: if you are interested, please send your resume to [email protected].
