Hi, I’m crooked.
In this episode, I want to briefly talk about a question that comes up frequently in interviews, but there is no standard answer.
What was the most impressive difficulty you encountered in your work and how did you overcome it?
Why do I want to talk about this?
Because I find this question often appears in various technical communication groups, when talking about this topic, most people are miserable, they don’t know how to answer this question.
Or I have never thought of such a question before, and suddenly I am asked, because I am not prepared, I feel confused.
After a quick review of my career, I found that I wrote CRUD every day, and I didn’t find it difficult.
For a time, I even wanted to blurt out: I think there is no special difficulty, I do quite well.
The interviewer smiled and said, ok, that’s all for today’s interview. Please go back and wait for the notice.
What’s on the test
It’s important to understand that every question an interviewer asks during an interview has a purpose.
For example, when the interviewer asks the candidate to give a brief introduction about himself, many people say that the purpose is to look over the candidate’s resume during the introduction time.
This may have been true in earlier years, when candidates were required to bring their own resumes to interviews.
But in these days of paperless interviews, an electronic copy of your resume is already in the interviewer’s hands.
Normally, the interviewer will have already seen your resume before the interview, so you don’t need to take the time to read it while you introduce yourself.
When I ask a candidate to introduce himself, I am listening carefully. I want to find out what is not on the resume from his introduction, and I am also looking for the entry point of the interview. If there is something in the introduction that interests me, I will start from this place and follow the resume.
For example, when asking about a project:
Tell me about the projects you are most familiar with.
What does the project do? What are the business scenarios?
Isn’t.
The purpose of asking this question is to know what the architecture of the project you are familiar with is, whether it is a single service or a micro service, which modules are removed, the approximate size of each service, how they interact with each other, and what technology stacks are involved.
Knowing this, the interviewer will be able to find discussion points to start the technical interview.
As for what the project is about, just say a few words and set the background.
Some students describe to the interviewer the pie that the leader drew for them when introducing the project. The interviewer won’t care about your business if it’s not in the same line of business.
Keep in mind that if you are going to introduce a business scenario, the purpose is to introduce a more complex technical solution behind it. Otherwise, the interviewer won’t be interested, and talking won’t help but take up time.
Instead, get out a pen and paper and draw a picture of your service interaction, along with a description of the technology stack involved where appropriate.
If you can’t draw, check out this post I shared earlier:
Interviewer: Please draw me a project architecture diagram.
Here’s another question:
What was the most impressive difficulty you encountered in your work and how did you overcome it?
Some students said that they would not answer, BUT I analyzed it and found that the reason for not answering was that I did not know what direction the interviewer was investigating.
So can only give some such as query slow add index, hot data cache, a problem restart good… You’re not going to find anything that jumps out at the interviewer.
How can you answer with a little more sparkle?
In general, I think there are two ways to answer this question.
The first direction is to the depth of technology, for the pursuit of technology in this direction. I want to see if you have encountered any technical problems that are difficult, and how to locate and solve them.
The second direction is to the sense of ownership, reflect the direction of subjective initiative. When a project or a task assigned by a leader involves other project teams or even other departments, how do I promote myself?
Depth of technology
If you answer this way, you have to accumulate more in your daily work, observe more relevant cases, and then write them down.
You can take a long view, not necessarily the problems of your own project team, but the problems of other project teams.
This is where you have to have an intelligence-gathering capability, and a sensitivity to technology.
As soon as you hear this question, you should know: this is a good material to learn more about.
You may not be able to solve the problem, but you need to understand the context so that you can package your own experience.
The interviewer won’t be able to tell.
And I always believe that moderate packaging is not a fake interview.
Of course, you can also go in this direction.
But not pure recitation, appropriate to expand.
Like this post I shared earlier:
The production case, good, good, very good.
This case analyzes the problem from the perspectives of database, GC, network and link tracing from the appearance of Dubbo call timeout at the very beginning, and it is a step-by-step process.
You will find that everyone for timeout problems such as the screening routine is nothing more than this, layer upon layer of progressive screening, to find the problem.
This is a case you can use yourself to create a business scenario related to your work.
I don’t believe you, you never timeout your interface calls?
There are many such articles on the Internet, but the author only focuses on the interview question itself.
If you want to apply this case to yourself, then you have to study what the problem extends to.
For example, in the previous article, why is it said that “the failure policy is failFast, fast failure does not retry”? In the case of failover, the system retries by default, and the timeout period is the sum of the retries. So, he tells us that there are no retries, and that the timeout is not caused by the addition of time to request retries.
The ElapsedFilter mentioned in the article, “the interface time exceeding 300 milliseconds will be printed”, is the author’s own extended Filter, based on Dubbo SPI implementation, is not an official built-in function of Dubbo. So he added that “ElapsedFilter is one of the (custom) extension points of the Dubbo SPI mechanism.”
The Druid connection pool has been used for a long time. The Druid connection pool has been used for a long time. The Druid connection pool has been used for a long time.
If you are looking at GC logs, do you have a general idea of what parameters to configure and what information to focus on? Why would he say “safe” here? What is the relationship between the safety point and the time of STW?
Arthas tools, network capture tools, etc.
When we separate these knowledge into interview questions, you may think, why do you always ask me about MySQL, network related knowledge, garbage collection knowledge I do not need?
Asking you, silencing you is not the goal. Measuring the breadth of your knowledge so that you can apply it is the goal.
The important thing is to connect the dots in some way.
One way to connect the dots is to ask, “What are the most impressive difficulties you have encountered at work?”
In addition to the previous article, I also share these similar things, do you think I just share them with you?
No, I myself also in the collection, also in the understanding, also want to “take doctrine” :
A good online troubleshooting case, and now it’s yours.
Did you come across any difficult problem in your work?
I laughed. The interviewer asked me if I had ever encountered any online questions.
I have a Bug with the Apache top-level project
There’s another interview tip that everyone knows.
When answering questions, try to consciously guide the interviewer into familiar territory.
How do you guide it?
You can’t be asked: Can you tell me about thread pools?
You say, “That’s boring. Let me tell you about HashMap.”
The interviewer must have thought his head was big.
We can guide the interviewer with these open questions.
If you are familiar with kafak, RabbitMQ, RocketMQ, or storage technologies such as Redis and MySQL, you can explain why.
For example, if I had to speak, I would have chosen to answer some technical questions brought by the Dubbo box, and let the interviewer get into my familiar territory, and let him and I have a game.
Or to the DIRECTION of the JVM guide, anyway, we learn this thing, look at the same information, depending on how much you remember or I remember more.
Or we could do something about multi-threading, but now that multi-threading sucks, I probably won’t be able to compete with the interviewer for too long. Even if your answer is perfect, most interviewers will think it’s just a basic skill to master.
In a word: if you want to answer in the depth of technology, be sure to talk about something. The problem can be a small one, such as configuration, network, and framework bug, but the focus should be on the troubleshooting process. In the process of troubleshooting, there is a certain methodology, which can be refined.
For this problem, the best way is to process your own experience, actually have the experience of solving the problem, just how to put it on a high gloss.
The worst thing you can do is package someone else’s experience so that it looks like the real thing.
If you really have to choose the wrong way, I can only offer you one more sentence: include a few details, such as what button to click on the tool, what kind of source code to look at, refer to a famous blog, etc.
It’s up to your luck to pass.
Subjective initiative
I don’t really have anything particular to say about subjective initiative.
The core idea is what I said earlier: a sense of ownership.
You are responsible for tasks that were assigned to you. But you are the owner of the task, and you need to figure out how to be proactive and get it done.
Here’s an example:
You were just a happy programmer writing CRUD, waiting for your boss to give you tasks to write code.
All of a sudden, one day, your leader says to you: Xiao Wang, there is a project urgent, but I have more urgent things to do, so I assign this task to you, you can take full charge of it.
You were muddled at that time, the hand on the keyboard is not happy.
This means you’re no longer a programmer writing code, you’re a project leader.
A project leader has to coordinate requirements, product, development, testing, operations, and other resources.
And this is something you’ve never done before. The thing is, it’s a rush.
How to do?
Isn’t that the most impressive difficulty you’ve encountered at work?
The scene frame is given to you, and you just fill it in according to your company’s procedures.
How you split tasks, how you organized review meetings, and what you gained when the project was successfully launched.
Talk a little bit more about things you can’t see from a programmer’s perspective. Focus on the difficulties and solutions encountered in coordinating resources and cross-department cooperation.
What, you’re saying you don’t have any experience?
Can’t you just assume?
Can’t you observe the entire project cycle in your company?
You have to use your initiative.
And then again, if you go in this direction, there’s a good chance you’ll get a follow-up question:
If you had to do it again, how would you handle it better?
What’s the test on this thing?
Test is your ability to review, test is to have a review for the project.
If you answer: Since it was my first time to be in charge of a project and follow up the whole process of its first phase of requirements, it was a very valuable experience for me, so I did a review of the project after it was launched and found one, two, three and four areas that could be improved…
I think that’s pretty much a safe answer.
You say you won’t call back, okay, there’s no help. Go back and wait.
conclusion
For this kind of open topic in the interview, in fact, it is not so good to answer as imagined, there are undercurrents surging everywhere.
So be sure to prepare for this kind of topic before the interview, improvisation is certainly the effect is very general.
In my own experience as an interviewer, this is especially true for those with three to five years of experience.
I certainly don’t ask about admissions. Less than three years of experience is not enough to give a satisfactory answer, so I don’t ask. Instead, ask a few more technical questions to see if his skills are solid.
Also, we need to prepare for both directions.
If it is the first two rounds of interview questions, you can answer in a technical way, because this time is generally in the front line coding programmers as technical interviewers, he is more willing to discuss with you in technical aspects.
If it is in the later rounds of interviews, you can go to the direction of the sense of ownership to answer, because most of the later interviews are managers such as department heads, who are rarely in the front-line coding, they are more willing to see your soft strength in addition to technology.
One last word
Ok, see here, forward, look, like any arrangement, if you arrange it, I don’t mind. Writing is tiring and needs some positive feedback.
Here’s one for readers:
This article has been collected from personal blog, welcome to play.
www.whywhy.vip/