The four cofounders of ZipRecruiter have worked together for a long time. We all worked together early on at Rent.com, which was acquired by eBay in 2005 for $433 million, and some of us worked together at various Los Angeles tech companies between 2006 and 2010.
In 2009 we started working on what would eventually become ZipRecruiter. It started out as a side project, which we worked on during nights and weekends while keeping our full time jobs. We launched the web site, incorporated the company, and revised and iterated all aspects of the business over the next year or so. By early 2011 we had enough customers to quit our jobs and focus on ZipRecruiter full time.
We've grown rapidly. Since early 2011, we've gone from zero employees to over 600, with over 100 software engineers, and both our team and our company's revenue are still growing quickly. In August 2014, we raised $63 million in our first round of venture capital funding, after having bootstrapped the business for 4 years.
It's too early to tell where we'll end up, but our goal is to build the best online services for posting and finding jobs.
We don't claim a specific software development process, but we're aligned with many agile principles. We release software multiple times per week and run experiments often. We use Amazon Web Services, Linux and many open source technologies. Our primary programming languages are Perl and Python. We hire mostly generalist engineers, and we support engineers learning new technologies instead of expecting them to be experts in a technology before working with it at our business.
We also offer the salary, bonus, benefits and stability that you'd expect of a large corporation (we omit the soul destroying aspects like lack of purpose and inane bureaucracy).
We have a fairly simple hiring process. It starts with you applying to one of our open positions or sending us an introductory email. We ask you to take a ~1 hour quiz that involves writing programs to solve a few small problems in a language of your choice. That's followed by one or two phone screening calls, and then a set of in-person interviews that takes 3-4 hours total (a lunch break is included).
[Develop a minimum viable product and release often.] We've released software to production just about every week for as long as the company has existed. Most changes are small and incremental, but we get quick feedback on whether our code is working properly and helping or hurting the business.
[It's ok to break things.] Don't be afraid of making a mistake, even if it costs the company thousands of dollars. It's happened quite a few times in the past, and is part of what happens when you build software iteratively and release it often. Nobody is going to yell at you for making a mistake.
[Give an honest effort.] This is not a crazy startup or video game company where we expect you to work late or on weekends, but neither is it a big company where we can afford to sit around and be ineffective. You have lots of autonomy and we don't keep close tabs on you - we trust you.
[Don't work too hard (really!).] On the opposite end of the spectrum are people who get so buried in work that they risk burning out. It's not good for the business to rotate through engineers as others burn out. We'd rather have a stable team that knows the codebase and is well rested and happy.
[Be assertive in a polite manner.] Sometimes your coworkers will want you to do something for them ASAP, but you don't have to drop what you're doing just because someone is pushing for you to do something else. If you do say no, be polite about it and try to understand why they're asking.
[Manage technical debt.] Make incremental improvements as you work on projects. You'll often be improving a system or building something with slightly different requirements, and the fastest way to complete your current project would be to copy, building something completely separate and leaving the existing similar thing untouched. But if there's an opportunity to take a little more time and refactor so that the existing thing and the current project can share code, you should do that refactoring to help keep the codebase minimal. We believe incremental refactoring like this is preferable to building up large amounts of technical debt and then periodically going back and trying to clean up everything in a big rewrite.
[Use self-directed time.] Feel free to use a minority of your time to work on your own ideas and improvements, as long as you're honestly working to help the business. Here are specifics on what we mean by self-directed time.
[Open source code that’s not specific to our business.] Talk to a founder before starting the release process, but open source contributions are great for hiring, publicity, and for the worldwide software community. Examples of things we have or could open source: the config templating system, enhancements to the perl client for solr, the task queue framework.
[Be willing to "wash the dishes".] Don't feel like you're above certain types of work, although if there's boring mechanical work that needs to be repeated, perhaps you should automate it so that nobody has to do it in the future.