Attracting engineers

A few weeks ago I wrote about the challenges non-technical entrepreneurs face finding good developers to build their idea. But even for a capable entrepreneur, finding talent and getting that first bit of interest isn’t the end of the challenge. I’ve seen more than a few smart, well-networked, -resourced and -researched entrepreneurs struggle to attract technical talent to a genuinely promising business because, well, us programmers are odd types and you need to understand what we want. Many aspiring entrepreneurs seem think that developers will be attracted to the same things that they are: an impossibly huge ambition, constant uncertainty and change, a statistically unlikely shot at millions of dollars, that kind of thing. For better or worse, that’s not generally true. Remember: great engineers have many attractive options. To attract them to your company you need to understand what they want, and make sure you can provide it (along with the entrepreneurial excitement).

Everyone’s different, but in my experience really good technically-minded people tend to value two things above all else: working with great people, and working on technically interesting problems. Working with great people–at least as good as oneself–amplifies the impact of your work. When you can trust that your peers are capable, motivated, intelligent problem-solvers it’s easier to see how your work will be valuable as part of a quality end product, as opposed to a jewel buried somewhere in a steaming pile of code. Talented peers will appreciate your talent and effort and be best able to arrange their own work to complement yours. Great people provide constant opportunities for learning: from how they work, from their existing expertise, and together as you explore new ground. And the best technical minds will attract even more great people to work with them, compounding all these benefits. Working with great people is the number one attraction for most good developers I’ve met.

Interesting problems are a close second. Solving problems is the essence of working with computers: problems of domain modelling, problems of complexity, problems of user interface, problems of scale, and so on. Sure, developers and engineers spend a lot of time writing code, expressing their solution formally, but the really interesting bit is solving the problem in the first place (often concurrently with writing the code). That’s also the most valuable part to your company in the long run. Solving problems presents constant challenges and opportunities for growth and learning. Solving hard problems, especially in collaboration with talented colleagues, is a realisation of one’s potential, the very top of Maslow’s hierarchy viewed through an engineer’s eyes. Without interesting problems, a developer is likely to get bored and realise their job could be done by someone with lesser talents. Now, you might not have technically interesting problems early on in your new company (the problems of making sure you’re building the right product are far more urgent), but you need the promise that you won’t shy away from them when they arise, that you’ll allow your team to stretch. Great people want a challenge.

After these two values, working with great people on interesting problems, people’s values vary a lot more. Your entrepreneurial vision, potential impact, company culture, work environment, technical infrastructure, decision-making freedom etc. are all really important. But don’t think that they’re enough without a promise of great peers and great problems.

For your first couple of technical hires, of course, you can’t demonstrate the quality of your as-yet-unformed team. The best you can do is promise to engage an outside technical mentor to help you hire  good people, and hand technical hiring over to the development team as soon as practical so that they can control the quality of future hires.

For many potential candidates the first impression they’ll get about working for your company will be a job ad, on your website or elsewhere. This job description (and the rest of your online presence) needs to sell the benefits of working with you. That means you need to sell your talented team and interesting problems, and you need to sell them above your ill-defined vision or potential riches. I’ve drafted up a mock software engineer job ad to help people who don’t know where to start. It’s based on those I wrote for Posse where they were very successful (and Posse’s still always on the lookout for great people). It’s missing a few specifics and anything about company vision and culture will of course depend on the company. But it’s a job ad that I would have been interested in, and aimed at the kinds of people I’ve most enjoyed working with in the past and hope to in the future (stay tuned!).


[Company] is seeking talented and ambitious engineers to help us build the future of [product area].

You might be an experienced engineer with multiple specialties or a class-topping graduate keen to learn while applying your talents to hard problems. At [Company] you will develop creative and innovative solutions to novel problems amongst accomplished peers. We are a small, growing team and you will have a great impact on the design and development of our product. We’re particularly interested if you have [specialty] experience, or are keen to get dirty learning about it.


Our engineers:

  • design, implement and test clear, elegant code (we use [technologies]);
  • work with with other brilliant developers to craft robust systems and beautiful interfaces;
  • sweat the details with product management and designers to implement compelling features;
  • develop tools and processes to continually improve our team’s productivity; and
  • share knowledge, teach, and learn from colleagues.


Our team all:

  • have a passion for developing creative solutions in a team, translating abstract concepts into code, and understanding and adapting to our users;
  • demonstrate strong technical design sense across both the big picture and the devilish details;
  • derive joy from conquering complexity through abstracting, refactoring, and applying well-understood (and sometimes novel) principles and patterns;
  • know how to balance engineering perfection with shipping product;
  • are independent, enthusiastic, and keen to lead talented peers in innovation; and
  • are in-tune with the [industry or vertical].


