How to hire and keep engineers happy public
Download as PPTX, PDF6 likes2,915 views
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.
How to hire and keep engineers happy public
- 1. How to hire and keep engineers happy Wharton School of Business, San Francisco March 16th, 2013
- 2. Why is it so 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 are smart hardworking engineers willing to work for relatively little money, but you have to make it up in other ways
- 4. Hiring • Your first few 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 Technical Co-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. Low technical 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 to engineers • 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 your startup offer that Google can’t? • Individual mentoring • Chance to own a big piece of code • A chance to move up quickly
- 10. “Moneyball” as applied to 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 • Engineers are 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 a process • 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 • Used to 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 • Code Review 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 in software 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 engineers good 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 critical decisions: 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 by far 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 • Considered HARMFUL! 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 of your 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)