What does a skilled BDD-/RSpec-er want in a job?

Hi everyone,

Hope this is not too OT, but I know I will get a good answer here…

I will be soon* helping one of my clients write a job spec for an
agile software developer, to work on a Ruby web app using RSpec. I’d
just like to know something from experienced BDDers - what in a job
spec would attract your attention? There’s obviously nothing I can do
about pay, working conditions etc (although both are pretty good, I
have to say - I’d certainly like the job if I didn’t want to work for
myself), so it’s more the technical appeal of the job.

I’m guessing most people would be put off by, for example:
Programmer wanted to write web site. Must have 3 years’ experience in
Rails, SQL Server and CVS. We are agile so you must deliver 3 pages
of the project spec every iteration. We do pair programming, but if
you need a machine of your own, we have some spare Windows 95 boxes in
the cupboard.

But what things make a job appealing? What technologies, skills,
practices and methodologies make for a good BDD role?

Thanks
Ashley

  • Tomorrow actually, I guess I had the inspiration to ask on this list
    a bit late


http://www.patchspace.co.uk/

On Sun, Sep 7, 2008 at 1:14 PM, Ashley M.
[email protected]wrote:

But what things make a job appealing? What technologies, skills, practices
and methodologies make for a good BDD role?

Just mentioning BDD is good. It’s easily searched for, and if you
indicate
that it’s not just a buzzword to you, I’d imagine that would be enough
to
lure some good resumes. Most shops don’t even have a clue what BDD/TDD
are.

///ark

RSpec is a tool, it should be in face minimally (yes, this is
important!)
A job description that mentioned RSpec explicitly would signal a red
flag
to me.

On Sep 7, 2008, at 7:21 PM, Bryan L. wrote:

RSpec is a tool, it should be in face minimally (yes, this is
important!) A job description that mentioned RSpec explicitly
would signal a red flag to me.

Not at all! A mention of RSpec would be a great thing. In fact, it’s
one of the things that attracted me to my current job at EastMedia.
They knew I had contributed patches to the framework, and this helped
me to get hired. Being there, I’ve not only had plenty of freedom to
work on RSpec, but also on Stories, and to pair with Bryan, the
creator of webrat.

But what things make a job appealing? What technologies, skills,
practices and methodologies make for a good BDD role?

Any sort of mention of testing or BDD would be attractive to a
BDD’er. Mentioning RSpec would in fact mean that the job is forward
thinking - that they aren’t bogged down with legacy code (i.e.
Test::Unit) and legacy thinking.

I was interested in the job at EM because it was obvious that they
would allow me to use the tools that made me most productive, and
that this toolset could change and adapt to my workflow.

Scott

On Sun, Sep 7, 2008 at 4:21 PM, Bryan L. [email protected] wrote:

RSpec is a tool, it should be in face minimally (yes, this is important!)
A job description that mentioned RSpec explicitly would signal a red flag
to me.

BDD, Ruby on Rails, and OOP are just tools, too. They are each means to
an
end (and they’re not the only means, either). But tools take time to
learn,
and can take a lot of time to learn to use well. I don’t think lack of
RSpec
experience should disqualify someone from a job (and a good thing, too,
or I
wouldn’t be working where I am). But it could be a plus from the
employer’s
perspective, just as it could be a plus from the candidate’s.

///ark

“Bryan L.” [email protected] writes:

RSpec is a tool, it should be in face minimally (yes, this is important!) A
job description that mentioned RSpec explicitly would signal a red flag to me.

I’m with Scott & Mark on this one. Tools matter, and good developers
usually have strong opinions on them. The key is strong, not stubborn -
and remembering that they’re just tools allows us to improve on them and
seek out better alternatives.

