本文发表在 rolia.net 枫下论坛Very often interviewers interrupt candidates in mid-sentence and move on to the next question. Sometimes, they do so after only a couple of words. Why? Because the candidates already hit the point.
The "point" is the most important thing in communications. You often hear people say "I got your point", "you missed the point", "what's your point". The most common problem in communications is not able to "get the point across" - they understand everything you say, but they still don't understand you.
One reason why we couldn't "get our point across" is rambling: giving too much details, or straying into totally unrelated topics. As a result, our point gets crowded out.
The good news is that this problem is easy to fix. We just have to realize the importance of "being concise and to the point". Most people don't have the patience to listen to ramblings. Even if they're patient, they may not be able to pick up our point from all the unimportant details.
Recently, I helped someone to find a job after she was laid off. One thing I helped her was email. At the beginning, I had to edit her emails so much that I often ended up rewriting the while thing. Something I could explain in one sentence, she had to use five. I told her that people get tons of emails at work and they could easily miss your point buried in a long email. Worse, they judge you to be a bad communicator and pick someone else for the job. She got my point and started to write shorter emails. After a couple of weeks, I didn't have to change her email very much.
Another reason why we couldn't "get our point across" is that we simply don't know the "point". This problem is harder to fix. Recently, after reading my previous post on communications, someone commented that he often had a hard time explaining technical ideas to other people. As a result, he lost some good opportunities. In my opinion, his problem could be that he doesn't understand the ideas deeply enough himself. Even though he knows a lot of facts, he isn't able to see the essence of the matter. As a result, all he could do is to recite these facts. And his audience doesn't have any "point" to get, only a lot of facts.
I did many mock interviews with the person I helped recently with job search. She had this problem often. For example, once I asked her to explain "Web Service". She talked about SOAP, WSDL, UDDI, and about the Web Services projects she worked on. A lot of facts. However, someone new to "Web Service" would still not know what exactly a "Web Service" is after listening to her. She couldn't help him because she actually doesn't know the answer herself, despite her knowledge and experience on the subject. If she had told him that a "Web Service" is simply "RPC over XML", an experienced programmer would "get the point" right away. The rest, is merely detail.
The ability to grasp the essence of a matter is very important in communications. Years ago, I applied for a Java EJB job after merely reading a book on EJB. The guy who interviewed me told my manager that he'd never seen anyone who understood EJB so deeply. I don't know exactly how I impressed him, but I remember one thing I said in the interview: an Entity Bean is a row in a database table. To me, this is the essence of Entity Beans. A lot of pages in that book distilled into this one sentence. And this one sentence might have earned me that job.
If you don't have the ability to grasp the essence of a matter, you may be able to acquire it by practice. Try to summarize a paragraph in one sentence. Then a chapter. Then a book. Or to summarize a technology in one sentence. Or a person. Or a city. If you can't, it probably means you haven't got to the core of the matter. You need to think more about it. Or read more. Or dream a little.
People often say that it's nearly impossible to land a job through published ads. There're probably 200 people fighting for one job, they'd say. Or even 1000. I always dismiss this type of thinking as pessimists' poison. If you can explain everything in a sentence or two, you should easily beat most of these 200 people, or 1000. Here's a good example.
The other day, I read an answer on the web to the question "what is Struts"? The guy used 3 long paragraphs yet he still didn't hit the key points. Here's the first paragraph: "The core of the Struts framework is a flexible control layer based on standard technologies like Java Servlets, JavaBeans, ResourceBundles, and XML, as well as various Jakarta Commons packages. Struts encourages application architectures based on the Model 2 approach, a variation of the classic Model-View-Controller (MVC) design paradigm." If you're interested in the other two paragraphs, here's the link: http://www.allapplabs.com/interview_questions/struts_interview_questions.htm.
I would answer the question this way: "Struts is a Java framework for building web applications; we use Struts Action classes to process web requests; we use Struts tags to compose web pages; we use Struts ActionForms to store and validate user input."
In a few short sentences, I explained key facts about Struts: Action classes, ActionForms and a tag library. With 5 times as many words, the web guy failed to mention either of these. I showed the interviewer that I'm experienced in Struts; the web guy, however, only showed that he memorized a lot of buzz words. He either didn't have much experience in Struts or didn't think much for an answer.
I'll conclude this post with a quiz. Someone was asked this question in an interview: "I need to test a method in a class. The method calls a service which takes 5 minutes to finish. How should I write the test?" What's the best answer in 2 or 3 words which might lead the interviewer to move on to the next question?
------ to be continued ------更多精彩文章及讨论，请光临枫下论坛 rolia.net
The "point" is the most important thing in communications. You often hear people say "I got your point", "you missed the point", "what's your point". The most common problem in communications is not able to "get the point across" - they understand everything you say, but they still don't understand you.
One reason why we couldn't "get our point across" is rambling: giving too much details, or straying into totally unrelated topics. As a result, our point gets crowded out.
The good news is that this problem is easy to fix. We just have to realize the importance of "being concise and to the point". Most people don't have the patience to listen to ramblings. Even if they're patient, they may not be able to pick up our point from all the unimportant details.
Recently, I helped someone to find a job after she was laid off. One thing I helped her was email. At the beginning, I had to edit her emails so much that I often ended up rewriting the while thing. Something I could explain in one sentence, she had to use five. I told her that people get tons of emails at work and they could easily miss your point buried in a long email. Worse, they judge you to be a bad communicator and pick someone else for the job. She got my point and started to write shorter emails. After a couple of weeks, I didn't have to change her email very much.
Another reason why we couldn't "get our point across" is that we simply don't know the "point". This problem is harder to fix. Recently, after reading my previous post on communications, someone commented that he often had a hard time explaining technical ideas to other people. As a result, he lost some good opportunities. In my opinion, his problem could be that he doesn't understand the ideas deeply enough himself. Even though he knows a lot of facts, he isn't able to see the essence of the matter. As a result, all he could do is to recite these facts. And his audience doesn't have any "point" to get, only a lot of facts.
I did many mock interviews with the person I helped recently with job search. She had this problem often. For example, once I asked her to explain "Web Service". She talked about SOAP, WSDL, UDDI, and about the Web Services projects she worked on. A lot of facts. However, someone new to "Web Service" would still not know what exactly a "Web Service" is after listening to her. She couldn't help him because she actually doesn't know the answer herself, despite her knowledge and experience on the subject. If she had told him that a "Web Service" is simply "RPC over XML", an experienced programmer would "get the point" right away. The rest, is merely detail.
The ability to grasp the essence of a matter is very important in communications. Years ago, I applied for a Java EJB job after merely reading a book on EJB. The guy who interviewed me told my manager that he'd never seen anyone who understood EJB so deeply. I don't know exactly how I impressed him, but I remember one thing I said in the interview: an Entity Bean is a row in a database table. To me, this is the essence of Entity Beans. A lot of pages in that book distilled into this one sentence. And this one sentence might have earned me that job.
If you don't have the ability to grasp the essence of a matter, you may be able to acquire it by practice. Try to summarize a paragraph in one sentence. Then a chapter. Then a book. Or to summarize a technology in one sentence. Or a person. Or a city. If you can't, it probably means you haven't got to the core of the matter. You need to think more about it. Or read more. Or dream a little.
People often say that it's nearly impossible to land a job through published ads. There're probably 200 people fighting for one job, they'd say. Or even 1000. I always dismiss this type of thinking as pessimists' poison. If you can explain everything in a sentence or two, you should easily beat most of these 200 people, or 1000. Here's a good example.
The other day, I read an answer on the web to the question "what is Struts"? The guy used 3 long paragraphs yet he still didn't hit the key points. Here's the first paragraph: "The core of the Struts framework is a flexible control layer based on standard technologies like Java Servlets, JavaBeans, ResourceBundles, and XML, as well as various Jakarta Commons packages. Struts encourages application architectures based on the Model 2 approach, a variation of the classic Model-View-Controller (MVC) design paradigm." If you're interested in the other two paragraphs, here's the link: http://www.allapplabs.com/interview_questions/struts_interview_questions.htm.
I would answer the question this way: "Struts is a Java framework for building web applications; we use Struts Action classes to process web requests; we use Struts tags to compose web pages; we use Struts ActionForms to store and validate user input."
In a few short sentences, I explained key facts about Struts: Action classes, ActionForms and a tag library. With 5 times as many words, the web guy failed to mention either of these. I showed the interviewer that I'm experienced in Struts; the web guy, however, only showed that he memorized a lot of buzz words. He either didn't have much experience in Struts or didn't think much for an answer.
I'll conclude this post with a quiz. Someone was asked this question in an interview: "I need to test a method in a class. The method calls a service which takes 5 minutes to finish. How should I write the test?" What's the best answer in 2 or 3 words which might lead the interviewer to move on to the next question?
------ to be continued ------更多精彩文章及讨论，请光临枫下论坛 rolia.net