In fact, most Java developers are indeed capable of daily development work, but many candidates are unable to impress the interviewer in the interview. Because you want to fully demonstrate your strengths in a short-term interview, it requires skills. Judging from the current status of most Java development interviews, there are not many candidates who will interview. Therefore, before starting to talk about the distributed component interview skills, first give out the common problems that most candidates will encounter. This requires everyone to take warning.
1 Many people only "add, delete, modify, and check"
For the primary development of Java, the usual main work is really just "addition, deletion, modification, and checking", that is, it is necessary to implement various addition, deletion, modification, and checking functions based on different business needs with technologies such as Java and database. For senior Java developers and even architects, in addition to advanced technical work such as "tuning", "component architecture design" and "troubleshooting" in daily work, development work such as "addition, deletion, modification, and investigation" is also required. It will account for a certain proportion, but in the interview, you can't make the interviewer feel that you don't have other skills besides "addition, deletion, modification, and investigation".
For example, when the author is interviewing candidates as a technical interviewer, he found that many people can really combine the requirements of the projects they have done before, showing the ability to achieve various business needs with technologies such as Spring and database, and they can indeed answer relevant questions. The technical realization of "addition, deletion, modification, and checking" business functions related issues, but when asked about the following other aspects, they will be helpless. Many candidates have not even heard of the relevant terminology.
• Questions about database performance tuning, for example, in the project, how do you optimize the performance of SQL statements using indexes and execution plans?
• Java virtual machine memory tuning problems, for example, in the project, please give an example of how you troubleshoot OOM problems? Or when you are developing business functions, what measures have you taken to improve the memory performance of the JVM (Java Virtual Machine)?
• High concurrency issues, for example, what is the maximum amount of concurrency your project can withstand? In the project, what distributed components have you used to cope with high concurrency requirements?
• Questions about database and distributed component clusters. For example, how do you use clusters (database or Dubbo or Redis) in your project to ensure high service availability?
• Questions about the integrated application of distributed components, for example, which distributed components have been used in your project? How are they integrated to cope with high concurrency requirements?
Since most of the current projects need to work in high-concurrency scenarios, correspondingly, in the interview, there is a great possibility of asking about the above-mentioned performance tuning, distributed clustering and other issues dealing with high concurrency. Therefore, if the candidate only demonstrates the skills of “addition, deletion, modification, and review” of projects in the interview, then they may only be able to apply for low-tech development jobs, such as assignments and outsourcing jobs.
In addition to accumulating business knowledge points for this type of work, I am afraid that there is still no opportunity to get in touch with advanced development skills such as distributed, and this type of business development work is too substitutable. Crisis".
2 Able to recite questions, but will not talk about skills in combination with projects
At present, there are many Java-related interview questions that can be searched on the Internet, such as algorithms, basic knowledge of Java Core, databases, and web development such as Spring Boot or Spring Cloud, and even There are also distributed components and cluster architectures. Many more attentive candidates will also make full preparations before the interview.
It is true that you need to recite questions before the interview, and some rhetoric about the underlying code and principle types can also help the candidate, but if you only review these questions, you may only be able to grasp the knowledge points at the theoretical level, and you cannot go further to the interview during the interview. The officer shows that you have used relevant skills in actual projects, and the interviewer is more interested in the latter.
Here is a case of an interview question. For example, the interviewer asks: "What is the difference between ArrayList and Vector in a Java collection?" If you have read the relevant interview questions, the candidate can generally say the following: "Vector is thread-safe and ArrayList is not thread-safe. At the same time, when expanding, Vector will expand by 100%, while ArrayList is 50%." At this level, the interviewer will think that the candidate knows these two objects,
but if the candidate People further gave the following rhetoric: "In the previous project, if I encountered a single-threaded working environment, I would use thread-unsafe objects such as ArrayList, and for the sake of improving memory performance, in the project I use ArrayList because of its low expansion ratio."
Although the above statement is only a few words, because it is integrated into the project, the interviewer will confirm that the candidate has actually used it in the project, but this "combined project" The ability to talk about technology may be generally lacking in candidates, especially candidates at the junior development level.
Perhaps in terms of Java core basic skills, the practice of "combining project experience and technology" is not very helpful to candidates, so in terms of distributed components, candidates who "can combine project and technology" and "can only recite questions" The difference between the candidates is enough to determine the success or failure of the interview. Take a look at the relevant interview case.
Another example is Redis, assuming that a candidate only understands the Redis data structure and underlying code and even the practice of building a cluster based on the online interview questions, then the interviewer only needs to use something like "How to use Redis in combination with the project" Questions can ask the candidate, but if another candidate can talk about the key points of project practice such as configuration, cached data details and anti-penetration in combination with the usage scenario, then he can effectively prove that he has used Redis in the project. . In fact, many candidates in interviews can only recite questions and talk about theories, so as long as the interviewer thinks that you have done it in the project, then you can be better than those who can only recite questions.
In terms of distributed components, this book will tell you the practical points of using distributed components in the project based on case studies. On the other hand, it will combine these practical points to organize relevant interview speeches for you, and will also give out on this basis " Redis anti-penetration", "Dubbo anti-timeout" and "Kafka anti-retransmission" and other highlight technology display methods, from which everyone can intuitively grasp the skills of preparing for the interview in terms of distributed components, and can successfully surpass in the interview. Most competitors.
3 At the linux level, there is a general lack of basic operating skills
It is true that most of the projects are developed on the windows operating system, so many candidates have not been exposed to other operating systems such as linux. According to the author’s technical interviewer’s experience, many candidates think that the developed project is deployed on the windows system, and the distributed components are installed on the windows system. For daily troubleshooting, you only need to observe the logs on the windows system. .
But the actual situation is not like this. Distributed components and even clusters are mostly deployed on the Linux system. The developed Spring Boot and other types of projects are also deployed and run on the Linux system. Therefore, the interviewer asked about Linux operations during the interview. The problem is by no means an embarrassing candidate.
You can imagine, if a candidate can't even find out how to find and open a file on Linux, and find key strings in the file, how can he prove that he really checked the problem in the project? Some interviewers will even think that candidates will only "developing additions, deletions, corrections, and checking" on the windows system.
In fact, even for primary development, it is not difficult to prepare for Linux interviews. You only need to prepare some basic file operation commands and some basic script operation skills. In other words, you only need to spend a little time to prepare linux rhetoric according to the steps given in the subsequent chapters of this book, so that the interviewer will have a refreshing feeling during the interview, not to mention the linux operation skills, the candidate They can also effectively demonstrate their ability to "analyze, troubleshoot, and solve problems".
4 The ability to troubleshoot and solve problems, many people will not show
You can imagine that interviewers most hope that candidates have project development experience in related technologies, so if candidates can effectively prove that they have experience in troubleshooting and solving online problems in previous projects, that is definitely a bonus.
However, during the interview process, many candidates just passively answer questions and will not actively expand beyond that. In this way, if you encounter interviewers who are not good at digging out the bright spots of candidates, then these candidates who passively answer questions will not have the opportunity to show such bonus points.
When discussing distributed components such as Redis, Dubbo, and Netty later, the author will give tips and rhetoric for "investigating and solving actual online problems" for the corresponding components. Here, I will first give the general steps to show the experience of such bonus items.
First, let's talk about the corresponding online failure, such as a certain system is unavailable, or the system output is different from what was expected, or an error log is found in the log file.
Second, let's talk about the process of locating the problem based on the error log, such as which log of Redis finds that Redis has a timeout problem.
Third, let's talk about the causal relationship between errors and failures seen through the log. For example, because Redis times out, the return time becomes longer, which leads to unavailability of the service.
Fourth, let's finally talk about how to solve it, such as reducing the Redis timeout time in the configuration file accordingly.
In this way, candidates can effectively demonstrate relevant skills and project practical experience in the interview. And please pay attention to this kind of "troubleshooting and problem solving" related rhetoric, you will not say too much in the interview, so before the interview, the candidate can focus on "tuning", "highly concurrent distributed applications" and "Distributed clusters" and many other valuable technologies, prepare as many rhetoric as possible.
5 Answering questions passively, lacking the awareness of actively guiding and throwing bright spots
As mentioned earlier, many candidates will only passively answer questions during the interview, so that they give up the right to ask questions in the interview. If the interviewer asks questions that the candidate is not familiar with, then the result of the interview can be imagined. And know.
But in fact, as long as you have answered the relevant questions and said a few more words, it is possible to guide the interviewer’s questions to the various highlights that you have prepared. In fact, you will learn this kind of "guidance" skills as soon as you learn, and this book will give more guidance on this kind of guidance in the subsequent chapters on specific distributed components. Here are some examples, please experience this kind of Guided practices and possible benefits.
For example, after you have answered the question about the Connection component in JDBC, say one more sentence, "In our project, in addition to using JDBC to connect to the database, Redis cache is also used to improve database performance", so the interviewer is very likely Continue to ask Redis related questions, so that you have the opportunity to show the highlights of the Redis cluster and anti-penetration prepared before the interview.
Another example is that after you have answered the question about Redis penetration prevention, you can say one more sentence, "In the previous project, we also solved the online problem of Redis penetration prevention." When the interviewer asked in detail, You can continue to say, “I found the Redis penetration problem through the log. The reason is that the empty data and non-existent data are not cached in Redis, and this type of data is cached later.” That is to say, the interviewer was successfully treated here. The problem led to the "solving actual online problems" and successfully demonstrated the actual project experience in Redis and the ability to troubleshoot problems.
In fact, many interviewers are still working hard to fix bugs or participate in various meetings before the interview, that is, they scan the candidate's resume before the interview, and they are not good at preparing interview questions. Many of the questions are in the interview. I thought about it temporarily. So when the candidate throws out this kind of "guidance" remarks in the interview, the interviewer is likely to continue to ask questions along this topic. In this way, the candidate can guide the questions as much as possible during the interview as they have prepared. In the range.
6 The difficulty of preparing for an interview is lower than the difficulty of doing a good job
What is a good project? It is necessary to ensure that there are no various bugs in the project, and to successfully deploy the project online, and effectively fix various problems encountered when the project is running online. How can I pass the interview? Just answer the interviewer’s key questions.
The type and number of problems encountered in the project are unpredictable, and most of the questions asked by the interviewer are routine, and the development project cycle is at least a few months, and the technical interview lasts at most one hour, so be prepared The difficulty of the interview is lower than the difficulty of doing a good job.
General interviews are divided into three rounds: technical interviews, project manager interviews, and personnel interviews. This book will focus more on technical interviews. A technical interview is generally 20 to 30 minutes, and it is generally not more than an hour long. The specific process is generally as follows.
1. After the greeting, the candidates will be asked to introduce basic information such as academic qualifications and the company they have worked for. You can prepare for these remarks before the interview.
2. Later, the candidate will be asked to introduce the most recent (or the best available) project situation. At this time, the candidate can use the methods given in this book, according to the preparation before the interview, combined with the actual project to throw out various highlights. And can guide the subsequent interviewer's questions to the prepared range, that is to say, the introduction of the project can also be prepared.
3. After introducing the project, the interviewer will generally ask questions freely. It is said that it is free to ask questions, but it will also ask questions around the technical points mentioned in the job introduction. If you are recruiting Java programmers, the distributed component aspect is also an assessment point. At this time, if the candidate can use the guidance techniques mentioned above, he can control the interviewer's questions as much as possible within his familiar range.
4. The interviewer may ask questions about data structures and algorithms, but such questions can also be prepared by brushing the questions.
5. In the end, the interviewer will ask the candidate to ask questions. You can also prepare for this session. The candidate can also take the opportunity to throw out highlights that he didn't have the opportunity to show before.
You can see that doing a good project and preparing for a technical interview are two different dimensions. The former is hands-on and the latter is talking. And if you prepare well before the interview, you can definitely throw out a variety of highlights in conjunction with the project during the interview, or you can show your knowledge of a certain technology by "writing (details) and drawing (block diagrams, flowcharts, etc.) while talking". Understand, you can even guide the interviewer's questions by "answer a good question and say one more sentence". In other words, by preparing for the interview and introducing various skills in the interview, candidates can not only show their highlights to the greatest extent, but also effectively prevent the interviewer from asking too much about their weaknesses, so that they can effectively improve the pass Possibility of technical interviews.
7 Wrong and correct ways to prepare for an interview
As mentioned above, the difficulty of preparing for the interview is lower than the difficulty of doing the project. In fact, many candidates fail to pass the interview because they are not prepared in advance or the preparation method is improper. Some of them may be in the project team. This is the reason why many candidates perform poorly in interviews.
In fact, the reason was also mentioned in the previous article: preparing for an interview and doing a good project are two dimensions. Before giving the correct preparation method for the interview, let's take a comparative look at some wrong preparation methods.
1. Prepare for the interview only based on the techniques used in the previous project. Since programmers’ daily development work is mostly "addition, deletion, modification, and investigation", the valuable technology they are exposed to is very limited. This alone cannot keep the distance from other competitors. Therefore, even if the final interview is successful, the ability and salary may be affected. underestimate.
2. Too many algorithm questions or programming questions or related interview questions. It is important to know that the interviewer will definitely assess the candidate's project practice ability in related technologies. If you prepare in this way, you may have the opportunity to interview for a junior development position, but it may be difficult to apply for a senior development position.
3. Memorize some rhetoric (in terms of distributed components, etc.) only at the theoretical level. For these valuable rhetoric, the interviewer will most likely ask about technical implementation details and troubleshooting steps. If you rely solely on theoretical rhetoric, you cannot effectively prove that you have used these valuable skills in your project.
Correspondingly, the correct interview preparation method is ready. The method given here not only covers distributed components, but is more suitable for preparing for other Java interviews.
1. Necessary work such as brushing questions cannot be pulled down, because related questions may also be asked in the interview, and at the same time, the rhetoric of showing basic skills in combination with the project must also be prepared.
2. Combining the projects you have done, prepare as many valuable technical highlights as possible. For example, if you can combine the risk control module business developed before, you can tell the Dubbo remote call process, which is better than if you simply speak from a theoretical perspective. Much better. It is best to find similar valuable technologies and find a point of integration with the project.
3. It is not only necessary to prepare the highlights of the project in combination with the project, but also to prepare a plan to throw these highlights. For example, before the interview, you have fully prepared the rhetoric of Dubbo, Redis and Netty, but the interviewer has not asked about it, and you can't show it to yourself. Correspondingly, you need to prepare the phrase "after answering the SQL question and leading to the Redis component", or the phrase "after answering the Redis data structure question and leading to the Redis cache tuning". In short, for the highlights of your preparation, you have to prepare one or more sets of "guidance programs" so that you can show your highlights to the greatest extent.
The above preparation methods will be described in detail later in this book. Of course, there are some senior interviewers who can control the direction of the interview well, and they are not easily guided by the candidate's words. But if you use the above preparation methods, even if you encounter this type of interviewer, you can still throw out highlights to the greatest extent. Besides, many interviewers you meet may be technical experts, but they may not be experienced in interviews.
8 Summary of highlights that can be proactively thrown during the interview
Regarding the highlights mentioned in the previous article, what can Java programmers prepare for? In fact, some topics have already been mentioned above, but here are more generalizations.
First, the underlying source code. Speaking shallowly, you can talk about the underlying source code of Java core objects, such as the expansion of ArrayList, HashMap read and write operations, and other low-level implementations. In depth, you can talk about the underlying source code at the Spring level, such as how the IOC mechanism injects objects, or aspect programming. How to associate the object and aspect code in it. Going deeper, you can talk about the underlying source code of distributed components, such as Dubbo service exposure or zero copy in Netty. Telling the corresponding implementation mechanism through the underlying source code can make the interviewer feel that you are very professional in this area.
Second, performance tuning. Here you can talk about memory tuning from the JVM garbage collection mechanism, and you can also extend the database tuning from the index to the Redis cache or MyCAT sub-database sub-table component, and even talk about the database and the cache cluster. Of course, it is best to combine projects. Case study. By demonstrating this skill, the interviewer will feel the depth of your technique.
Third, the ability to monitor, analyze, troubleshoot and solve problems. Candidates can use the case to explain from the three perspectives of "discovering problems through monitoring or logs", "troubleshooting problems through log analysis" and "corresponding solutions". If possible, add "distributed components" and " "Performance tuning", "Analyze the underlying source code" and "Cooperate with other groups to solve" these key elements. In the interview practice, the highlights of this part can even offset the shortcomings of some candidates in secondary skills.
Of course, the highlights that can be thrown in a Java interview are by no means the only ones, but in the interview process that lasts at most an hour, even if the candidate fully throws out the above three highlights, it is enough to affect the interview result.
Moreover, for Java primary development and advanced development, the experience of using distributed components can be regarded as a bright spot. From the basic grammar to the use of clusters, to the troubleshooting, as long as the project is combined, it is also a bonus item.
9 Not a summary, only a beginning
This article is part of the first chapter of my book on Distributed Component Interview Skills. It only introduces the status quo of most candidates and gives corresponding methods.
Since it is the first chapter, many methods are just presented without detailed expansion, and they have not even touched on distributed components. In the following chapters, I will focus on distributed components such as Dubbo, Redis, Kafka, and Netty, combined with cases to tell you about interview preparation skills and the way to display distributed skills in the interview combined with projects. In this regard, I will continue to extract relevant articles in subsequent blog posts, so stay tuned.
Moreover, this book is still in the process of writing, and it is expected to be published in half a year. After the book is published, please support me.
Copyright notice: If you want to reprint this article, please get my consent in advance.