When an interviewer asks you this question, what does he want to hear?

Hello, I am crooked.

In this issue, I want to briefly talk about an interview question that appears frequently in interviews, but has no standard answer.

What are the most impressive difficulties you have encountered at work and how did you overcome them?

Why do I want to talk about this?

Because I found that this question often appears in various technical exchange groups, most of them are miserable when they talk about this topic, and they all say they don't know how to answer this question.

In other words, I hadn't thought about such a question before, and I was suddenly asked. Because I wasn't prepared, I couldn't figure it out.

Looking back at my career in a hurry, I found that I wrote crud every day, and I didn't think it was difficult.

For a while, I actually wanted to blurt out: I don't think there are any major difficulties, I'm doing pretty well.

The interviewer smiled slightly: Okay, let's go here first for today's interview, please go back and wait for the notice.

what is the test

You must know that under normal circumstances, every question the interviewer asks during the interview must have his purpose.

For example, the interviewer asks the candidate to make a brief self-introduction. Many people say that the purpose is to look at the candidate's resume during the self-introduction time.

Perhaps in the early years, when candidates were asked to bring their resumes to interviews, this was indeed the case.

But now, all interviews are paperless, and the electronic version of your resume has long been in the hands of the interviewer.

Normally, the interviewer will have seen your resume before the interview. You don't need to use your self-introduction time to browse your resume when you don't need an interview.

When I usually ask candidates to introduce themselves, I listen carefully, I want to find things that are not reflected on the resume from his self-introduction, and I am also looking for the entry point of the interview , if there is any in the self-introduction Where I am interested, I will start from this place and ask around the resume.

For another example, when asked about your project:

Tell me about the project you are most familiar with.

It is asking what your project is for and what are the business scenarios?

no.

The purpose of asking this question is to know what the architecture of the project you are familiar with is like, whether it is a monolithic service or a dismantled microservice, which modules have been dismantled, the approximate size of each service, and how they interact with each other. Yes, what are the technology stacks involved.

Knowing this, the interviewer can find the point of discussion and start a technical interview.

As for what the project is for, just say a few words and set up a background.

When some students introduced the project, they described the pie the leader had drawn to him in business and described it to the interviewer again. If it's not the same line of business, the interviewer won't care about your business.

You must know that if you want to introduce a business scenario, the purpose must be to elicit a more complex technical solution behind it. Otherwise, the interviewer will not be too interested, and it will be useless to talk about it, but it will take up the time of the interview.

It is better to take out a pen and paper, draw your service interaction on it, and describe the technology stack involved in the corresponding place.

Again this question:

What are the most impressive difficulties you have encountered at work and how did you overcome them?

Some classmates said that he would not answer. I analyzed it, and the reason for not answering was actually because he did not know what direction the interviewer was investigating.

So I can only give some general answers such as adding an index when the query is slow, adding a cache for hot data, and restarting if there is a problem... I can't find anything that makes the interviewer shine.

How can it be brighter?

Generally speaking, I think there are two directions for answering this question.

The first direction of is the depth of technology. For the pursuit of technology, answer . I want to see if you have encountered any difficult technical problems, and how to locate and solve them.

The second direction is towards the sense of ownership, the direction that reflects subjective initiative. Answer . When faced with a project or a task given by a leader that involves other project teams or even other departments, how do you promote it?

depth of technology

If you answer this way, you have to accumulate more in your usual work, observe more relevant cases, and then record them.

You can look at the long-term perspective, not necessarily the problems encountered by your own project team, but also the problems encountered by other project teams.

Here you need to have an intelligence gathering ability and sensitivity to technology.

As soon as you hear this question, you should know: this is a good material, you can learn more about it.

This problem is not necessarily solved by you, but if you know the ins and outs clearly, you can package it as your own experience.

The interviewer doesn't notice it.

And I have always believed that modest packaging is not an interview fraud.

Of course, you can also go back in this direction.

But it cannot be purely recited, it has to be expanded appropriately.

For example, I shared an article about Dubbo call timeout before.

From the very beginning of the appearance of Dubbo calling timeout, the problem was analyzed from various perspectives such as database, GC, network, and link tracking, and it was a step-by-step process.

You will find that everyone's troubleshooting routines for problems such as timeouts are nothing more than this.

You can use this case yourself and set up a business scenario related to your own work.

I don't believe it. Haven't your interface calls ever timed out?

There are many such articles on the Internet, but the author writes only focus on the interview question itself.

If you want to apply this case to your own use, then you must also study what this problem can extend.

For example, in the previous article, why do you say "the failure strategy is failFast, and fast failure will not retry"? Because if it is failover, it will retry by default, and the timeout time is the sum of the retry time. So, he told us that there is no retry here, and the timeout is not caused by the time superposition brought by the request retry.

The ElapsedFilter filter mentioned in the article, "The interface that takes more than 300 milliseconds will be printed when it takes time" is the Filter extended by the author's own company. It is implemented based on Dubbo's SPI and is not an official function of Dubbo. Therefore, he added an additional sentence "ElapsedFilter is one of the (custom) extension points of the Dubbo SPI mechanism".

The Druid connection pool used by the author guesses that the connection will be recycled after not being used for a long time. Do you know and understand the function of the time-related configuration in the Druid configuration file?