Personally, I’ve talked with potential employers that know about my
RSpec involvement, and say, “we use Test::Unit here, would that be a
problem for you?” And my answer is, “Yes, unless you want me to help
move everything to RSpec.” Of course I could do that job…but with all
the other (sane :slight_smile: employers who “let” me use RSpec, why bother?

btw, a job ad that would catch my eye would be one that lists the tools
you
use, what open source contributions you’ve made to them, and what other
open source stuff you’ve done in the form of plugins, mini apps,
whatever.

Pat

On Sep 08, 2008, at 1:09 am, Pat M. wrote:

btw, a job ad that would catch my eye would be one that lists the
tools you
use, what open source contributions you’ve made to them, and what
other
open source stuff you’ve done in the form of plugins, mini apps,
whatever.

Hi Pat, Mark, Scott, Bryan

Thanks very much for the feedback. I think based on your comments we
should include the technologies, but make it clear they are just what
we use, and that similar skills in say xUnit tools, or with Java/
Python/etc are equally valid. Don’t know how long it will take to get
the job advertised, hopefully within a month or so though.

Cheers
Ashley


http://www.patchspace.co.uk/

I know a while back Google used to request python skills when they were
hiring java folks. They didn’t actually need python to do their job - it
just meant they attracted the kind of developers who venture outside
their
regular programming world, which is what they were really after. Mind
you
they ended up hiring Guido van Rossum, so you have to be a bit careful
:slight_smile:

Mentioning the technologies is useful, but if you put the emphasis on
your
culture (co-located, collaborative, valuing open source - both using and
contributing, etc.) you may find you attract people who also value
culture
over specific technical skills. And any job ad that attracts Pat M.

well that would be a pretty successful job ad in my opinion.*

Cheers,
Dan

  • because it would mean he was working somewhere else :wink:

2008/9/8 Ashley M. [email protected]

On Tue, Sep 9, 2008 at 8:34 AM, Ashley M.
[email protected] wrote:

RSpec core team by accident?
Sorry man, to get us you’re going to have to talk about vegetables and
Features.

Customer → Story Session → Story → Spec → Code
| |
<------------- Demo Meeting <---------------

And it’s no longer clear where the fuzzy business stuff stops and the geeky
technical stuff starts. Dunno how you screen for that though, short making
a real story writing session part of the interview process.

Why not? I’ve been asked to submit code before job interviews and even
pair during them. Taught me as much about potential employers as it
did them about me.

And any job ad that attracts Pat M. - well that would be a pretty
successful job ad in my opinion.*

This may require something more specific on the job description. Pat’s
favourite brand of coffee is? :slight_smile:

I’d stick to the previously established theme here - “we tend to drink
a nice dark Tanzania coffee here, but if you tend towards Sumatra
instead, that’s OK. Just no Starbucks on the premises, please.”

Cheers,
David

On 9 Sep 2008, at 13:28, Dan N. wrote:

I know a while back Google used to request python skills when they
were hiring java folks. They didn’t actually need python to do their
job - it just meant they attracted the kind of developers who
venture outside their regular programming world, which is what they
were really after. Mind you they ended up hiring Guido van Rossum,
so you have to be a bit careful :slight_smile:

Good point! Might try and sneak something new and shiny in there. Do
you think if we mention RSpec + Stories on the job spec we might hire
the whole RSpec core team by accident?

Mentioning the technologies is useful, but if you put the emphasis
on your culture (co-located, collaborative, valuing open source -
both using and contributing, etc.) you may find you attract people
who also value culture over specific technical skills.

Very good point, hadn’t looked at it that way. Collaborative is very
important. One thing I love about stories is they give a concrete way
to bridge the gap between the customer and code. I noticed a few
weeks back that there’s a continuum:

Customer → Story Session → Story → Spec → Code
| |
<------------- Demo Meeting <---------------

And it’s no longer clear where the fuzzy business stuff stops and the
geeky technical stuff starts. Dunno how you screen for that though,
short making a real story writing session part of the interview process.

And any job ad that attracts Pat M. - well that would be a
pretty successful job ad in my opinion.*

This may require something more specific on the job description.
Pat’s favourite brand of coffee is? :slight_smile:

Ashley


http://www.patchspace.co.uk/

On Sep 09, 2008, at 3:00 pm, David C. wrote:

Sorry man, to get us you’re going to have to talk about vegetables
and Features.

Actually I’m going to be giving a short talk on BDD story/feature
writing + Cucumber + RSpec + Celerity at my next local monthly mini-
conference/geek beer-swilling night*. To the best of my limited
ability anyway.

That’s got TWO vegetables in it. Do I get bonus recruitment points???

Why not? I’ve been asked to submit code before job interviews and even
pair during them. Taught me as much about potential employers as it
did them about me.

When I wrote it, I knew it might be just crazy enough to work…

I think a day spent story writing with a customer in the morning, and
pairing in the afternoon, could give a very good indication of how
well someone will work. But I bet it’d be very stressful for the
candidates.

I’d stick to the previously established theme here - “we tend to drink
a nice dark Tanzania coffee here, but if you tend towards Sumatra
instead, that’s OK. Just no Starbucks on the premises, please.”

Hmmm, I suspect I may have to upgrade from Tesco decaf to stand any
chance of hiring a developer…

Ashley


http://www.patchspace.co.uk/