[Company cultural values or mission]. We release early (daily!) to learn from real users and react quickly. We work end-to-end, so each engineer understands their work in depth. We encourage everyone to learn and share knowledge with others to improve our craft. We exalt engineering productivity and quality and continually improve our tools and processes. We are building a culture and a codebase that are a joy to work in.

[Company] hires only the best and brightest. We offer [compensation and benefits outline]. Other benefits include [more benefits!], plus other random acts of appreciation.

About Company

[Company vision, product outline, challenges]

[Company back-story, market opportunity, notable investors & backers, other evidence of likely impact]


Note this slight tweak to a traditional responsibilities and requirements list: instead of listing desired traits of the applicant, I’ve listed the actual traits of existing staff applicants might work with. You don’t need to be this explicit about it, but in describing applicant requirements a job ad implicitly describes the attributes of your existing or future team, and this is the most important attractor of new talent. This is an ad, the beginning of the pipeline, not an acceptance checklist. Its role is like that of a resume: to get to interview. So sell the experience of working at your company by selling the future peers of successful applicants.

Without getting into details, the ad also makes it clear that interesting problems and challenges exist. With more knowledge your product you can probably be more specific, but details might be better left to a discussion. You should add interesting nuggets of information about your company. Maybe you have some particularly distinguished team members, a unique technical challenge, or some great traction stats. Any of these will help you stand out from other opportunities. And, if you can, add some personality to the mix. Let your company culture shine through. BigCommerce did a great job of this with a Hypnotoad hook, boosting views of their add some by 10 times.

Note also what this ad doesn’t have. There’s no laundry list of specific technical knowledge or experience. There’s a placeholder mentioning what technologies the company presently uses, but you should be looking for people who can take part in decisions about what tools are right for the job. Limiting applicants to specific prior experience is really just limiting your pool of candidates to people who don’t like change. There’s definitely no “N years experience with X” requirement. A flexible team is made of people who learn fast, and you’ll be far better off, a few months down the track, having hired someone who is super-smart and learns fast but has little direct experience with your tech stack than someone who’s been using the same tools for 5+ years and likes it that way. I’ve had this approach validated multiple times by people I’ve hired. Flexibility is super-important when your company is young, so look for smart, motivated generalists over experienced but less-driven experts.

Some other recruitment drives that I’ve been particularly drawn to are those of Asana and Quora. Note the emphases on colleagues, learning, challenges and impact, as well as each company’s mission. Feel the culture of the two companies in the expression of who they want to hire. See how the “requirements”, such as they are, tend to be phrased more like character attributes than specific experience checks. If the teams at these companies live up to these descriptions then they are the kind of people that great developers aspire to be, and will fall over themselves to work with.

I hope that’s helpful for some of you on the hunt for early technical employees. And if the mock ad appealed to you as a developer, well, I’m sure I’ll be building another team like that someday soon.

4 Thoughts on “Attracting engineers

  1. Nice writeup. I definitely believe we should be doing more in Australia to do this. So information like this is very helpful.

    Overseas, it’s been done where a company will hire a limosine to pick up a hot engineer to offer them a position. I wish we could see more of that here.

  2. Hellz yes, this is great. Thanks Alex. Love the advice on not laundry listing technologies or years of experience, and adding some personality. I did a quick session on this topic at General Assembly Sydney recently

  3. Tony Souter on March 31, 2013 at 9:24 pm said:

    Alex, I’ve only just discovered your superbly written blogs; the language skills alone contradict my stereotyped view of developers.

    I have a lot of contact with a BIG international organisation that has trouble recruiting good developers. There are lessons for them on this page – they should read it.

    You mention “great developers” several times, here and by implication on your piece “How to find someone technical to build your idea”. I’m assuming that capitalism at this stage has produced a mismatch between the number of top-notch engineers and the need for top-notch engineering. Clearly we either don’t have enough developers or we don’t have enough really good ones. When ideas are so “cheap and plentiful” by comparison with realising them on the developer side, it must be bad for the economy and more broadly for creativity.

    My question to you is: will you write a whole piece on the skill-set that makes a great developer? Specific things I wonder about are (i) what marks out a likely “great developer” in the first place, pre-training; and (ii) what would you like to see in our system of training to maximise the number of great developers coming into the workforce?


    • Alex on April 4, 2013 at 7:45 am said:

      Thanks Tony. Yes, we both don’t have enough, or enough really good ones.

      But it’s not a skill set that makes a great developer, it’s an attitude: a thirst for solving problems, a personal standard of excellence, an awareness of detail, a drive for improvement. Sure, there are some specific techniques and technical skills required to start, but I don’t think our university system falls to short here apart from insufficient volume. It’s the attitude toward learning and solving difficult problems that our education systems fail us on.

Post Navigation