If you want to observe the GC log, do you roughly know what parameters should be configured, and what information should you pay attention to? Why does he mention safety here? What is the relationship between the safe point and the STW time?

And so on, some related skills and knowledge reserves about containers, the use of Arthas tools, and the use of network packet capture tools.

When we take these knowledge out to form interview questions, you may think, why do you always ask me about MySQL knowledge, network-related knowledge, and some unused garbage collection knowledge?

Asking you to be speechless is not the purpose. Investigate the breadth of your knowledge, so that you can apply what you have learned is the goal.

The important thing is to connect the isolated points you have learned in some way.

And "what are the most impressive difficulties you have encountered at work" is one way you connect these knowledge points.

In addition, there is a well-known interview tips.

When answering questions, try to consciously guide the interviewer to a field that you are familiar with.

How to guide it?

It is impossible for others to ask you: can you tell me about the thread pool?

You replied: This is so boring, let me tell you about HashMap.

The interviewer must have felt that his head was big at the time.

We can guide the interviewer on these open questions.

If you have a deep understanding of technologies such as kafak, RabbitMQ, and RocketMQ, or have learned a lot about storage technologies such as Redis and MySQL, you can talk more about the reasons when you prepare for such problems.

For example, if I were to speak, I might choose to answer some technical questions caused by the Dubbo box, let the interviewer enter the field that I am familiar with, and let him start a game with me in it.

Or to guide in the direction of JVM, anyway, everyone learns this thing, and they all read the same information, it depends on how much you remember or how much I remember.

Or we can battle about issues related to the multi-threading field, but now that multi-threading is rotten, I may not be able to play with the interviewer for too long. Because even if your answer is flawless, most of the interviewers will think that this is just a basic skill that needs to be mastered.

In a word: if you want to answer in terms of technical depth, you must have something to say. The final problem can be a small problem, such as configuration reasons, network reasons, and framework bugs, but The focus should be on the investigation process. In the process of troubleshooting, there is a certain methodology, and it is good to extract it.

For this problem, the best strategy is to process your own personal experience, and have real experience in solving problems, just how to package it up.

The best way is to pack other people's experiences, to pack them vividly, and to mix the fake with the real.

If you are really helpless to choose the next option, then I can only give you one more sentence: add some detailed descriptions, which can be what button of the tool to click, what kind of source code you have read, and a reference to a blog of a big cow kind of.

Whether or not you can pass it depends on your fortune.

Subjectivity

In terms of subjectivity, I don't really have anything special to say.

The core idea is what I said earlier: sense of ownership.

The tasks you are responsible for are assigned to you by others. But you are the master of this task, and you have to think about how to be proactive and complete it.

for example:

You were originally just a happy programmer who wrote crud, waiting for the leader to assign tasks every day, and then lead the task to write code.

Suddenly one day, the leader said to you: Xiao Wang, there is a project here that is very urgent, but I have more urgent things to do here, so I will assign this task to you, you can take full responsibility for it.

You were stunned at the time, and the hand typing on the keyboard was unhappy.

This means that you are no longer a programmer who only writes code, you are still the leader of a project.

The person in charge of a project has to coordinate the resources of requirements, products, development, testing, operation and maintenance, etc.

And you've never done this before. The worst thing is, this thing is quite urgent.

How to do?

Isn't this the impressive difficulty you have encountered at work?

The scene frame is given to you, you just need to fill in the content according to your company's process.

How did you split the tasks, how did you organize the review meeting, and what was your reward for the successful launch of the project in the end?

can talk a little more about things that can't be seen from a programmer's perspective. Emphasize the difficulties and solutions you encounter when coordinating resources and cooperating across departments.

What, you say you have no experience with this?

Can't you just assume?

Can't you observe the entire process of a project cycle in your company?

You have to use your subjective initiative.

Then say it again, if you answer in this direction, there is a high probability that you will encounter a follow-up question:

If you were asked to do it again, how would you handle it better.

What is this thing about?

The test is your ability to review the test, and the test is whether you have reviewed the project.

If you answer: Since it is the first time for me to take charge of a project and follow up the whole process of its first-phase requirements, it is a very valuable experience for me, so after the project is launched, I conduct a After reviewing, I found that there are still one, two, three or four points that can be optimized...

I think basically answering this method is almost certain.

You have to say that you will not replay, okay, there is no help, go back and wait for the notice.

Summarize

During the interview, such open-ended questions are actually not as easy to answer as imagined, and there are undercurrents everywhere.

So be sure to prepare for this type of topic before the interview, and it will definitely have a very general effect on the spot.

Take my personal experience as an interviewer, especially friends with three to five years of work experience are prone to this problem.

I definitely don't ask this question in school admissions. The experience of less than three years is not rich enough, and it is difficult to give a satisfactory answer, so I do not ask. It is better to ask a few more technical questions to check whether his technology is solid.

In addition, the two directions mentioned above must be prepared.

If it is the first two rounds of interview questions, you can answer them in a technical way, because at this time, programmers who are coding on the front line are usually the technical interviewers, and he is more willing to discuss with you in terms of technology.

If it is the next few rounds of interviews, you can answer in the direction of the sense of ownership, because most of the interviews in the back are managers such as department heads, and they are rarely coding on the front line. They are more willing to see you in addition to technical skills. external soft power.

This article participated in the SegmentFault Sifu essay "How to "anti-kill" the interviewer?" , you are welcome to join.