Downloaded 37 times
Uploaded byPiaw Na
How to hire and keep engineers happy public
The document provides tips for hiring and retaining software engineers. It emphasizes that the first few engineering hires are critical and technical skills should be prioritized over degrees or certifications. Engineers want challenging work, decision-making power, and good working conditions. Compensation should include both monetary and non-monetary rewards like mentoring and ownership. Engineering culture and tools are also important to establish processes and high standards. Managing technical debt, providing good hardware, and avoiding "engineering ladders" can help create a strong engineering organization.
More Related Content
Similar to How to hire and keep engineers happy public
How to hire and keep engineers happy public
- 1. How to hireand keep engineers happy Wharton School of Business, San Francisco March 16th, 2013
- 2. Why is itso hard to find young and hungry programmers? David "Pardo" Keppel: "There's no shortage of smart hardworking engineers. There's a shortage of smart hardworking engineers willing to work for very little money." • http://tinyurl.com/cc2jgth
- 3. Corollary • There aresmart hardworking engineers willing to work for relatively little money, but you have to make it up in other ways
- 4. Hiring • Your firstfew hires are critical • If you’re non-technical, find someone else to do your engineering interview. • Important qualities: – Technically sound – Able to translate requirements into code – Able to transcend the immediate problems to find generalized solutions – Passionate about building tools and automation
- 5. Find a TechnicalCo-founder • Case studies: – AirBnB – Intuit – Apple • Learn to Code – It’s easy to learn to code – It’s hard to code well
- 6. Hiring mistakes 1. Lowtechnical bar “I can’t see myself working at a company where the toughest question is, ‘what’s the difference between a linked list and an array’” --- engineer who turned down a startup 2. No decision making by engineer “A mere matter of programming” “The co-founders go home and talk and announce decisions the next day.” 3. Poor engineering environment “They were too cheap to buy us phones to test our mobile software on.”
- 7. Reaching out toengineers • Best engineers usually have jobs or aren’t otherwise looking • LinkedIn • StackOverflow • Technical mailing lists
- 8. Writing Job Descriptions •Don’t make job descriptions sound like they’re written by HR • Big booboos: – Asking for N years of experience in X – Asking for N years of experience in X when X has been around for n < N – Over-emphasis on degrees and technical credentials (especially certifications)
- 9. What can yourstartup offer that Google can’t? • Individual mentoring • Chance to own a big piece of code • A chance to move up quickly
- 10. “Moneyball” as appliedto Engineering • In big organizations, big titles correspond to political skill • Better to hire quality engineers who’ve proven themselves poor at politics
- 11. Things to do •Hire experienced engineers with management experience • Challenge engineers during interview • Be realistic about what an engineer will accept
- 12. Managing Engineers • Engineersare creative people, give them lots of freedom, right? • Yes and No • Unlike art, in engineering, process matters – Brittle solutions versus resilient solutions – 10X engineers make a huge difference – Context matters
- 13. Creating Feasible Projects •MBAs, take a programming class! – Learn to program python – Learn to program Excel/Visual Basic • Important to understand – What’s easily done within current technology – What requires developing new technology – What’s not easily done with technology (at all!)
- 14. Compensation is hard,let’s go shopping • The pay for performance myth • Creativity is decreased by incentives • Best solutions come from intrinsic motivation
- 15. Engineering is aprocess • Specifications • Design • Implementation • Testing • User feedback Keeping this cycle as short as possible is important!
- 16. Recurring Engineering Screwups •Incompetent Engineers – “fail whale” – Low scalability (crashing in under 1000qps) – Trying to solve in software what’s easily done in hardware • Poor management – Incurring technical debt without paying it down – Focus on new features rather than clean code – Failing to spend on adequate hardware – Poor engineering culture
- 17. Engineering Tools • Usedto be able to judge the soundness of a technical team by the tools they used: – Visual Source Safe – incompetent and stupid – RCS/CVS – cheap but barely competent – Perforce – competent and technically smart • Now much harder: – Git is fashionable and free – Plenty of good alternatives
- 18. Engineering Tools • CodeReview Tools: – Essential and worth the investment • Continuous Build/Integration – Roll your own or use something prebuilt • Bug Tracking – History suggests that every company eventually builds their own if they last long enough • If your team does not use/build these tools, you have a problem!
- 19. Never solve insoftware what you can do in hardware • High scalability is now easily resolved with modern hardware – Apply SSDs to MySQL – High performance machines are cheap • Do back of envelop calculations – Intel X-25M: 8600 IOPS ($300) – Fusion IO: 135,000 IOPS ($3000) – Texas Memory Systems RAM SAN: 400,000 4K Random IOPS ($100,000)
- 20. Dynamic Languages • Ruby/Rails • Python/Django • Lisp • Erlang • Easy to launch, might prove difficult to scale • Static type checking is a “safety net” most programmers need but refuse to admit to needing
- 21. Technical Debt • Incurred every time you change a specification • Switch platforms • Add an unplanned feature • Push engineers to “just get it done” Technical debt is like credit card debt: if you only pay the minimum, you’ll never get out from under it, and it depletes capital/engineering effort better spent elsewhere.
- 22. Buy your engineersgood hardware • SSD: $300 • Typical engineering salary: $100,000 ($50/hr) • Each compile saves 30s • 50 compiles/day • ROI: 3 weeks! (Each month saves you an 8 hour day!)
- 23. Engineering Culture • Develop a culture of excellence • “No assholes” • Promote from within • Culture is: – Who you promote – Who gets the big bonuses – Whether you get recognized for doing the grungy painful work nobody else wants to do
- 24. Strong Engineering Culture •Counter-intuitively, created by tough interviewing culture • Interviewing considered important, highly valued and respected engineers do not shirk interviewing • High standards->Esprit de corps • Hiring mistakes are quickly corrected • Caterine Fake: “Never stronger than your first few engineers.”
- 25. Management • Most criticaldecisions: who gets put into management • Yishan Wong’s Theory: if you don’t promote from within early enough, and you don’t prepare a “deep bench” internally, you are doomed to always hire managers from outside.
- 26. Compensation • Informal compensation – Praise/recognition – Comp time – Better hardware – Work from home privileges • Formal compensation – Stock – Salary – Bonus
- 27. Compensation • Praise/Recognition byfar most under-utilized! – Engineers/Engineering managers don’t like to “stroke” people • Do not conflate hardware requirements with perks! • Important to recognize: different people have different requirements
- 28. Engineering Ladder • ConsideredHARMFUL! Avoid for as long as possible. (Most startups only introduce this at 100 engineers. Google waited until well past Dunbar’s number—300 engineers before introducing engineering ladder) • Once you have one, you have to think hard about how you promote and who you promote. Most engineering ladder job descriptions are laughable.
- 29. Managing by Objectives •Intel process: employees set goals, then grade themselves. Adopted by Google and several other technology firms. • Engineering leaders/managers should guide objective setting. Grading should be done by engineering managers in conjunction with engineers. • Don’t go crazy with objectives. Most important consideration: “Feedback should be constant. If you’re surprised by your annual performance review, then your manager screwed up!”
- 30. Summary • Think ofyour organization (especially engineering) as a product • Your customers are the engineers • Consider what sort of problems you need to solve and build your product accordingly)
- 31.