What do you think?
Rate this book
Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent
A "good" programmer can outproduce five, ten, and sometimes more run-of-the-mill programmers. The secret to success for any software company then is to hire the good programmers. But how to do that? In Joel on Hiring, Joel Spolsky draws from his experience both at Microsoft and running his own successful software company based in New York City. He writes humorously, but seriously about his methods for sorting resumes, for finding great candidates, and for interviewing, in person and by phone. Joel’s methods are not complex, but they do get to the heart of the how to recognize a great developer when you see one.
182 pages, Kindle Edition
First published January 1, 2007
21 people are currently reading
1144 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 103 reviews
September 12, 2020
This book is a guide to hiring developers using humiliating techniques, that are wildly common today, but hopefully, die soon:
* Making a candidate write code on paper
* Whiteboard interviews
* Asking uncomfortable/stressful questions to see how a candidate deals with them (basically sadism)
* Dividing people in smart and dumb
* Assuming that some people cannot be good programmers: according to Joel, you're bad if you don't understand recursion or pointers well
* Sending a candidate through 5-6 interview rounds a day
* Boasting about fancy offices, parties, limos, and other cheap crap
* etc.
The book is written from the position of a "rockstar developer", who created a popular "rockstar company", where only the privileged, talented, and gifted people are allowed to work (basically those who can write a compiler on a napkin using Haskell and understand pointers).
The book is polarized, full of prejudice. Nothing is said about psychology, impostors, different personalities, and treating people well. Overconfident rockstars-assessors (who think they are 10x more productive than others and "hitting the high notes" more frequently) choose new "bros" into the privileged closed club.
There were good parts about hunting new grads and some non-hiring hints (that you can learn from DeMarco's Peopleware and Brooks' Mythical Man-Month). Otherwise, use practices described in this book at your own peril. This book is harmful to the software industry.
* Making a candidate write code on paper
* Whiteboard interviews
* Asking uncomfortable/stressful questions to see how a candidate deals with them (basically sadism)
* Dividing people in smart and dumb
* Assuming that some people cannot be good programmers: according to Joel, you're bad if you don't understand recursion or pointers well
* Sending a candidate through 5-6 interview rounds a day
* Boasting about fancy offices, parties, limos, and other cheap crap
* etc.
The book is written from the position of a "rockstar developer", who created a popular "rockstar company", where only the privileged, talented, and gifted people are allowed to work (basically those who can write a compiler on a napkin using Haskell and understand pointers).
The book is polarized, full of prejudice. Nothing is said about psychology, impostors, different personalities, and treating people well. Overconfident rockstars-assessors (who think they are 10x more productive than others and "hitting the high notes" more frequently) choose new "bros" into the privileged closed club.
There were good parts about hunting new grads and some non-hiring hints (that you can learn from DeMarco's Peopleware and Brooks' Mythical Man-Month). Otherwise, use practices described in this book at your own peril. This book is harmful to the software industry.
December 23, 2016
This is a very quick read on how to hire programmers. It's full of insights and interesting thoughts from someone who has been in the trenches of being a programmer and hiring programmers for years, who has succeeded at both tasks, and who has thought deeply about why. He has great points on how to find programmers (hint: job boards don't work) and how to build an environment where programmers can be productive. For those reasons, it's worth reading.
However, while I respect Spolsky and have followed his blog for years, I don't agree with a number of key points in the book:
* Spolsky makes most of his arguments about hiring as if they are scientific facts, whereas most of what he says actually consists of anecdotes, correlations, and guesses. For example, when he makes the claim that interview questions about pointers can be used to distinguish between good programmers and great programmers, he has nothing but anecdotal evidence to back that up. It's entirely possible that the programmers he rejected who failed his pointers interview question would've actually been great employees. Without a controlled experiment, we don't really know. Obviously, I don't expect Spolsky to be spending his time on controlled scientific experiments, but I do expect him to present his stances as conjectures rather than absolute truths. The sad truth about hiring is that we all suck at it and not acknowledging that does a lot of harm to this industry.
* As an example of the harm this "trust me, I know what I'm doing" attitude can have is Spolsky's claim that programming ability, such as understanding pointers, is innate, and cannot be taught. I call BS on that. No one is born understanding pointers. And if a large percentage of people can't learn pointers, my guess is that has more to do with the ability of the teachers than of the students. But that's just my guess and I prefer to label it as such. Spolsky presents it as a hard fact. The either you-have-it-or-you-don't, fixed-mindset is, IMO, harmful to the software industry. We need to encourage more people to take up programming rather than scaring them away because they might have been born a muggle.
* Sposky recommends white board coding. I would argue this is a horrifically ineffective way to evaluate programmers that this industry should have abandoned long ago. Working on artificial problems from CS 101 that can fit in a 45 minute slot, writing code by hand with no compiler, no syntax checking, no auto complete, no Google or StackOverflow (yes, every programmer uses these constantly while coding), no libraries, no ability to incrementally build/run the code, no quiet time to do thinking (instead, speak all your thoughts out loud because that's totally natural!), and a ridiculous pressure to prematurely optimize the shit out of a tiny piece of code is NOT my idea of an effective interview process. A book like this recommending it as a "best practice" does harm to the industry.
In short: if you're going to hire programmers, it's worth reading this book, but don't take it as gospel.
As always, some of my favorite quotes from the book:
"Duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold. Essentially, design adds value faster than it adds cost."
"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years."
"It's not just a matter of "10 times more productive." It's that the "average productive" developer never hits the high notes that make great software."
"The great software developers, indeed, the best people in every field, are quite simply never on the market [...] The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot."
"When a programmer complains about "politics," they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it."
"In a high-tech company the individual contributors always have more information than the "leaders," so they are really in the best position to make decisions. When the boss wanders into an office where two developers have been arguing for two hours about the best way to compress an image, the person with the least information is the boss, so that's the last person you'd want making a technical decision."
"The military uses Command and Control because it's the only way to get 18-year-olds to charge through a minefield, not because they think it's the best management method for every situation."
However, while I respect Spolsky and have followed his blog for years, I don't agree with a number of key points in the book:
* Spolsky makes most of his arguments about hiring as if they are scientific facts, whereas most of what he says actually consists of anecdotes, correlations, and guesses. For example, when he makes the claim that interview questions about pointers can be used to distinguish between good programmers and great programmers, he has nothing but anecdotal evidence to back that up. It's entirely possible that the programmers he rejected who failed his pointers interview question would've actually been great employees. Without a controlled experiment, we don't really know. Obviously, I don't expect Spolsky to be spending his time on controlled scientific experiments, but I do expect him to present his stances as conjectures rather than absolute truths. The sad truth about hiring is that we all suck at it and not acknowledging that does a lot of harm to this industry.
* As an example of the harm this "trust me, I know what I'm doing" attitude can have is Spolsky's claim that programming ability, such as understanding pointers, is innate, and cannot be taught. I call BS on that. No one is born understanding pointers. And if a large percentage of people can't learn pointers, my guess is that has more to do with the ability of the teachers than of the students. But that's just my guess and I prefer to label it as such. Spolsky presents it as a hard fact. The either you-have-it-or-you-don't, fixed-mindset is, IMO, harmful to the software industry. We need to encourage more people to take up programming rather than scaring them away because they might have been born a muggle.
* Sposky recommends white board coding. I would argue this is a horrifically ineffective way to evaluate programmers that this industry should have abandoned long ago. Working on artificial problems from CS 101 that can fit in a 45 minute slot, writing code by hand with no compiler, no syntax checking, no auto complete, no Google or StackOverflow (yes, every programmer uses these constantly while coding), no libraries, no ability to incrementally build/run the code, no quiet time to do thinking (instead, speak all your thoughts out loud because that's totally natural!), and a ridiculous pressure to prematurely optimize the shit out of a tiny piece of code is NOT my idea of an effective interview process. A book like this recommending it as a "best practice" does harm to the industry.
In short: if you're going to hire programmers, it's worth reading this book, but don't take it as gospel.
As always, some of my favorite quotes from the book:
"Duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold. Essentially, design adds value faster than it adds cost."
"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years."
"It's not just a matter of "10 times more productive." It's that the "average productive" developer never hits the high notes that make great software."
"The great software developers, indeed, the best people in every field, are quite simply never on the market [...] The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot."
"When a programmer complains about "politics," they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it."
"In a high-tech company the individual contributors always have more information than the "leaders," so they are really in the best position to make decisions. When the boss wanders into an office where two developers have been arguing for two hours about the best way to compress an image, the person with the least information is the boss, so that's the last person you'd want making a technical decision."
"The military uses Command and Control because it's the only way to get 18-year-olds to charge through a minefield, not because they think it's the best management method for every situation."
September 17, 2018
A little outdated and a lot of condescension. There are some useful tips, but others I feel were just wrong. There is weird stuff about how programmers talking about O(log n) is using jargon. What comes off in the book is that Spolsky is pretty opinionated about the hiring process without doing some self-assessment of whether it really makes sense.
April 25, 2019
Smart and Gets Things Done (2007) by Joel Spolsky is Spolsky's guide to hiring good programmers and setting things up so they can work best. Joel on Software was for a number of years in the 2000s a well read software engineering blog. Spolsky worked for Microsoft, then founded Fog Creek software that made a bug tracker and then went on to co-found the incredibly useful Stack Exchange site.
The book is mainly about hiring and Spolsky describes how he hires and how he thinks you should hire. Spolsky says that companies should hire the best after phone screens, code writing in interviews and careful checks and then pay them very well and put coders in offices. The advice is all fairly solid, the issue being that it's solid for a company that is able to pay well and give top software engineers what they want. There is little consideration given to companies that can't pay that well but still need someone to work on their code.
Something that is interesting about the book now is that it predates the massive growth of the Agile movement and also some modern tools like Continuous Integration / Continuous Deployment and DevOps. This doesn't take much away from the book, but does show how things have moved on.
Smart and Gets Things done isn't a great book, but it is a good one and a book that has quite a few useful tips for anyone involved in hiring.
The book is mainly about hiring and Spolsky describes how he hires and how he thinks you should hire. Spolsky says that companies should hire the best after phone screens, code writing in interviews and careful checks and then pay them very well and put coders in offices. The advice is all fairly solid, the issue being that it's solid for a company that is able to pay well and give top software engineers what they want. There is little consideration given to companies that can't pay that well but still need someone to work on their code.
Something that is interesting about the book now is that it predates the massive growth of the Agile movement and also some modern tools like Continuous Integration / Continuous Deployment and DevOps. This doesn't take much away from the book, but does show how things have moved on.
Smart and Gets Things done isn't a great book, but it is a good one and a book that has quite a few useful tips for anyone involved in hiring.
January 2, 2021
A short guide on how to hire engineers, even though IMHO same principles can be applied to any role.
November 15, 2023
Trang 20-46: Joel nói về cách tuyển dụng nhân tài từ khi còn là sinh viên, đưa đón bằng limo, ở khách sạn cao cấp, video giới thiệu các kỳ intern trước đó, tuyển vào mùa hè, cho làm việc với code production, những sinh viên giỏi thường bắt đầu lập trình từ năm 10 tuổi. tổ chức các hoạt động ngoại khóa: âm nhạc. phim, tour bảo tàng, đi thuyền, ...
Best working environment -> Best programmers -> Best products -> Profit
công ty Fog Creek không có nhiều quản lý cấp trung, họ muốn nhân viên của mình phải hoàn toàn self-driven. những người thích chờ đợi sự hướng dẫn thì sẽ ko phù hợp với họ.
họ sẽ đưa ra offer cao hơn những cty khác để khi intern trở về trường, so sánh mức offer đó với những người bạn đồng trang lứa, họ sẽ có thể ra quyết định nhanh chóng. vì đã có thời gian thử thách khi intern, nên họ không phải nghĩ về việc người đó sẽ ko làm được việc. họ sẵn sàng trả lương cao hơn vì họ có nhiều thông tin về ứng viên hơn những công ty khác mà chỉ thực hiện phỏng vấn, thông qua thời gian thử thách trước đó.
họ trả cho sinh viên 750$/tuần + free housing + free lunch + free subway passes + các chi phí di chuyển khác nếu có.
cuốn sách Peopleware là kinh thánh trong việc quản lý công ty công nghệ
trang 50-60: nhìn từ góc độ của lập trình viên, họ muốn cty ntn? các tiện nghi khi làm việc. private offices, ghế công thái học thay vì ghế rẻ tiền, ghế công thái học tính ra có thể sử dụng lâu dài còn tiết kiệm hơn ghế rẻ mà nhanh hỏng, dev có thể ngồi nhiều giờ liền mà vẫn thoải mái, màn hình xịn, nên có ít nhất 2 màn hình 21 inches và cho dev thoải mái lên amazon mua sách technical. đồng nghiệp của họ như thé nào?
nếu bạn muốn thuê những người giỏi, coi họ là những chuyên gia , thì hãy tin tưởng chuyên môn của họ, đừng can thiệp vào chi tiết quá trình họ làm, như vậy sẽ gây ra sự khó chịu.
trang 72: một trong những cách tốt nhất để thu hút người tài là cho họ biết những điều thú vị mà họ sắp làm trong cty. cty có trang web chia sẻ kiến thức không? cho phép dev dành 1 tuần để đi xung quanh cty và lựa chọn dự án mà họ muốn join. đừng gò bó ngôn ngữ lập trình mà dev sẽ sử dụng. dev sẽ happier nếu được trải nghiệm với ngôn ngữ lập trình mới, framework, công nghệ mới.
lý tưởng của cty là gì? có khiến dev đồng cảm không
trang 78: lập trình viên giỏi thực sự không nghĩ ngợi nhiều về tiền, mà họ sẽ quan tâm những yếu tố ở phái trên, nhưng ko có nghĩa là bạn lợi dụng để trả họ mức lương thấp, hãy chủ động trả lương cao.
trang 83: những yếu tố bổ trợ khi chọn ứng viên:
- đam mê: cần bằng chứng: kinh nghiệm lập trình, mức độ thường xuyên code trên github, great programmers sẽ dành cả mùa hè tại computer camp, hoặc build những dự án riêng, thay vì đi làm thêm ở cửa hàng quần áo, ..., họ cập nhật kiến thức, công nghệ mới, hỏi là biết
- sự kén chọn: resume thay vì chỉ nói về bản thân ứng viên, họ còn nói về việc tại sao họ chọn cty này
- tiếng anh: quan trọng trong giao tiếp và giải thích ý tưởng của mình
- tư duy: GPA cao, tham gia những cuộc thi top coder, competitive chess, ACM contest, ...
- trường đại học: dựa vào số liệu trong quá khứ, họ sẽ lọc được tỉ lệ sinh viên trường nào có kỹ năng tốt, môi trường của đại học nào rèn luyện tốt cho sinh viên, ví dụ có những hoạt động quân đội, huấn luyện, các cuộc thi lớn
- làm việc với phần cứng: ví dụ ấn tượng với người biết về OCaml hơn là Java, biết assembly hoặc device driver hơn là Visual Basic hay PHP, C++ với ATL hơn là Perl, ...
- sự đa dạng trong trải nghiệm của ứng viên trong quá khứ
hãy nhớ trên đây chỉ là những yếu tố bổ trợ, quan trọng là phải phỏng vấn và thử việc, thì mới hiểu được chính xác khả năng của ứng viên
nếu resume của ứng viên ít thông tin, c�� thể test họ thông qua các câu hỏi lập trình, code trực tiếp như implement thuật toán đệ quy, thời gian họ cần để tìm và fix bug, họ có thể keep nine items in short-term memory không, ...
trang 97: sử dụng gọi điện (không bật cam để đảm bảo công bằng, ko nhìn mặt mà bắt hình dong) ��ể test ứng viên trước khi hẹn phỏng vấn trực tiếp, tránh mất thời gian và tiền bạc của cả 2 bên.
3 phần khi phỏng vấn = điện thoại:
- hỏi ứng viên về kinh nghiệm làm việc, giới thiệu bản thân: giúp họ giảm bớt căng thẳng với những câu hỏi đơn giản. dựa chọn câu trả lời của họ để đi vào chi tiết. ví dụ họ liệt kê nhiều dự án, thì hỏi vào công nghệ họ sử dụng, vai trò của họ trong dự án đó
- hỏi về kiến thức công nghệ: a wide-ranging, open design question: làm sao để bạn thiết kế 1 cấu trúc dữ liệu hoặc 1 block of code để làm việc X? với X là 1 vấn đề lớn và phức tạp. đặt series câu hỏi để hướng ứng viên giải quyết từng phần một. Here are some ideas to get you started: • How might you design a program that lets people play Monopoly with each other over the Internet?2 • What would be a good data structure for a photo editor? • How would you implement code to operate the elevators in a high rise? • How would you implement the rendering engine of a web browser? Tránh những câu hỏi kiểu như bạn sẽ code quicksort như thế nào? Hãy hỏi những câu liên quan đến độ phức tạp time/space, tradeoffs, performance
- cuối cùng là để ứng viên đặt câu hỏi ngược lại cho mình: nếu ứng viên thực sự hứng thú với cty, họ sẽ đặt những câu hỏi liên quan đến những yếu tố thu hút ở trang 50-60 phần bên trên.
trang 107: cần có ít nhất 6 người thực hiện phỏng vấn ứng viên, trong đó có ít nhất 2 người thực hiện pair programming với ứng viên (2 người này cũng là dev, không phải manager), tránh trường hợp 1 người nonprogrammer đi phỏng vấn 1 programmer. nếu ít nhất 2 trong 6 người phản đổi, thì sẽ ko chọn ứng viên này.
có 3 kiểu ứng viên:
- không biết gì, chỉ cần hỏi 2 hoặc 3 câu hỏi nhanh là đã phát hiện ra
- superstar, người dành cả cuối tuần để code Lisp compiler for fun, hay viết assemler for the Nintendo DS
- tầm trung, đông đảo nhất, người thường trả lời "maybes"
một trick đó là hãy nói ra sự khác nhau giữa superstar và maybes, vì bạn sẽ chẳng bao giờ còn muốn tuyển maybes nữa đâu
chỉ có kết luận Hire hoặc No Hire, đừng kiểu Hire, but not for my team. như vậy rất là thô lỗ và ko tôn trọng mọi người
chân dung ứng viên: smart and get things done
cách nhận diện ứng viên smart: họ không phải giải thích 1 vấn đề lặp đi lặp lại nhiều lần. cách phỏng vấn hiệu quả là hãy đặt những câu hỏi mở, cùng các vấn đề cần giải quyết. thay vì những câu hỏi kiến thức cơ bản. tham khảo cuốn: How Would You Move Mount Fuji: Microsoft’s Cult of the Puzzle
- tự giới thiệu
- hỏi về dự án hiện tại của ứng viên, kỳ học vừa rồi bạn thích nhất môn nào, nói cho tôi nhiều hơn về nó đi. nhìn vào sự đam mê khi người đó nói về môn học, dự án. cách họ trình bày có dễ hiểu cho 1 người bình thường hay ko. nếu họ nói lý thuyết kỹ thuật quá. hãy hỏi: bạn có thể giải thích làm sao để bà của tôi cũng có thể hiểu được không?
- những câu hỏi lập trình dễ: why did you do it that way? what are the performance of your algorithm? what did you forget? where is your bug?
- câu hỏi về con trỏ, đệ quy, những câu hỏi kiểu "back of the envelope questions". ví dụ: có bao nhiêu người điều chỉnh đàn piano ở Hanoi? ứng viên bthg sẽ bỏ cuộc, nhưng smart candidate sẽ happy to try and estimate a reasonable number for you. Let see, giả sử có khoảng 1 triệu người sống ở Hanoi, có lẽ khoảng 1% trong số họ có piano. và 1 chiếc piano cần được điều chỉnh 2 năm 1 lần. và nó sẽ tốn khoảng 25 phút để điều chỉnh 1 chiếc đàn. all wrong, of course, nhưng ít nhất, họ đã attacking the problem. sau đó bạn lại tiếp tục giao tiếp với ứng viên. ok 25 phút, nhưng còn thời gian di chuyển để sửa những chiếc đàn thì sao? họ có thể lên lịch để tối ưu thời gian di chuyển, giống như shipper giao hàng những địa điểm trên cùng 1 tuyến đường.
- bạn có hài lòng không
- bạn có câu hỏi gì cho tôi không
kể cả đó là bad candidate, bạn vẫn sẽ muốn họ thích cty của bạn và ra về với những ấn tượng tích cực
thời điểm tốt nhất để ra quyết định Hire hoặc No Hire là 3 phút sau khi phỏng vấn. càng để lâu thì càng dễ quên kết quả phỏng vấn. nếu bạn đang phân vân về 1 ứng viên thì kết quả là No Hire, hãy kiên nhẫn chờ đợi ứng viên thích hợp nhất.
ngay khi tìm thấy ứng viên tốt nhất, hãy chốt deal nhanh chóng, giải quyết những vấn đề họ đang gặp phải như thuê nhà gần cty, ... hãy sẵn sàng trả tiền để giải quyết vấn đề của họ. đối xử với họ thật trân trọng như những samurai (trang 132)
trang 136: tiếp nhận 1 team cũ, đừng đánh giá dev qua số lượng dòng code họ viết mỗi ngày. việc đánh giá bằng các thang đo là vô nghĩa và hopeless. bạn càng cố tạo ra các tiêu chuẩn đo lường, dev sẽ càng cố thực hiện làm sao để đạt được chỉ số đó, trong khi có những việc khác có ý nghĩa hơn cần làm, nhưng nếu làm thì lại khiến chỉ số đo lường của dev bị giảm sút.
For example, you might decide to start counting the lines of code that each developer generates per day. The developers with the most lines of code get a bonus. Those with average lines of code get to keep their jobs. Drop into the bottom 20% and you’re fired. The problem, of course, is that it’s trivial, as a programmer, to increase the number of lines of code that you produce every day. Just put in some extra blank lines.
“Oh,” you say. “Good point. We should measure nonblank lines of code.” “OK,” say the programmers. “We’ll write lots of comments. Long expository paragraphs with three words per line.” “Well, I appreciate the comments, but that’s just cheating. I’m only going to measure actual lines of code.” “OK, so, if you’re not paying me to write comments, I won’t write comments at all. And I’ll spread out every function call so each argument is on its own line. It looks neat that way!” “Aargh!” you think. “Maybe there’s something I can measure that’s harder to game. I can measure statements, so spreading them out on multiple lines won’t change the count.” “OK. Well, I have this big block of obsolete code that I don’t need any more. I really should delete it, because it’s just going to confuse the heck out of the next programmer who reads the code. But if I delete 500 lines of code, it’s going to make me the worst programmer on the team for the next two months. So I’m going to have to just wrap it in a cryptic ‘if’ statement so it never executes. Maybe then you won’t penalize me.”
có những lập trình viên không giỏi tự viết code, nhưng debug lại rất đỉnh. có những lập trình viên rất giỏi tìm kiếm những công cụ để giải quyết vấn đề của họ. có thể 1 trong số đó là những người tệ, nhưng ngược lại cũng có rất nhiều ngời giỏi giải quyết vấn đề 1 cách nhanh chóng. vì vậy, đừng đánh giá người khác qua các thang đo hay chỉ số, nếu bạn không muốn phá hỏng những nhóm perfectly happy and productive.
trang 142: cách tốt nhất nếu bạn là 1 quản lý mới của team, hãy nói chuyện với từng người, để các thành viên trong team nhận xét đồng nghiệp của mình. sắp xếp vào 3 loại: great developer, need specific improvements và hopeless.
đừng sợ việc sa thải 1 người sẽ khiến team đi xuống, nếu bạn sa thải đúng người năng lực kém, sẽ khiến team bớt đi gánh nặng, và những great developer sẽ ko còn phải mệt mỏi đi fix bug. việc này cũng giống như dọn nhà, kết quả sau khi dọn sẽ khiến ngôi nhà sạch sẽ, ngăn nắp và dễ tìm kiếm đồ đạc hơn.
trang 143: When you use Econ 101 management, you’re encouraging developers to game the system. Suppose you decide to pay a bonus to the developer with the fewest bugs. Now every time a tester tries to report a bug, it becomes a big argument, and usually the developer convinces the tester that it’s not really a bug. Or the tester agrees to report the bug “informally” to the developer before writing it up in the bug tracking system. And now nobody uses the bug tracking system. The “bug count” goes way down, but the number of bugs stays the same, and you lose track of them. Developers are clever this way. Whatever you try to measure, they’ll find a way to maximize, and you’ll never quite get what you want. The biggest problem with Econ 101 management is that it’s not management at all: it’s an abdication of management. A deliberate refusal to figure out how things can be made better. It’s a sign that management simply doesn’t know how to teach people to do better work, so they force everybody in the system to come up with their own way of doing it. Instead of training developers on techniques of writing reliable code, you just absolve yourself of responsibility by paying them if they do. Now every developer has to figure it out on their own.
trang 160: identity management method, tạo không khí cty như 1 gia đình, ăn trưa cùng nhau trên 1 chiếc bàn lớn, cùng đi chơi, xem phim, đi bảo tàng, xem bóng chày, đá bóng, nhạc hội, ... mọi người tin tưởng và thân thiết với nhau. thứ hai, phải giải thích lý do rõ ràng để đồng nghiệp suy nghĩ và hiểu góc nhìn của mình.
trang 165: The Joel Test (những trang sau đó sẽ giải thích từng câu hỏi một)
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
mỗi câu trả lời yes sẽ tương đương 1 điểm. 12 điểm là perfect, 11 điểm chấp nhận được, nhưng từ 10 điểm trở xuống là vấn đề. rất nhiều cty đang running với chỉ 2 hoặc 3 điểm. điều này là vô cùng nghiêm trọng.
Best working environment -> Best programmers -> Best products -> Profit
công ty Fog Creek không có nhiều quản lý cấp trung, họ muốn nhân viên của mình phải hoàn toàn self-driven. những người thích chờ đợi sự hướng dẫn thì sẽ ko phù hợp với họ.
họ sẽ đưa ra offer cao hơn những cty khác để khi intern trở về trường, so sánh mức offer đó với những người bạn đồng trang lứa, họ sẽ có thể ra quyết định nhanh chóng. vì đã có thời gian thử thách khi intern, nên họ không phải nghĩ về việc người đó sẽ ko làm được việc. họ sẵn sàng trả lương cao hơn vì họ có nhiều thông tin về ứng viên hơn những công ty khác mà chỉ thực hiện phỏng vấn, thông qua thời gian thử thách trước đó.
họ trả cho sinh viên 750$/tuần + free housing + free lunch + free subway passes + các chi phí di chuyển khác nếu có.
cuốn sách Peopleware là kinh thánh trong việc quản lý công ty công nghệ
trang 50-60: nhìn từ góc độ của lập trình viên, họ muốn cty ntn? các tiện nghi khi làm việc. private offices, ghế công thái học thay vì ghế rẻ tiền, ghế công thái học tính ra có thể sử dụng lâu dài còn tiết kiệm hơn ghế rẻ mà nhanh hỏng, dev có thể ngồi nhiều giờ liền mà vẫn thoải mái, màn hình xịn, nên có ít nhất 2 màn hình 21 inches và cho dev thoải mái lên amazon mua sách technical. đồng nghiệp của họ như thé nào?
nếu bạn muốn thuê những người giỏi, coi họ là những chuyên gia , thì hãy tin tưởng chuyên môn của họ, đừng can thiệp vào chi tiết quá trình họ làm, như vậy sẽ gây ra sự khó chịu.
trang 72: một trong những cách tốt nhất để thu hút người tài là cho họ biết những điều thú vị mà họ sắp làm trong cty. cty có trang web chia sẻ kiến thức không? cho phép dev dành 1 tuần để đi xung quanh cty và lựa chọn dự án mà họ muốn join. đừng gò bó ngôn ngữ lập trình mà dev sẽ sử dụng. dev sẽ happier nếu được trải nghiệm với ngôn ngữ lập trình mới, framework, công nghệ mới.
lý tưởng của cty là gì? có khiến dev đồng cảm không
trang 78: lập trình viên giỏi thực sự không nghĩ ngợi nhiều về tiền, mà họ sẽ quan tâm những yếu tố ở phái trên, nhưng ko có nghĩa là bạn lợi dụng để trả họ mức lương thấp, hãy chủ động trả lương cao.
trang 83: những yếu tố bổ trợ khi chọn ứng viên:
- đam mê: cần bằng chứng: kinh nghiệm lập trình, mức độ thường xuyên code trên github, great programmers sẽ dành cả mùa hè tại computer camp, hoặc build những dự án riêng, thay vì đi làm thêm ở cửa hàng quần áo, ..., họ cập nhật kiến thức, công nghệ mới, hỏi là biết
- sự kén chọn: resume thay vì chỉ nói về bản thân ứng viên, họ còn nói về việc tại sao họ chọn cty này
- tiếng anh: quan trọng trong giao tiếp và giải thích ý tưởng của mình
- tư duy: GPA cao, tham gia những cuộc thi top coder, competitive chess, ACM contest, ...
- trường đại học: dựa vào số liệu trong quá khứ, họ sẽ lọc được tỉ lệ sinh viên trường nào có kỹ năng tốt, môi trường của đại học nào rèn luyện tốt cho sinh viên, ví dụ có những hoạt động quân đội, huấn luyện, các cuộc thi lớn
- làm việc với phần cứng: ví dụ ấn tượng với người biết về OCaml hơn là Java, biết assembly hoặc device driver hơn là Visual Basic hay PHP, C++ với ATL hơn là Perl, ...
- sự đa dạng trong trải nghiệm của ứng viên trong quá khứ
hãy nhớ trên đây chỉ là những yếu tố bổ trợ, quan trọng là phải phỏng vấn và thử việc, thì mới hiểu được chính xác khả năng của ứng viên
nếu resume của ứng viên ít thông tin, c�� thể test họ thông qua các câu hỏi lập trình, code trực tiếp như implement thuật toán đệ quy, thời gian họ cần để tìm và fix bug, họ có thể keep nine items in short-term memory không, ...
trang 97: sử dụng gọi điện (không bật cam để đảm bảo công bằng, ko nhìn mặt mà bắt hình dong) ��ể test ứng viên trước khi hẹn phỏng vấn trực tiếp, tránh mất thời gian và tiền bạc của cả 2 bên.
3 phần khi phỏng vấn = điện thoại:
- hỏi ứng viên về kinh nghiệm làm việc, giới thiệu bản thân: giúp họ giảm bớt căng thẳng với những câu hỏi đơn giản. dựa chọn câu trả lời của họ để đi vào chi tiết. ví dụ họ liệt kê nhiều dự án, thì hỏi vào công nghệ họ sử dụng, vai trò của họ trong dự án đó
- hỏi về kiến thức công nghệ: a wide-ranging, open design question: làm sao để bạn thiết kế 1 cấu trúc dữ liệu hoặc 1 block of code để làm việc X? với X là 1 vấn đề lớn và phức tạp. đặt series câu hỏi để hướng ứng viên giải quyết từng phần một. Here are some ideas to get you started: • How might you design a program that lets people play Monopoly with each other over the Internet?2 • What would be a good data structure for a photo editor? • How would you implement code to operate the elevators in a high rise? • How would you implement the rendering engine of a web browser? Tránh những câu hỏi kiểu như bạn sẽ code quicksort như thế nào? Hãy hỏi những câu liên quan đến độ phức tạp time/space, tradeoffs, performance
- cuối cùng là để ứng viên đặt câu hỏi ngược lại cho mình: nếu ứng viên thực sự hứng thú với cty, họ sẽ đặt những câu hỏi liên quan đến những yếu tố thu hút ở trang 50-60 phần bên trên.
trang 107: cần có ít nhất 6 người thực hiện phỏng vấn ứng viên, trong đó có ít nhất 2 người thực hiện pair programming với ứng viên (2 người này cũng là dev, không phải manager), tránh trường hợp 1 người nonprogrammer đi phỏng vấn 1 programmer. nếu ít nhất 2 trong 6 người phản đổi, thì sẽ ko chọn ứng viên này.
có 3 kiểu ứng viên:
- không biết gì, chỉ cần hỏi 2 hoặc 3 câu hỏi nhanh là đã phát hiện ra
- superstar, người dành cả cuối tuần để code Lisp compiler for fun, hay viết assemler for the Nintendo DS
- tầm trung, đông đảo nhất, người thường trả lời "maybes"
một trick đó là hãy nói ra sự khác nhau giữa superstar và maybes, vì bạn sẽ chẳng bao giờ còn muốn tuyển maybes nữa đâu
chỉ có kết luận Hire hoặc No Hire, đừng kiểu Hire, but not for my team. như vậy rất là thô lỗ và ko tôn trọng mọi người
chân dung ứng viên: smart and get things done
cách nhận diện ứng viên smart: họ không phải giải thích 1 vấn đề lặp đi lặp lại nhiều lần. cách phỏng vấn hiệu quả là hãy đặt những câu hỏi mở, cùng các vấn đề cần giải quyết. thay vì những câu hỏi kiến thức cơ bản. tham khảo cuốn: How Would You Move Mount Fuji: Microsoft’s Cult of the Puzzle
- tự giới thiệu
- hỏi về dự án hiện tại của ứng viên, kỳ học vừa rồi bạn thích nhất môn nào, nói cho tôi nhiều hơn về nó đi. nhìn vào sự đam mê khi người đó nói về môn học, dự án. cách họ trình bày có dễ hiểu cho 1 người bình thường hay ko. nếu họ nói lý thuyết kỹ thuật quá. hãy hỏi: bạn có thể giải thích làm sao để bà của tôi cũng có thể hiểu được không?
- những câu hỏi lập trình dễ: why did you do it that way? what are the performance of your algorithm? what did you forget? where is your bug?
- câu hỏi về con trỏ, đệ quy, những câu hỏi kiểu "back of the envelope questions". ví dụ: có bao nhiêu người điều chỉnh đàn piano ở Hanoi? ứng viên bthg sẽ bỏ cuộc, nhưng smart candidate sẽ happy to try and estimate a reasonable number for you. Let see, giả sử có khoảng 1 triệu người sống ở Hanoi, có lẽ khoảng 1% trong số họ có piano. và 1 chiếc piano cần được điều chỉnh 2 năm 1 lần. và nó sẽ tốn khoảng 25 phút để điều chỉnh 1 chiếc đàn. all wrong, of course, nhưng ít nhất, họ đã attacking the problem. sau đó bạn lại tiếp tục giao tiếp với ứng viên. ok 25 phút, nhưng còn thời gian di chuyển để sửa những chiếc đàn thì sao? họ có thể lên lịch để tối ưu thời gian di chuyển, giống như shipper giao hàng những địa điểm trên cùng 1 tuyến đường.
- bạn có hài lòng không
- bạn có câu hỏi gì cho tôi không
kể cả đó là bad candidate, bạn vẫn sẽ muốn họ thích cty của bạn và ra về với những ấn tượng tích cực
thời điểm tốt nhất để ra quyết định Hire hoặc No Hire là 3 phút sau khi phỏng vấn. càng để lâu thì càng dễ quên kết quả phỏng vấn. nếu bạn đang phân vân về 1 ứng viên thì kết quả là No Hire, hãy kiên nhẫn chờ đợi ứng viên thích hợp nhất.
ngay khi tìm thấy ứng viên tốt nhất, hãy chốt deal nhanh chóng, giải quyết những vấn đề họ đang gặp phải như thuê nhà gần cty, ... hãy sẵn sàng trả tiền để giải quyết vấn đề của họ. đối xử với họ thật trân trọng như những samurai (trang 132)
trang 136: tiếp nhận 1 team cũ, đừng đánh giá dev qua số lượng dòng code họ viết mỗi ngày. việc đánh giá bằng các thang đo là vô nghĩa và hopeless. bạn càng cố tạo ra các tiêu chuẩn đo lường, dev sẽ càng cố thực hiện làm sao để đạt được chỉ số đó, trong khi có những việc khác có ý nghĩa hơn cần làm, nhưng nếu làm thì lại khiến chỉ số đo lường của dev bị giảm sút.
For example, you might decide to start counting the lines of code that each developer generates per day. The developers with the most lines of code get a bonus. Those with average lines of code get to keep their jobs. Drop into the bottom 20% and you’re fired. The problem, of course, is that it’s trivial, as a programmer, to increase the number of lines of code that you produce every day. Just put in some extra blank lines.
“Oh,” you say. “Good point. We should measure nonblank lines of code.” “OK,” say the programmers. “We’ll write lots of comments. Long expository paragraphs with three words per line.” “Well, I appreciate the comments, but that’s just cheating. I’m only going to measure actual lines of code.” “OK, so, if you’re not paying me to write comments, I won’t write comments at all. And I’ll spread out every function call so each argument is on its own line. It looks neat that way!” “Aargh!” you think. “Maybe there’s something I can measure that’s harder to game. I can measure statements, so spreading them out on multiple lines won’t change the count.” “OK. Well, I have this big block of obsolete code that I don’t need any more. I really should delete it, because it’s just going to confuse the heck out of the next programmer who reads the code. But if I delete 500 lines of code, it’s going to make me the worst programmer on the team for the next two months. So I’m going to have to just wrap it in a cryptic ‘if’ statement so it never executes. Maybe then you won’t penalize me.”
có những lập trình viên không giỏi tự viết code, nhưng debug lại rất đỉnh. có những lập trình viên rất giỏi tìm kiếm những công cụ để giải quyết vấn đề của họ. có thể 1 trong số đó là những người tệ, nhưng ngược lại cũng có rất nhiều ngời giỏi giải quyết vấn đề 1 cách nhanh chóng. vì vậy, đừng đánh giá người khác qua các thang đo hay chỉ số, nếu bạn không muốn phá hỏng những nhóm perfectly happy and productive.
trang 142: cách tốt nhất nếu bạn là 1 quản lý mới của team, hãy nói chuyện với từng người, để các thành viên trong team nhận xét đồng nghiệp của mình. sắp xếp vào 3 loại: great developer, need specific improvements và hopeless.
đừng sợ việc sa thải 1 người sẽ khiến team đi xuống, nếu bạn sa thải đúng người năng lực kém, sẽ khiến team bớt đi gánh nặng, và những great developer sẽ ko còn phải mệt mỏi đi fix bug. việc này cũng giống như dọn nhà, kết quả sau khi dọn sẽ khiến ngôi nhà sạch sẽ, ngăn nắp và dễ tìm kiếm đồ đạc hơn.
trang 143: When you use Econ 101 management, you’re encouraging developers to game the system. Suppose you decide to pay a bonus to the developer with the fewest bugs. Now every time a tester tries to report a bug, it becomes a big argument, and usually the developer convinces the tester that it’s not really a bug. Or the tester agrees to report the bug “informally” to the developer before writing it up in the bug tracking system. And now nobody uses the bug tracking system. The “bug count” goes way down, but the number of bugs stays the same, and you lose track of them. Developers are clever this way. Whatever you try to measure, they’ll find a way to maximize, and you’ll never quite get what you want. The biggest problem with Econ 101 management is that it’s not management at all: it’s an abdication of management. A deliberate refusal to figure out how things can be made better. It’s a sign that management simply doesn’t know how to teach people to do better work, so they force everybody in the system to come up with their own way of doing it. Instead of training developers on techniques of writing reliable code, you just absolve yourself of responsibility by paying them if they do. Now every developer has to figure it out on their own.
trang 160: identity management method, tạo không khí cty như 1 gia đình, ăn trưa cùng nhau trên 1 chiếc bàn lớn, cùng đi chơi, xem phim, đi bảo tàng, xem bóng chày, đá bóng, nhạc hội, ... mọi người tin tưởng và thân thiết với nhau. thứ hai, phải giải thích lý do rõ ràng để đồng nghiệp suy nghĩ và hiểu góc nhìn của mình.
trang 165: The Joel Test (những trang sau đó sẽ giải thích từng câu hỏi một)
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
mỗi câu trả lời yes sẽ tương đương 1 điểm. 12 điểm là perfect, 11 điểm chấp nhận được, nhưng từ 10 điểm trở xuống là vấn đề. rất nhiều cty đang running với chỉ 2 hoặc 3 điểm. điều này là vô cùng nghiêm trọng.
This entire review has been hidden because of spoilers.
Read
November 3, 2018I had some problem about interviewing people and also how actually other people manage their teams. This book is like a treasure and that's not very controversial. It's hard to understate such a big impact this book has on me. I like it very much and highly recommended.
June 15, 2015
Joel is one of the best guys on the internet if you want to have read about software business, and this book follow the same quality.
Things change fast in software. The book was wrote before the Continuous Delivery got on the mouth of everybody, so the author tells about CI practices without mentioning it. I'm not criticizing it, contrariwise, I believe the author have merits in elaborating practices before all the movement start.
Things change fast in software. The book was wrote before the Continuous Delivery got on the mouth of everybody, so the author tells about CI practices without mentioning it. I'm not criticizing it, contrariwise, I believe the author have merits in elaborating practices before all the movement start.
February 6, 2017
This book proposed that if you have the Best Working Conditions => you get the Best Programmers => to develop the Best Software => which results in Profit!
The preface for this is the the quality of the work and the amount of time spent are simply uncorrelated. Productivity is 5 to 1 or 10 to 1 between programmers. You can't afford to be number two, or to have a "good enough" product. It has to be remarkably good, by which I mean so good that people remark about it. Having really, really, really talented software developers is your only hope for remarkableness. The great software developers, indeed, the best people in every field, are quite simply never on the market. The average great software developer will apply for, total, maybe, four jobs in their entire career. Whereas bad people are on the market quite a lot.
How to find people who are not on the market:
1. Go to the mountain
What conferences do they go to? Top end conferences or up and coming technologies
Where do they live?
What organizations do they belong to?
Which websites do they read?
Avoid advertising on general-purpose, large job boards as the bad people who are all over the market will apply and swamp you.
2. Internships
Students are lazy, with lots of options so can roll out of uni into a job. For the good ones try to attract them a year or two early - they might need some training but it is beneficial for both sides. You will likely need to have a contact at the Uni to find the best students.
If they are great make them a good offer for after graduation
3. Build your own community
Referalls
Tend to be from former companies tent do be from the same company which can be risky
Nobody wants to persuade their friends to apply for a job at their company only to get rejected
If you pay too much for referrals then they will coach people through the interview process
Work space
Private offices make programmers more productive and programmers prefer it
Putting on headphones with music to drown out the ambient noise reduces the ability of programmers to have useful insights
Office location
Does the office look exciting?
Good chairs don't cost that much more over their lifetime and if you take the cost per week it is cheaper than most other office facilities
People want to work with good, cheerful and happy people - Smart, and Gets Things Done and not a jerk
Managers can advise but they must be extremely careful to avoid having their "advice" interpreted as a command
Thing which annoy programmers
being told to use a certain programming language
people being promoted because of their ability to network rather than being promoted strictly on merit
being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.
People want to work on something cool, exciting new languages attract people
Young programmers, especially, are attracted to ideological companies
open source or the free software movement
social causes
benefiting society
Developers don't really care about money unless you're screwing up on the other things - it means people aren't really loving their job. If potential new hires just won't back down on their demands for outlandish salaries, you're probably dealing with a case of people who are thinking, "Well, if it's going to have to suck to go to work, at least I should be getting paid well.". That doesn't mean you can underpay people, because they do care about justice - you do have to pay competitively, as long as the salaries are basically fair they will be surprisingly low on their list of considerations. Offering high salaries is a surprisingly ineffective tool in overcoming problems
Resumes filtering
Be selective about how we advertise jobs to limit the amount of poor CVs
Use a strictly objective system of reviewing and sorting them, this is not a filtering criteria it is just to sort a big pile of CVs to find candidates who are most likely to be suitable so they get interviewed first
Passion
Jobs with computers or experience programming going back to a very early age
People who love programming often work on their own programming projects (or contribute to an open source project) in their spare time.
Sometimes certain programming languages or technologies indicate evidence of someone who loves to explore new technologies
Pickiness
Specific covering letter to the company, a custom cover letter is a sign that if we do make this candidate an offer they're likely to accept it
programmers who can communicate their ideas clearly - so neat, well structured and gramatically correct CVs
Brains
Math camp, programming competitons etc
Selectivity
Have they been through a rigorous review process before either for Uni or another company
Hard-core
Some development work is just harder than others, if they have the harder work then they stand out.
Diversity
Trying to bring new ideas into the team - to break people out of group-think and their own echo chamber
Great developers are likely to have enough options of places to work that any extra hoops will put them off bothering to apply.
Any technology you know right now might be out of date in a year, you are looking for people who pick things up quickly and can learn new things - so don't filter CVs on key words.
Phone Interview
Get the candidate to describe their career history and basically tell me about themselves. Looking for:
Technology: How did they do things. What was their role. CV validation
Politics: How the candidate handles challenges. Looking for people who got things done, even in the face of opposition. I'm looking for people who challenged the status quo, who overcame objections, and who made things happen. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?
Get the candidate to solve a technical problem. This should take something the candidate is familiar with but are unlikely to have implemented themselves. The aim is to look at their approach rather than getting them to speak code over the phone.
Get the candidate to ask questions about the company. This shows if they have done any research and what they are interested in.
Interviewing
6 interviewers, at least 5 peers not managers
If two people would reject the candidate end the interview at that point
Don't interview multiple people at once
There are three catorgories
Nos
Maybes - never hire maybes
Superstars
"Hire, but not for my team." is a no hire
"I'm a little concerned about" is a no hire
"Perhaps" is a no hire
It is much much better to reject a good candidate than hire a bad one
Look for people who are Smart, and Get things done.
Bad interviwers
Interviewers who just talk the entire time
People who are just looking for trivia e.g. "What's the difference between varchar and varchar2 in Oracle 8i?", smart does not mean knows trivia, aptitude is more important. Any skill set will be out of date in a couple of years
Good practice
Know as little as you can about the candidate in advance so it does not bias your opinion.
don't listen to recruiters opinions, don't ask around about the person before you interview them, never talk to the other interviewers about the candidate until you've both made your decisions independently. This provides the least amount of bias for or against the candidate.
Good candidates
are passionate, they might be passionate in favor or against but passion is key. Bad candidates just don't care.
can explain what they have done in a way a normal
look for signs of leadership, how have they pushed forward to get things done
write code and discuss it
pointers
recursion
data structures
ask them to find bugs in their code, even in the unlikely event there are none, to see how they approach it
Even if they are a bad candidate, you want them to like your company and go away with a positive impression.
Don't ask questions such as are they married, have kids etc even in a conversational way as this adds nothing and the candidate might feel this has been used against them which is likely illegal.
"Back of the envelope questions" e.g. How many piano tuners are there etc are a good way to provoke a conversation.
Do feedback instantly before you forget about the candidate
If 4 or 5 people think this person is worth hiring then you likely won't go wrong
If you do have to say no to someone, do it quickly and respectfully
Great people are much, much more valuable than average people - three to ten times as productive, costing 20% or 30% more
Teams
Why don't they work?
performance measurements and incentives - devastatingly ineffective
Remove the parts which are not working.
Anonymous peer ranking with the options:
Great developer
Needs specific improvements
Hopeless
Firing poor performers can increase moral because poor performers are taking time away from the good performers. If you can't fire them move under-performers to a place where they can't cause any impact.
Putting in things which do work
Three approaches to leadership
The Command and Control Method
Tell people what to do and tell them off if they don't do it
Disadvantages for developers
Smart people rebel against doing what they are told without good reasoning
Micromanaging would require a huge amount of managers to micromanage everything. That or you hit and run not seeing the consequences of your decisions.
The management have the least knowledge so are ill placed to make decisions.
The Econ 101 Method
Give them financial rewards and punishments to create incentives, aka replaces intrinsic motivation with extrinsic motivation.
When you stop paying the bonus, or when they decide they don't care that much about the money, they no longer think that they care, even though they might have cared before you started giving them a bonus for it.
They'll find some way to optimize for the specific thing you're paying them, without actually achieving the thing you really want.
You're encouraging developers to game the system.
You can't abdicate your responsibility to train your people by bribing them.
The Identity Method
Make people identify with the goals you're trying to achieve
The Identity Method is a way to create intrinsic motivation.
Make a point of of eating lunch with my coworkers. It's hard to understate what a big impact this has on making the company feel like a family, in the good way.
by sharing information people will do the right thing
The preface for this is the the quality of the work and the amount of time spent are simply uncorrelated. Productivity is 5 to 1 or 10 to 1 between programmers. You can't afford to be number two, or to have a "good enough" product. It has to be remarkably good, by which I mean so good that people remark about it. Having really, really, really talented software developers is your only hope for remarkableness. The great software developers, indeed, the best people in every field, are quite simply never on the market. The average great software developer will apply for, total, maybe, four jobs in their entire career. Whereas bad people are on the market quite a lot.
How to find people who are not on the market:
1. Go to the mountain
What conferences do they go to? Top end conferences or up and coming technologies
Where do they live?
What organizations do they belong to?
Which websites do they read?
Avoid advertising on general-purpose, large job boards as the bad people who are all over the market will apply and swamp you.
2. Internships
Students are lazy, with lots of options so can roll out of uni into a job. For the good ones try to attract them a year or two early - they might need some training but it is beneficial for both sides. You will likely need to have a contact at the Uni to find the best students.
If they are great make them a good offer for after graduation
3. Build your own community
Referalls
Tend to be from former companies tent do be from the same company which can be risky
Nobody wants to persuade their friends to apply for a job at their company only to get rejected
If you pay too much for referrals then they will coach people through the interview process
Work space
Private offices make programmers more productive and programmers prefer it
Putting on headphones with music to drown out the ambient noise reduces the ability of programmers to have useful insights
Office location
Does the office look exciting?
Good chairs don't cost that much more over their lifetime and if you take the cost per week it is cheaper than most other office facilities
People want to work with good, cheerful and happy people - Smart, and Gets Things Done and not a jerk
Managers can advise but they must be extremely careful to avoid having their "advice" interpreted as a command
Thing which annoy programmers
being told to use a certain programming language
people being promoted because of their ability to network rather than being promoted strictly on merit
being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.
People want to work on something cool, exciting new languages attract people
Young programmers, especially, are attracted to ideological companies
open source or the free software movement
social causes
benefiting society
Developers don't really care about money unless you're screwing up on the other things - it means people aren't really loving their job. If potential new hires just won't back down on their demands for outlandish salaries, you're probably dealing with a case of people who are thinking, "Well, if it's going to have to suck to go to work, at least I should be getting paid well.". That doesn't mean you can underpay people, because they do care about justice - you do have to pay competitively, as long as the salaries are basically fair they will be surprisingly low on their list of considerations. Offering high salaries is a surprisingly ineffective tool in overcoming problems
Resumes filtering
Be selective about how we advertise jobs to limit the amount of poor CVs
Use a strictly objective system of reviewing and sorting them, this is not a filtering criteria it is just to sort a big pile of CVs to find candidates who are most likely to be suitable so they get interviewed first
Passion
Jobs with computers or experience programming going back to a very early age
People who love programming often work on their own programming projects (or contribute to an open source project) in their spare time.
Sometimes certain programming languages or technologies indicate evidence of someone who loves to explore new technologies
Pickiness
Specific covering letter to the company, a custom cover letter is a sign that if we do make this candidate an offer they're likely to accept it
programmers who can communicate their ideas clearly - so neat, well structured and gramatically correct CVs
Brains
Math camp, programming competitons etc
Selectivity
Have they been through a rigorous review process before either for Uni or another company
Hard-core
Some development work is just harder than others, if they have the harder work then they stand out.
Diversity
Trying to bring new ideas into the team - to break people out of group-think and their own echo chamber
Great developers are likely to have enough options of places to work that any extra hoops will put them off bothering to apply.
Any technology you know right now might be out of date in a year, you are looking for people who pick things up quickly and can learn new things - so don't filter CVs on key words.
Phone Interview
Get the candidate to describe their career history and basically tell me about themselves. Looking for:
Technology: How did they do things. What was their role. CV validation
Politics: How the candidate handles challenges. Looking for people who got things done, even in the face of opposition. I'm looking for people who challenged the status quo, who overcame objections, and who made things happen. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?
Get the candidate to solve a technical problem. This should take something the candidate is familiar with but are unlikely to have implemented themselves. The aim is to look at their approach rather than getting them to speak code over the phone.
Get the candidate to ask questions about the company. This shows if they have done any research and what they are interested in.
Interviewing
6 interviewers, at least 5 peers not managers
If two people would reject the candidate end the interview at that point
Don't interview multiple people at once
There are three catorgories
Nos
Maybes - never hire maybes
Superstars
"Hire, but not for my team." is a no hire
"I'm a little concerned about" is a no hire
"Perhaps" is a no hire
It is much much better to reject a good candidate than hire a bad one
Look for people who are Smart, and Get things done.
Bad interviwers
Interviewers who just talk the entire time
People who are just looking for trivia e.g. "What's the difference between varchar and varchar2 in Oracle 8i?", smart does not mean knows trivia, aptitude is more important. Any skill set will be out of date in a couple of years
Good practice
Know as little as you can about the candidate in advance so it does not bias your opinion.
don't listen to recruiters opinions, don't ask around about the person before you interview them, never talk to the other interviewers about the candidate until you've both made your decisions independently. This provides the least amount of bias for or against the candidate.
Good candidates
are passionate, they might be passionate in favor or against but passion is key. Bad candidates just don't care.
can explain what they have done in a way a normal
look for signs of leadership, how have they pushed forward to get things done
write code and discuss it
pointers
recursion
data structures
ask them to find bugs in their code, even in the unlikely event there are none, to see how they approach it
Even if they are a bad candidate, you want them to like your company and go away with a positive impression.
Don't ask questions such as are they married, have kids etc even in a conversational way as this adds nothing and the candidate might feel this has been used against them which is likely illegal.
"Back of the envelope questions" e.g. How many piano tuners are there etc are a good way to provoke a conversation.
Do feedback instantly before you forget about the candidate
If 4 or 5 people think this person is worth hiring then you likely won't go wrong
If you do have to say no to someone, do it quickly and respectfully
Great people are much, much more valuable than average people - three to ten times as productive, costing 20% or 30% more
Teams
Why don't they work?
performance measurements and incentives - devastatingly ineffective
Remove the parts which are not working.
Anonymous peer ranking with the options:
Great developer
Needs specific improvements
Hopeless
Firing poor performers can increase moral because poor performers are taking time away from the good performers. If you can't fire them move under-performers to a place where they can't cause any impact.
Putting in things which do work
Three approaches to leadership
The Command and Control Method
Tell people what to do and tell them off if they don't do it
Disadvantages for developers
Smart people rebel against doing what they are told without good reasoning
Micromanaging would require a huge amount of managers to micromanage everything. That or you hit and run not seeing the consequences of your decisions.
The management have the least knowledge so are ill placed to make decisions.
The Econ 101 Method
Give them financial rewards and punishments to create incentives, aka replaces intrinsic motivation with extrinsic motivation.
When you stop paying the bonus, or when they decide they don't care that much about the money, they no longer think that they care, even though they might have cared before you started giving them a bonus for it.
They'll find some way to optimize for the specific thing you're paying them, without actually achieving the thing you really want.
You're encouraging developers to game the system.
You can't abdicate your responsibility to train your people by bribing them.
The Identity Method
Make people identify with the goals you're trying to achieve
The Identity Method is a way to create intrinsic motivation.
Make a point of of eating lunch with my coworkers. It's hard to understate what a big impact this has on making the company feel like a family, in the good way.
by sharing information people will do the right thing
October 6, 2017
It sounded more like an advertisement of FogCreek. However, it did have some interesting highlights for managers and recruiters.
I wonder the author used to hire such smart people and still FogCreek end up developing products like FogBugz :/
I wonder the author used to hire such smart people and still FogCreek end up developing products like FogBugz :/
June 22, 2014
Простая, короткая, многие советы звучат как из уст Капитана Очевидности. Но прочитать стоит, если еще не сделали этого.
August 22, 2022
Joel Spolsky's on hiring in a nutshell. I like the motto: "Smart and Get Things Done".
October 23, 2021
Good to revisit many concepts of what engineering leads/managers/founders face frequently. Also good to demystify some ideas present in the software industry.
About good developers on the market:
"The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot. They get fired all the time, because they can’t do their job. Their companies fail—sometimes because any company that would hire them would probably also hire a lot of unqualified programmers, so it all adds up to failure—but sometimes because they actually are so unqualified that they ruined the company. Yep, it happens."
One thing that programmers don't care about:
"They don’t care about money, actually, unless you’re screwing up on the other things. If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”"
And a funny one:
"I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first-year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4-years old. They are having a good ol’ time learning C or Pascal in college, until one day their professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything anymore. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good-looking members of the appropri- ate sex in their Comp Sci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers."
About good developers on the market:
"The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot. They get fired all the time, because they can’t do their job. Their companies fail—sometimes because any company that would hire them would probably also hire a lot of unqualified programmers, so it all adds up to failure—but sometimes because they actually are so unqualified that they ruined the company. Yep, it happens."
One thing that programmers don't care about:
"They don’t care about money, actually, unless you’re screwing up on the other things. If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”"
And a funny one:
"I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first-year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4-years old. They are having a good ol’ time learning C or Pascal in college, until one day their professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything anymore. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good-looking members of the appropri- ate sex in their Comp Sci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers."
This entire review has been hidden because of spoilers.
May 14, 2020
Don't know what the idea behind the formatting of the book is. The extra extra wide margins and the huge font are probably to make the "book" at least thick enough to be seen as a book rather than the booklet it is.
As for the content, it starts off like any good self-help guru autobiography by making statements that most people would agree on so as to make the reader think "Oh! That's true". Like saying that ergonomic chairs are ergonomic and then breaking down the cost over the number of toilet papers that can be bought from that money. Simple stuff. And moving on to making proclamations after this.
Most of the stuff is self contradictory with explicit disclaimers that it worked for the author but it might not work for others. Actually, we can't say with any degree of certainty that those specifics were what went right. Statistically speaking, it was probably many things that were not noticed that brought the success.
The self-contradiction is so much as to make all advice useless and is easy to see in every section and across sections if you don't just read everything in the narrow context of the page.
In short, if I had a reading list that I could give to my past self to make sure that I read those books at least once, I would not put this book on it.
As for the content, it starts off like any good self-help guru autobiography by making statements that most people would agree on so as to make the reader think "Oh! That's true". Like saying that ergonomic chairs are ergonomic and then breaking down the cost over the number of toilet papers that can be bought from that money. Simple stuff. And moving on to making proclamations after this.
Most of the stuff is self contradictory with explicit disclaimers that it worked for the author but it might not work for others. Actually, we can't say with any degree of certainty that those specifics were what went right. Statistically speaking, it was probably many things that were not noticed that brought the success.
The self-contradiction is so much as to make all advice useless and is easy to see in every section and across sections if you don't just read everything in the narrow context of the page.
In short, if I had a reading list that I could give to my past self to make sure that I read those books at least once, I would not put this book on it.
March 19, 2018
The one thing that this book taught me for sure is that I wouldn't ever get a job at Fog Creek (author's company) ;) The book is from 2007, which means it is pretty old (as for software development world standards) and some of the advice is deprecated. However, I found most of the stuff at least enjoyable and informative.
It is probably one single book that virtually every HR person and manager that would like to hire developers should read (mostly because it is a really quick read and provides actual real world advice). Author has a bright style and made the book quite funny, so I guess it was time well spent. Also the best piece of advice from this book is in the title. The 'and' part of it is crucial. ;)
It is probably one single book that virtually every HR person and manager that would like to hire developers should read (mostly because it is a really quick read and provides actual real world advice). Author has a bright style and made the book quite funny, so I guess it was time well spent. Also the best piece of advice from this book is in the title. The 'and' part of it is crucial. ;)
July 21, 2021
A book written by a "tech-guru" searching for "rockstar" developers. Easy to read. Easy to get irritated by some of the views of the writer. First of all it's a book of personal experience of the writer. No proper justification, no data. Division of people to smart and hopelessly dumb is pure prejudice. Of course it is useful to read it. First of all somebody can see the views of the leaders in the tech industry. Second it contains interesting things in order to improve your team and your hiring but unfortunately mainly things you need to "buy" in order to achieve the goal of the extraordinary. I think it directs to a very specific audience with a lot of resources and probably in the US.
March 1, 2018
My expectations were quite different for that book. When I read "Smart and gets things done", I was like "Cool, I will learn a way to judge which people are smart and will work hard". Nothing of the sort. The book shows you the most extensive practices to hire the best 0.00001% of programmers.
Yeah, thanks for that. I mean, it's good to know and strive for it, but unfortunately not a lot of companies can do that, just because it's not always up to the employees.
It's still a good book, but probably the title has a context that one is not necessarily aware of.
Yeah, thanks for that. I mean, it's good to know and strive for it, but unfortunately not a lot of companies can do that, just because it's not always up to the employees.
It's still a good book, but probably the title has a context that one is not necessarily aware of.
June 13, 2018
Lots of great hiring and management tips, with easy to understand/read stories. I've learnt a lot from this book. There's not just ideas, there are ways that you can implement them. Definitely would be much easier to change a small organization, but they do talk about how you can try to push for change even in a bigger organization.
This book will definitely shape how I would approach hiring and managing a team.
This book will definitely shape how I would approach hiring and managing a team.
February 16, 2019
Good advice doesn't get old. While some of the mentioned technologies, tools, etc. are obviously outdated by now, the overall premise hasn't changed. It actually has gotten a lot harder to find good (software) developers.
I can still recommend all of the ideas in this book - tailor it to your business, location and customers, of course.
I can still recommend all of the ideas in this book - tailor it to your business, location and customers, of course.
March 11, 2019
Joel always gets straight to the point and there are some lovely little nuggets in this pocket rocket of a book. Some of the ideas might be transferable to hiring other types of people too (and some are very definitely not), but if you want to hire good writers of software and save time doing it, then I highly recommend you give this book a read.
November 24, 2019
This is a bible for engineering managers. Joel Spolsky with his tongue in cheek humour has laid down the golden rules for hiring the best engineers in software. Words fall short when it comes to describing this book, so I am going to leave it up to you to decide but do remember, this is one book you'd definitely want to read if you were in the tech industry.
June 5, 2021
Short, funny and written by a programmer. These are the ingredients you would like in a book that guides you on how to hire the best talent in software. This books gives you exactly that, and some more if you also want to learn how to take care of the “Samurais” of the modern world after hiring them.
September 30, 2018
I am following Joel and have read other books of him, this one seems like a summary of what he wrote in the past about hiring.
- How to advertise your positions to attract talented candidates.
- How to read and value resumes
- How to do a phone screening
...
- How to advertise your positions to attract talented candidates.
- How to read and value resumes
- How to do a phone screening
...
December 6, 2020
Written as hiring manual the book goes beyond how to: it covers the culture and motivation of knowledge workers. Fun to read old text which explains what I have learned by doing. One more lesson to read great books while solving life puzzles
February 28, 2018
This guy knows his shit. Some parts are outdated though. Chuzpe included!
April 3, 2018
Some good key points here, works as a good starting point or a refresher. It is over 10yrs old though, which does need bearing in mind
June 6, 2018
Good read but quite some information not relevant to finding the best technical talent
August 7, 2018
changed how we evaluate technology talent
January 9, 2019
If you want to understand the keys to hiring good tech's or just good employees in any context this gives you some great ideas.
Read
November 5, 2019Хорошая книга о поиске технических талантов
Обратите внимание на процессы и нюансы найма
Обратите внимание на процессы и нюансы найма
Displaying 1 - 30 of 103 reviews