I consider our software development team to be one of the coolest on the planet. I’ve met a lot of teams around the planet – well, ok, only three continents – and I can only think of one that might be cooler than ours. We’re a small team, we have a great track record for the past 7+ years, we’re valued by the rest of our company, we’re allowed to do our best work, we’re always improving. We work at a sustainable pace, no nights, no weekends, no crazy hours. What’s not to like? (Yes, you’ll find me tweeting and blogging at odd times, but I enjoy writing, and at the moment I’m laid up with a broken ankle).
And yet, I’ve been tweeting for several weeks now about the fact that we want to hire a Java programmer and a software tester, and posted on several mailing lists, and the response has been underwhelming. I whined about this a couple weeks ago on Twitter, and received some good inspiration in response. One pointed me to Trish Koo’s blog post where she recruits a tester for her company (she’s in Sydney, luckily we aren’t in competition), and the other was to Atomic Object’s tester recruiting page (they’re in Grand Rapids, we’re in Denver, I rest my case).
This is my personal blog, not an official recruiting site for my employer, ePlan Services (A Paychex Company), and I’m not the hiring manager (I’m not a manager of any sort, but we all have input into the interview and hiring process), but I’d like to take the opportunity to do a little recruiting anyway.
What’s In It for You?
We’re a small team, following Agile principles, using most of the XP practices, working in a mix of Scrum, Lean, Kanban and whatever else works for us. We collaborate, we help each other, nobody’s afraid to ask for help, and we jump in on any task that needs doing. We’re a true part of the business, helping to set priorities and solve business problems, not the “software team” off in a corner. And we need you, a valued peer with whom we are proud to work!
You’ll work on a web-based financial services app, written in Java with some Groovy, using Spring, Hibernate and Velocity, and supported by tens of thousands of tests in JUnit, FitNesse, Canoo WebTest and Watir. Ours is a challenging domain to learn, but we work closely with awesome folks on the business side to understand what they need and find the simplest ways to deliver that. If you like working test-first, in small increments, getting quick feedback from automated regression tests and from business stakeholders, you’ll enjoy working here.
We take a Whole Team approach to quality and testing. We start every theme and user story by first thinking about how we’ll test it. We discuss upcoming themes and stories with the Product Owner and other stakeholders and write high-level requirements and test cases together. Testers develop test cases and strategy in more detail, in collaboration with customers, and specify tests to drive development. Developers automate those tests as they write the production code. Testers automate the GUI regression tests in Canoo Webtest. Testers do extensive manual exploratory testing, helped with Ruby/Watir scripts.
Working here, you’ll enjoy time to learn, with teammates willing to help. Does some other test framework seem like it might solve some automation problems? Another tester, developer or sys admin will probably be willing to pursue that idea with you. You’ll be working with a team of truly inspiring and fun people. If you like to play Quake, you’re really going to enjoy it here.
Rather than take up a lot more space here telling you about our team, I encourage you to read the many blog posts here (and also please see the links on my Articles and Publications page) that recount our real-life experiences. For that matter, you can read the book I co-wrote with Janet Gregory, which includes countless examples from my team. I also encourage you to check out my teammate Nanda’s blog. And my teammate Tony Sweets has also published articles based on ideas he’s implemented here, check out his blog. I could give you more teammates’ blogs, but I think this will give you enough information to know if you’d enjoy working with us.
What You May or May Not Like
If titles and “career path” are important to you, this might not be the place for you. I do have a fancy title, but what I put on my card is “Tester”, and that’s the title for the position we’re hiring. The Java programmer title is “Software Engineer”, I personally don’t see why we want to call ourselves engineers, but we are called the “engineering team” – I pick my battles.
The “advancement” you get on our team is the chance to continually learn, experiment, try new technologies and techniques, collaborate to solve business and technical problems. There are only ten people total on our team now, and 42 in the whole company, so there’s not a traditional corporate ladder. Our good work is rewarded and valued, you’ll feel the love in both extrinsic and intrinsic rewards. You’ll enjoy working here if you’re passionate about developing the best possible quality software product. And, because you like to enjoy your work and have a job that’s both challenging and fun!
Here are the job descriptions and the information on whom to contact. I encourage you to include an experience you’ve had that shows you’re a great fit for our team, based on what you read in our various blogs and articles. Please feel free to contact me as well, I’m happy to answer questions.
* * *
Software Tester
Software Testers at ePlan Services are part of an Agile team that builds the software to allow our company to be a leader in providing Internet-based 401(k) plans for small companies. If you are passionate about delivering value to your customers, we would like to talk to you about an immediate opening at our location in the Denver Technology Center.
To become a software tester at ePlan Services, you will need:
- Experience with software testing techniques such as manual and exploratory testing, test automation, performance testing, or security testing.
- Strong technical skills demonstrated by experience with programming or scripting languages such as Java, C, shell script, or Ruby.
- To collaborate with a variety of people in our company to make sure our software works for our customers.
- Some experience with databases, data modeling, and SQL.
- To show a commitment to ongoing professional development through self-learning, professional training, participation in open source projects, attending conferences etc.
If the above description accurately describes your experience and approach to software testing, please send your resume to:
Trevor Sterritt
trevor.sterritt@eplanservices.com
* * *
Software Engineer
Software engineers at ePlan Services develop the software that allows our company to be a leader in providing Internet-based 401(k) plans for small companies. If you are passionate about delivering value to your customers, we would like to talk to you about an immediate opening at our location in the Denver Technology Center.
To become a software engineer at ePlan Services, you will need:
- A high degree of expertise in Java and Spring.
- To be a dedicated follower of test driven development methods and technologies.
- Some professional experience with Hibernate, SQL, and web development languages such as HTML, CSS, and JavaScript.
- To show a commitment to ongoing professional development through self-learning, professional training, participation in open source projects, attending conferences etc.
If the above description accurately describes your experience and approach to software engineering, please send your resume to:
Trevor Sterritt
trevor.sterritt@eplanservices.com
10 comments on “We’re Hiring”
You forget to mention what’s in it for the potential candidate. I.e. you say, *you must* be able to this and that, *you must* be willing to commit to conferences. There is no notion of what is expected from the candidate or what they can expect in return.
My rewrite:
As an experienced software engineering, you can expect to work on
– The Payroll system.
– Lead review sessions.
– Teach pair programming, TDD and the other XP practices.
– Etc.
In return, you can expect:
– In house training and coaching.
– A mentor in our buddy-scheme.
– To attend at least – they are compulsory – two software conferences a year.
To apply for the job, the ideal candidate must have:
– Experience in Java and Spring.
– Etc…
— End Rewrite —
So, as a developer, this ad does not look attractive, as you ask a lot and don’t seem to offer much in return. It’s too confusing. Break it into three: exactly what you want from the candidate, what the candidate can expect in return, and finally what qualifications the candidate should have. And drop ‘self-learning’ because that makes you look like a company that let’s developers fend for themselves. Self-learning is important, but save that for the interview. You are selling yourself in the ad, so choose your words carefully.
Hope that helps, J.
Thanks, Jamie. I made some updates based on your suggestions, though I didn’t quite put it in that format, I’ll try as I get more time. Those are excellent points.
I’ll tweet it. Get you more exposure
I feel somewhat bad suggesting this, but perhaps part of the problem you’ve described in hiring right now is simply related to your technology stack – the simple fact is that, among the best and brightest that I know in the software industry around Denver, I can’t think of a single individual for whom the prospect of working on a J2EE app is appealing. It’s good that you’re using Spring, but I’m afraid that J2EE is likely an albatross around the neck of your company. Something that you don’t mention is any opportunity to expand ones’ skills in any technology that isn’t several years old at this point.
Combining that with the lack of mobility within the company that you’ve described, this sounds to me like the very definition of a dead-end job. I like hearing that your team is great, but that’s not a differentiator – everyone claims a great team. The blog post you reference are nice, but they’re pretty light weight – a few generic posts on agile processes, and one on configuring Hudson? Where’s the innovation here?
Perhaps I’ve misinterpreted things greatly, but in my mind, today simply being agile in your development process is not enough. To attract top tier talent, you need something more compelling than work in a dead technology with an average team.
My apologies,
Kris
Hmmm, maybe I have done a poor job of describing it. I have visited software teams all over the world, and I can honestly say I’ve only met one that meets or exceeds our software quality and technical standards.
Truly, if your goal is to “move up the ladder”, this isn’t the place for you, and that’s ok. People have different goals. I have really loved being able to make a real and valued contribution to the business overall, not only the software. I enjoy being part of a team which has been able to automate aspects of 401(k) plans that the industry believed could not be automated. I enjoy being part of a company whose customer base and revenues have grown exponentially, while the size of the software team and indeed the company as a whole has barely grown at all.
I enjoy finding new ways to deliver the right business value and delight customers and users. That is more of a reward to me than a more impressive-sounding job title. And here, you don’t need a promotion to have your contributions recognized by a raise or some other reward.
I know an awful lot of Java teams so I guess I disagree that it’s a dead technology. Not being a programmer myself, I maybe haven’t explained the developer side of things well. There are lots of ways to expand one’s skills in technology apart from the language used for production code – test frameworks and drivers, refactoring tools, IDEs, better ways to document requirements through automated tests, better solutions for the UI, better designs for the back-end.
I’m a people person, I get my reward from getting to work with a great team. I disagree that there are a lot of teams around that work together as well as this team, and where each person pushes him or herself to be the best. If your only interest is in developing your technical skills, then I can see this wouldn’t be a good choice.
There’s a distinction that I’d like to make; while Java is not (yet) a dead technology, J2EE unequivocally is. Even before Sun was acquired by Oracle, the java EE stack had essentially been completely rewritten after the disaster that was J2EE; JEE3 is much more tolerable, but still behind the state of the art.
With respect to mobility within a company, it just strikes me as very interesting that this is something you’d put in a job advertisement; it’s something I’ve never seen before and the explicit statement that a candidate will be expected to remain in their role indefinitely seems like a bit of a red flag. What’s wrong with the culture of the company that there’s no potential for people to change what they’re doing? It just seems like an extraordinarily strange thing to highlight.
I appreciate how passionate you are about the quality of your team; it’s definitely a good thing to see, but I’d consider reworking how you present some of the other factors, perhaps with the input of your developers.
Good luck!
Kris
Hi Kris,
I’d be curious to know how you would implement “mobility” on a team that has 4 programmers and 2 testers? Where would we go? Who would outrank whom?
As to changing what we’re doing – well, a few years ago, one of the testers said, “I think I’d like to be a programmer”. He took some Java courses, the other devs paired with him, and poof, he is now a programmer (or developer, if you would rather use that term, but to me, everyone involved in developing the software is a developer, not only the programmers).
I was explicit about the smallness of our team because it’s valid for people to want to “rise in the ranks”, but if that’s who they are, they won’t be happy at our company. I don’t know if that will change now that we’ve been acquired by a giant company – maybe people will have the opportunity to switch to other teams within the parent company that have a “career path”. But those aren’t the people we are looking for now.
I am trying to show what is right with our culture. How many businesses do you know that put the *quality* of the software ahead of speed and meeting deadlines? How many businesses allow at least four weeks per year – sometimes more – in which we are specifically not delivering any new business value, only managing our technical debt and learning new things? How many businesses involve their software team in choosing business priorities? I sure don’t know of many, but maybe you do.
The developers are free to write their own darn blog postings. :-> I can only present my perspective.
I do appreciate your feedback!
Your example of a tester growing into a developer is great because that *is* a form of mobility. Again, I was just questioning the emphasis that you placed upon this in the post because it is unusual. It’s great that the software team is allowed to inform decisions on business priorities, but is there the potential for standout developers to reach a point where they’re explicitly *setting* business priorities? The question is about culture; about how engineers are generally regarded within the company. Perhaps this sort of mobility is only really available in engineering-centric organizations like those that I’m more familiar with; I don’t know. Certainly with as small a team as yours there is no need for managerial hierarchy, but that’s very much a statement about what’s happening with your team *now* and says little about where the business is going. If the business grows 10x in the next two years, will the situation be the same?
The additional details about how the business explicitly allows time for managing technical debt are also very important, and I’m glad you included them in your response. Attention to quality is obviously very important; equally important is the ability for individuals to make contributions that actually grow the business, and to be rewarded for those contributions with decision-making power.
Hi Kris, in our domain, I don’t think it’s appropriate for us to set biz priorities, but we can and do provide a lot of input about ROI, alternatives. At least one developer participates in all prioritization meetings. This morning, the PO sat with a dev to talk about an upcoming theme and talk thru different ideas and risks.
Our business model is unusual in that it is designed so that the customer base and revenues continue to grow without needing to hire more people. There weere 26 people in the company when I joined it in 2003, now there are 42. Our dev team headcount is maybe one more than it was in 2004 (though obviously, now we are expanding it, because our new parent company asked us to). Personally I like working for small companies and on small teams, so this has been great for me.
The trust and recognition from the biz side means a lot to me. For example, our CEO and CFO have been overheard to tell potential partners, “You couldn’t pay us to not do agile development”. They’ve come back from industry conferences saying “None of our competitors can believe we were able to automate XYZ.” We have company-wide parties for milestones such as getting to 5,000 JUnit tests. One of the things I love best is to learn a domain and contribute to the business in multiple ways.
But other people might prefer the chance to work in a new programming language every few months. We’ve added Groovy over the years but I don’t see us switching from being a Java shop. So that kind of reward isn’t here. Personally, I also like to try new things such as different test frameworks on my own time too.
Thanks for your questions and comments, which give me an opportunity to clarify what it’s like to work here, and hope that maybe someone great will be interested!
[…] “We’re Hiring” by Lisa Crispin “Improving Our Interview Process” by Lisa Crispin “Hiring […]