|
Xin chào
Guest
| Đăng ký
| Đăng nhập
|
|
|
| Trang chủ | Những mạch mới | Mạch chưa trả lời | Người dùng trực tuyến | Thành viên | Giúp đỡ |
Diễn đàn SEGVN
Software Engineers
Software Engineering Professions
Mạch: Các công ti đang tìm cái gì?
|
| Không có thành viên nào đang xem mạch |
|
Trạng thái mạch: Bình thường Tổng số bài viết trong mạch này: 2 |
|
| Tác giả |
|
JohnVu
Prof. Tham gia: 29-12-2008 Tổng số bài đã viết: 849 Trạng thái: Offline |
Tim là giám đốc của một công ti phần mềm lớn. Tuần trước anh ấy tới gặp tôi để hỏi về một số sinh viên mà anh ấy muốn thuê cho nên tôi nói với anh ấy: “Anh chọn sinh viên phẩn mềm thế nào và làm sao anh biết người nào là người đúng cho công ti của anh?” Anh ta trả lời: “Tôi cho họ một số vấn đề để giải quyết và quan sát cách họ tiếp cận chúng. Mọi sinh viên phần mềm đều biết cách lập trình cho nên tôi không bao giờ hỏi họ về ngôn ngữ lập trình nhưng tôi đang tìm người có thể giải quyết được vấn đề. Với mọi vấn đề, có nhiều cách giải quyết nó. Một số người có thể đi tới giải pháp ngay lập tức và bắt đầu viết mã nhưng một số người sẽ yêu cầu thời gian để hiểu toàn bộ vấn đề trước khi làm bất kì cái gì. Tôi ưa thích kiểu người thứ hai bởi vì trong phần lớn thời gian, vấn đề không được thiết lập rõ. Sinh viên giỏi sẽ yêu cầu tôi giải thích vấn đề cho họ cho tới khi họ hiểu đầy đủ nó.” Tôi nói: “Vậy sau khi họ hiểu vấn đề thì anh có xem mã của họ không?" Anh ta lắc đầu: “Không đâu, điều tôi tìm kiếm là sinh viên bắt đầu nghĩ về các giải pháp khác nhau và xác định cách tiếp cận tốt nhất. Những sinh viên này sẽ tiếp tục hỏi tôi nhiều câu hỏi hơn để làm sáng tỏ giải pháp, thế rồi họ sẽ nghĩ thêm nữa rồi hỏi các câu hỏi nữa ngụ ý họ thực sự có nhiều tuỳ chọn và đang cố gắng tìm ra cách tốt nhất để giải quyết vấn đề. Những sinh viên giỏi này nhìn vào vấn đề, hình dung ra giải pháp phải là gì, loại thời gian nào họ có, chất lượng được mong đợi, công cụ họ có thể dùng làm việc trước khi họ thực tế thực hiện bất kì cái gì. Nếu tôi tìm thấy sinh viên như thế, tôi thuê họ ngay lập tức.” Tôi hỏi: “Nhưng về những người khác thì sao? Họ có thể giải quyết vấn đề mà.” Anh ta giải thích: “Có nhiều sinh viên có thể giải quyết được vấn đề, nhưng họ KHÔNG phải là điều công ti đang tìm. Chúng tôi là một trong những công ti phần mềm lớn nhất và thành công và chúng tôi rất có tính chọn lọc. Để tôi giải thích điều này cho anh, một số sinh viên vội vào trong viết mã và mọi sự dường như làm việc tốt cho họ nhưng điều gì sẽ xảy ra khi khách hàng đổi ý? Điều gì sẽ xảy ra khi yêu cầu thay đổi vào lúc sinh viên gần như hoàn thành mã của họ? Tất nhiên, họ phải đổi mã của họ và đó là chỗ khiếm khuyết bắt đầu xảy ra. Họ phải sửa chúng và họ càng sửa chúng, những điều xấu lại càng xảy ra thêm. Chúng tôi đã thấy nhiều sinh viên được đào tạo về viết mã nhưng KHÔNG được đào tạo về giải quyết và tiếp cận vấn đề. Tôi nghĩ đó là vấn đề với giáo dục ngày nay. Phần lớn các trường chỉ hội tụ vào viết mã mà KHÔNG vào qui trình phát triển phần mềm. Nhiều công ti đang thuê người lập trình, người có thể viết mã và kiểm thử nhưng họ KHÔNG biết cách tìm người phát triển tốt và đó là lí do tại sao công ti chúng tôi thành công thế. Ngày nay, sinh viên học về toàn thể vòng đời phần mềm nhưng chỉ hội tụ vào pha viết mã. Tất nhiên viết mã là quan trọng như có nhiều việc phát triển phần mềm hơn là chỉ viết mã. Bạn có thể có người lập trình giỏi nhất, và giải pháp tốt nhất nhưng nó có đáp ứng yêu cầu của người dùng không? Nếu nó KHÔNG đáp ứng thì bạn đã hoàn toàn thất bại. Sinh viên hiệu năng cao sẽ có khả năng giải quyết vấn đề bằng cách tiếp cận nó tương ứng theo qui trình và cẩn thận tuân theo các bước một cách nhất quán. Họ tìm ra đích xác điều người dùng muốn, đi tới cách tiếp cận lớn, chỉ ra cho người dùng điều họ sẽ được bằng các cuộc phỏng vấn gia tăng để khử bỏ khiếm khuyết. Đó là loại người phát triển chúng tôi muốn thuê.” Anh ấy dừng lại một phút rồi tiếp tục: “Có kiểu sinh viên khác có vẻ lanh lợi. Ông phỏng vấn anh ta và anh ta biết mọi thứ, anh ta có thể nói về đủ mọi lí thuyết phần mềm cho nên ông thuê anh ta và phân công cho anh ta cái gì đó để làm nhưng vài tuần sau, anh ta vẫn đang làm việc trên những điều mà đáng ra đã được thực hiện chỉ trong một tuần. Đây là loại "sinh viên lí thuyết", lanh lợi đấy, có thể ghi nhớ mọi thức nhưng không có tri thức thực hành và không biết cách làm cho mọi điều được thực hiện. Tôi thấy nhiều sinh viên thuộc vào loại này. Họ học mọi lí thuyết nhưng KHÔNG có thực hành. Hệ thống giáo dục đặt cơ sở hiệu năng sinh viên dựa trên thi cử là nguyên nhân gốc rễ cho kiểu sinh viên này. Sinh viên sẽ học bằng cách nhồi nhét mọi sách vở và lí thuyết nhưng không có thực hành thực tế. Đây là tình huống khó khăn cho nhiều công ti phần mềm. Là một công ti lớn và thành công, chúng tôi làm mọi sự theo cách khác. Chúng tôi tới thăm các đại học để kiểm điểm giáo trình của họ, chúng tôi kiểm cùng các giáo sư về mọi sinh viên tiềm năng mà chúng tôi muốn thuê để có gợi ý của họ. Chúng tôi theo sát tiến bộ của sinh viên bắt đầu từ năm thứ ba và cho nhiều việc thực tập trong hè để cho chúng tôi có thể quan sát được họ. Chúng tôi cộng tác với các đại học bằng việc cho họ biết loại kĩ năng nào chúng tôi sẽ cần trong ba tới năm năm và hi vọng rằng đại học sẽ cung cấp đào tại trong những khu vực đó. Trong trao đổi lại chúng tôi thuê sinh viên của họ và cung cấp phản hồi cho đại học về hiệu năng của họ. Nếu sinh viên đang làm tốt, chúng tôi sẽ tiếp tục thuê nhiều sinh viên từ đại học đó. Đó là mô hình quan hệ công nghiệp- đại học. Tôi bảo anh ta: “Tôi thích cách tiếp cận của công ti anh. Anh còn tìm cái gì khác nữa cho sinh viên của chúng ta?" Anh ta bảo tôi: “Nhân tố quan trọng khác là thái độ liên tục học hỏi. Người phát triển hiệu năng cao thường xuyên cập nhất kĩ năng của mình một cách dự ứng. Họ bao giờ cũng khao khát tri thức mới. Họ không chờ đợi người quản lí tới họ và yêu cầu họ lấy đào tạo thêm. Họ đi và học những điều mới theo cách riêng của họ. Trong cuộc phỏng vấn việc làm, tôi bao giờ cũng hỏi sinh viên về sách công nghệ hay website mới nhất là gì mà họ đã đọc trong vài tháng qua. Dựa trên câu trả lời của họ, tôi có thể xác định được liệu họ là người đúng cho công ti của tôi hay không. Để tôi cho anh một ví dụ khác về một trong các sinh viên của tôi. Năm ngoái, chúng tôi đã thuê Tiffany, cô ấy là người phát triển giỏi và đã làm rất tốt về dự án của cô ấy. Vài tuần trước, cô ấy gửi cho tôi một email “Tôi thực sự thích đi Hội nghị công nghệ an ninh phần mềm năm nay ở Boston. Tôi sẽ học thêm về an ninh phần mềm và cách thiết lập hàng động phòng ngừa để cho tôi có thể đóng góp cho dự án sửa đổi cơ sở dữ liệu bản ghi nhân sự. Tôi tin chúng ta cần chú ý nhiều về truy nhập dữ liệu hơn trước đây bởi vì dự án sửa đổi này sẽ là hệ thống phân bố. Nếu có thể, liệu công ti có thể giúp tôi trả tiền cho chuyến đi học này không?” Cô ấy chỉ là một nhân viên mới với một năm kinh nghiệm nhưng cô ấy đã chứng tỏ động cơ học tập của mình. Sau khi đọc yêu cầu của cô ấy, tôi đã cho cô ấy hai tuần để tham dự cuộc hội nghị và trả toàn bộ chi phí chuyến đi. Tôi nói với anh ta: “Tôi còn nhớ rõ Tiffany. Cô ấy là sinh viên giỏi và tôi biết rằng cô ấy sẽ đi xa trong nghề của mình. Tôi mừng là anh đã chăm nom cô ấy. Còn cái gì khác mà sinh viên chúng ta cần biết không?" Anh ta mỉm cười: “Nếu anh có nhiều sinh viên như Tiffany, tôi sẽ thuê tất cả họ. Có yếu tố quan trọng khác mà chúng tôi cũng coi là quan trọng: cách làm việc tổ. Một sinh viên có thể là một trong những người giỏi nhất, hay người lập trình tốt nhất, kiến trúc sư tốt nhất trong tổ, nhưng nếu người đó KHÔNG có khả năng chia sẻ thông tin hay đóng góp cho tổ, người đó đang đánh mất một nửa giá trị của mình đối với công ti. Chúng tôi KHÔNG muốn có anh hùng trong công ti chúng tôi, phần mềm là công việc tổ KHÔNG phải là công việc cá nhân. Người phát triển giỏi có thể hoàn thành công việc của mình nhưng nếu người đó KHÔNG giúp đỡ phần còn lại của tổ thì dự án có thể thất bại. Người phát triển vĩ đại bao giờ cũng trong tiếp xúc với mọi việc đang diễn ra bên trong tổ, và sẵn sàng giúp đỡ khi cần thiết. Người phát triển vĩ đại nhận trách nhiệm về việc riêng của mình và làm cho người khác gần mình được tốt hơn. Tất nhiên, có một số người chỉ muốn làm việc riêng của họ và không giúp cho người khác, họ có thể là người lập trình giỏi nhưng không bao giờ là vĩ đại. Người phát triển vĩ đại là người chơi theo tổ và coi tổ của họ như gia đình. Có nhiều người phát triển giỏi nhưng KHÔNG có mấy người phát triển vĩ đại. Nhiều người phát triển là những người kém trao đổi kinh khủng, họ thích làm việc chỗ cô lập hay trước máy tính. Họ KHÔNG thích nói chuyện và ưa thích gửi email hay tin nhắn cho nhau nhưng KHÔNG thích nói chuyện mặt đối mặt. Nhiều người sợ nói trước một nhóm. Những người này sẽ KHÔNG đi xa trong cách làm việc tổ nghề nghiệp của họ bởi vì làm việc tổ, trao đổi và trình bày cũng là những kĩ năng quan trong trong công việc kĩ thuật. ----English version---- What companies are looking for? Tim is a director of a large software company. Last week he came to see me to inquire about some students that he wanted to hire so I asked him: “How do you select software students and how do you know which one is the right person for your company?” He answered: “I give them some problems to solve and observe how they approach them. Every software graduates know how to program so I never ask them about programming languages but I am looking for people who can solve problems. For every problem, there are many ways to solve it. Some can come up with the solution instantly and start coding but some would require time to totally understand the problem before doing anything. I prefer the second type because most of the time, the problems are not well stated. Good students would ask me to explain the problem to them until they fully understand it”. I said: “So after they understand the problem then do you look at their code? He shook his head: “No, what I am looking for is students whostart thinking of various solutions and determine the best approach. These students will continue to ask me more questions to clarify their solutions, then they will thinking some more then ask questions again which means they really have several options and trying to find the best way to solve the problem. These good students look at the problem, figure out what the solution must be, what kind of time they have, the quality being expected, the tools they could work with before they actually implement anything. If I find students like that, I hire them immediately”. I asked: “But how about others? They can solve problem too.” He explained: “There are many students who can solve problem, but they are NOT what our company is looking for. We are one of the largest and successful software companies and we are very selective. Let me explain to you, some students hurry into coding and things seem to be working well for them but what will happen when customers change their minds? What will happen when requirements change at the time students almost complete their codes? Of course, they have to change their codes and that is where defects start to happen. They have to fix them and the more they fix, the more bad things are happening. We have seen many students who are trained in coding but NOT in problem solving and approach. I think that is the problem with the education today. Most schools only focus on coding but NOT the software development process. Many companies are hiring programmers who can code and test but they do NOT know how to find good developers and that is why our company is so successful. Today, students learn about the entire software life cycle but only focus on coding phase. Of course coding is important but there are more in software development than just coding. You may have the best programmer, and the best solution but does it meet the user’s requirement? If it is NOT then you have completely failed. A high performance students will be able to solve problem by approach it according to a process and carefully follow these steps consistently. They find out exactly what the user wants, come up with a great approach, show the user what they will get with incremental reviews to eliminate defects. That is the kind of developers that we want to hire”. He paused for a minute then continued: “There are another type of students who seems to be smart. You interview him and he knows everything, he can speak about all the software theories so you hire him and assign him something to do but several weeks later, he is still working on thing that could have been done in just one week. This is the kind of “Theoretical students” who are smart, can memorize everything but have no practical knowledge and do not know how to get things done. I found many students belong to this category. They learned all the theories but have NO practice. The education system that based students performance on examination is the root cause of these type of students. The students will learn by cramming all the books and theories but have no actual practices. This is a difficult situation for many software companies. As a large and successful company, we do things differently. We visit universities to review their curricula, we check with professors on every potential students that we want to hire to get their suggestions. We follow students’ progress’ beginning in the third year and gave many internships during summer so we can observe them. We collaborate with universities by let them know what kind of skills that we will need in the next three to five years and hope that university will provide training in those areas. In exchange we hire their students and provide feedback to the university on their performance. If students are doing well, we will continue to hire more students from that university. That is our industry-university relationship model. I told him: “I like your company’s approach. What else are you looking for in our students? He told me: “Another important factor is the continuous learning attitude. High performance developers are constantly updating their skills proactively. They are always thirsty for new knowledge. They do not wait for their managers to come to them and ask them to take additional trainings. They go and learn new things on their own. During the job interview, I always ask students what are the most recent technical books or websites that they have read in the past few months. Based on their answers, I can determine whether they are the right person for our company or not. Let me give you another example of one of your students. Last year, we hired Tiffany, she was a great developer and did very well on her project. Few week ago, she sent me an email “I would really love to go to the Software Security Technology Conference this year in Boston. I will learn more about software security and how to set up preventive actions so I can contribute to the Personnel record database revision projects. I believe we need to pay attention more on our data access than before because the revised project will be a distributed system. If it is possible, can the company help me pay for this trip?” She is only a new employee with about a year of experience but she already demonstrates her incentive to learn. After read her request, I gave her two weeks to attend the conference and paid for the entire trip. I told him: “I remember Tiffany well. She was a good students and I knew that she will go far in her career. I am glad that you already took care of her. Is there anything else that our students need to know? He smiled: “If you have more students like Tiffany, I will hire all of them. There is another important factor that we also consider important: Teamwork. A student can be one of the best, or the best programmer, best architect on the team, but if he is NOT able to share information or contribute to the team, he is losing about half of his value to the company already. We do NOT want hero in our company, software is a teamwork NOT individual work. A good developer may finish his work but if he is NOT helping the rest of the team then the project may fail. A great developer is always in touch with all the works that are going on within the team, and is ready to help when needed. Great developers take responsibility for their own works and make others near them better. Of course, there are some people who just want to do their own works and do not help others, they may be good developers but never be great. Great developers are team players and view their team like a family. There are many good developers but NOT a lot of great developers. Many developers are terrible communicators, they prefer to work in isolation or in front of the computer. They do NOT like to talk and prefer email or texting to each other but do NOT like to talk face to face. Many are afraid of talking in front of a group. These people will NOT go far in their career because teamwork, communication and presentation are also important skills in technical works. ---------------------------------------- Prof. Vu Carnegie Mellon University |
||
|
|
chucphuc
Novice Tham gia: 27-09-2010 Tổng số bài đã viết: 1 Trạng thái: Offline |
Cảm ơn Thầy ! Bài viết của thầy quan trọng lắm ! Chúc thầy luôn vui + khỏe !  |
||
|
|
|
Múi giờ hiện tại là GMT 00:43:12 06-02-2012 |
