Weekend Benefit - Discussing my view on Java learning and interviewing #

Hello, I’m Yang Xiaofeng. Today is the weekend, so let’s take a break and talk about something other than “Java Core Technology”. It’s also a good opportunity to fulfill the promise of giving out learning reward vouchers. I have left a reflection question at the end of each lesson, hoping that through learning and combining with your own work experience, you can seriously think about these questions. On one hand, it serves as a test of your learning effectiveness, and on the other hand, it helps you fill in any gaps and think about interview points that are often overlooked. I haven’t provided the answers to these questions. I hope you can think independently by studying this column or referring to other materials and write your own answers in the comments section to exchange ideas with me and other students. This is also one of the important ways to improve yourself.

Up until today, 15 lessons have been published in this column, covering the basic module and entering the advanced module. Now is a good time to pause and review the knowledge of the basic part, in order to lay a solid foundation for the subsequent concurrent content. Here, I would also like to share my thoughts on Java learning and interviews, hoping to be helpful to you.

First, some students have feedback that they don’t understand some of the content in this column. When preparing the articles for this column, I found that some students may not have accurate grasp of the basics. I made adjustments in the following articles by explaining key technical concepts and adding links to other terminology.

Now let’s talk about this situation, some people always think that they have already learned everything about Java basics, so what else is there to learn?

When it comes to mastering the basics, some students often have a superficial understanding, thinking that they have grasped the concepts just by hearing a few terms. This is not the case. At the very least, I believe that you should be able to express what you “master” accurately.

Albert Einstein once said, “If you can’t explain it simply, you don’t understand it well enough.” Understanding - Mastery - Proficiency, this is a progressive process of mastering things. From feeling like you understand it, to being able to explain it clearly, and then being able to apply it naturally, even drawing connections to other concepts, this is an ongoing process of improvement.

In the process of learning this column, if some terms seem unfamiliar to you, then understanding them has achieved the learning goal. If you can thoroughly understand them and reach the level of mastery, that’s even better. Optimistically speaking, there is always something to gain, so there’s no need to worry excessively.

From the perspective of learning techniques, everyone has their own habits. Personally, I like to practice hands-on and communicate with others.

• Hands-on practice is a necessary step. If you are not willing to get your hands dirty, you will find it difficult to have a deep understanding.
• In the process of communication, you will find that many seemingly false understandings suddenly become clear when you try to organize your thoughts into words, and other people’s perspectives also validate your judgments. This is especially true in the technical field. Organizing your understanding into words, outputting and communicating it is a very effective method for improvement. I even think this is a path that technical workers must go through to grow.

Let’s talk about whether it is necessary to read the source code for the underlying technologies.

Reading source code is definitely a good habit. Understanding high-quality code is crucial for improving our analysis, design, and other abilities.

• According to practical statistics, the time spent reading code in actual work as an engineer is actually much longer than the time spent writing code. This means that reading and summarizing abilities directly affect our work efficiency! Is there a shortcut? Maybe there is. My experience is that “there is no alternative, only practice makes perfect.”
• Referring to others’ architectures, implementations, and analyzing the pitfalls they encountered in history, these are naturally good materials. When reading, you can start from the perspective of the problems they have solved.
• In modern software engineering, the pace is getting faster, and the requirements are becoming more complex and volatile, highlighting the importance of the “white box” approach. Often, fast problem localization requires a combination of black box and white box capabilities. Without any knowledge of the internal workings, you may have no direction. At the same time, general platforms and open-source frameworks may not be very suitable for your own business needs. Often, customizations or self-development at the source code level are needed to achieve them. I think this is also one of the reasons why the status of software engineers is constantly improving.

So, to what extent should we understand the source code?

This is indeed a controversial question when it comes to underlying technologies. Personally, I don’t think that everything needs to be understood at the lowest level. It’s good to understand it, but it doesn’t represent everything. After all, knowledge and abilities are different, and we should also respect the requirements of the interviewer. Personally, I believe that not everyone who does Java development needs to read the JVM source code. Although I provided some interpretation of the underlying source code in this column, I only hope that engineers who are truly interested and in need will follow up and learn. For most developers, understanding some source code, at least not being completely unprepared when asked during an interview, is sufficient.

Regarding reading source code and understanding the underlying technology, I have some suggestions:

• Read with questions and clear goals in mind, for example, from the perspective of debugging a specific problem, combine it with practice to verify that it is helpful and make yourself feel rewarded, deepening your understanding and practical abilities

• It is important to have output, at least write it down, organize your thoughts, communicate, verify, and improve. This is similar to our daily work. Do not spend a long time and then tell your leader that there are no conclusions.

Most of us are engineers, not scientists. In software development, it is important to distinguish between appearance, behavior, and specification. It’s good to like source code and the underlying details, but it’s important to differentiate between implementation details and specified promises. Because if our program relies on appearance, it may cause maintenance problems in the future.

I mentioned earlier the importance of the white-box approach, but careful consideration is needed when depending on internal dependencies, to distinguish between hacks and solutions. If we solve the problem using a hack, it may work temporarily, but it will accumulate and become a barrier for upgrades, and even escalate. For example, when I was experimenting with Cassandra, I found that it used Unsafe.monitorEnter()/monitorExit() in the concurrency part, which caused it to not smoothly run on the new version of JDK because the corresponding internal APIs have been removed. Fortunately, there were public APIs that could replace it.

Finally, let’s talk about the qualities and abilities that I look for in candidates during interviews.

Based on my personal experience in actual work, there are several aspects in interviews that I particularly care about:

• Good technical literacy and the ability to think deeply, without talking superficially. That’s why I like to ask about the area in which the candidate is most proficient. If one cannot think carefully in their area of expertise, how can we ensure that they will diligently research in their next job? Of course, this kind of thinking does not mean focusing on low-level details; being able to understand the engineering significance behind ordinary things in business is also commendable. After all, except for special positions, most tasks can be handled as long as there is good technical literacy, enthusiasm for work, and a certain amount of experience.

• Professionalism and the ability to approach every task seriously. We are professionals in the workplace, not children being cared for in a kindergarten. If someone is too picky about the tasks they do, the team often cannot achieve basic fairness. Experienced managers mostly focus their management energy on positive team building, rather than wasting energy on people who hinder the team’s progress. No one likes people who are difficult to collaborate with. Someone once said that the height of your profession depends on your ability to “fill in the gaps,” and I think that makes sense. In real work, there are rarely ideal perfect tasks that are clear in goals and challenging, and happen to be what I am good at. Such tasks are rare. The ability to proactively find clarity from ambiguity and effectively solve problems is very important.

• Being hands-on and proactive. I generally do not require current needs to be very hands-on, but at least the candidate should show that they can be.

Below is the list of winners and selected comments. We are giving away 15 yuan study reward vouchers, hoping that my book “Java Core Technology 36 Lectures” can not only bring you into the Java interview scenes of large companies but also help you review and build your Java knowledge system. You are also welcome to communicate with me here about interview or learning difficulties and experiences, so that we can freely express our opinions and make progress together.

‍