
Slightly Less Awful Hiring for Engineering Talent - wpietri
http://www.codeforamerica.org/blog/2015/12/11/slightly-less-awful-hiring-for-engineering-talent/
======
ianamartin
One thing I noticed in my most recent job search was that I don't see nearly
as many postings for junior and entry level positions as I seem to remember in
the past. Seems like everyone is looking for a rockstar or a genius or a code
ninja miracle-worker.

I'm curious if anyone else sees that trend, or if I'm just making it up. One
of the reasons is that several friends of mine have been bugging me for a
while to help get them started with code. These are people around my age.
Professional musicians from back in the time of my life when that was what I
did for a living.

There five of them now who have been asking, so I'm finally putting together a
structured curriculum and working with them on a regular basis. When we get
done in six months or so, they will have some abilities with Linux server
administration, databases, Python, C#, web application frameworks,
javascript,front end work, version control, and testing. I'll work in some CS
theory as we hit appropriate points.

Obviously, they will be very green. But they are all incredibly bright,
professional, adults. One of them has a master's in Math she got after her
Doctorate in music just because she was curious, and another has most of a PhD
in Physics. I don't think any of them expect to waltz into a high-powered job
after 6 months of me spewing at them. But I think any of them would thrive in
a junior position with people around them who had the time and the inclination
to do some mentoring.

Are those kinds of jobs disappearing? Am I being unrealistic hoping that this
could be an option for some of them? What do you think?

~~~
stouset
Regardless of what organizations claim to be looking for, virtually everywhere
I've been besides my current position has been staffed to the brim with junior
developers, and been in dire need of at least a few people with seniority.

The irony is when a senior person does come in, all their recommendations are
ignored because they will slow down the pace of development. Which it will,
but in exchange for setting a _sustainable_ pace of development. A senior
developer might (making numbers up here) crank out 100 lines of code per day,
but a junior will crank out 1,000 while solving twice as many business
problems. Unfortunately, bug counts seem to scale linearly with code size, so
most of the problems you're solving are actually just a direct consequence of
the ten-fold increase in bugs in the larger code base. Eventually progress
grinds to a complete halt as it becomes too difficult to add business value,
and the company enters zombie mode where its death is virtually inevitable,
but can still operate for years through additional funding.

Sorry, I may have gotten a little off point there.

~~~
EliRivers
Sweet Jesus, so true.

Every time someone suggests we have proper requirements or decent testing or
put some thought into design or rewrite something that's causing endless
trouble, we're told there's no time for it.

Which is how we're now up to "release candidate" FORTY, four months behind the
original release date. Because tests get done six months after the code was
written, whatever doesn't fail has a fifty-fifty chance of not actually doing
what's needed (so it's a bug), and testers and coders have long conversations
about "what's it even meant to do, anyway?" that are unanswerable because
there is no requirement or design reference.

The cost of running four months over schedule thus far is, well, four man-
months multiplied by the number of employees, basically. So yeah, excellent
savings compared to having spent a couple of days thinking about what we're
trying to build and having testers involved throughout rather than just
dumping six months' worth of untested development on them (and expecting them
not only to be able to test it in a week, but expecting everything to pass).

Wouldn't mind if this was the first time, but EVERY DAMN CYCLE is the same. We
can't possible start doing things properly, look how far behind we are! It's
like there's a mental gap, some kind of inability to see the cause and effect
right in front of their faces.

( Morale is low :p )

~~~
wpietri
> Every time someone suggests we have proper requirements or decent testing or
> put some thought into design or rewrite something that's causing endless
> trouble, we're told there's no time for it.

I should point out that as professionals not only do we have the option of
saying no to bad requests, I think we also have the obligation to do so.

I know there's this culture in software development of "just do whatever the
bosses say", but as far as I can tell it's not a law. I've told executives no
on many occasions and so far I've never been fired for it. At first their
startled, but if you keep saying no to the bad requests and help them
understand what they're supposed to do, they eventually come around. And if
not, this is an excellent time to find another software development job.

> It's like there's a mental gap, some kind of inability to see the cause and
> effect right in front of their faces.

Yes, that definitely happens. Until people experience it the other way, they
often think that's just how software development has to be.

~~~
EliRivers
"I should point out that as professionals not only do we have the option of
saying no to bad requests, I think we also have the obligation to do so."

Indeed. I watched three people say "no" to a significant, new piece of very
important software that replaced completely our legacy data
storage/fetching/processing methods. They said "no" for the reasons you'd
expect; not properly specified, unreasonable expectations of basically magic
on the part of management, very improbable timescale.

In one meeting, when a very skilled programmer (who goes to the C++ committee
meetings and that sort of thing) said "no", the response was "Well then I'll
find someone who can." What they got, of course, was someone who didn't say
"no" (and of course, there's an element of self-selection here; given that
some skilled, competent software engineers said no, the person who said yes
was, harsh as it may sound, an adequate _programmer_ but an incompetent
software engineer). What we got was a total car crash of software, six months
late, that's massively unsuitable, doesn't do what's needed, undocumented,
untested, everything bad that you'd expect. A great deal of the 40 "release
candidates" were desperate fixes to this car crash, that our recently
appointed new software architect is planning to take outside and execute in
the car park as soon as we get a "release". So that was a great use of a year.

Where this is going is that saying "no" didn't actually stop them finding
someone who wouldn't say "no". On the plus side, the person who delivered this
truly atrocious software to us is now actively looking for another job. Not
that he was fired, no no, but he's now got zero credibility and nobody wants
to work on anything he ever touched.

Christ, I wish I'd just gone into mathematics.

~~~
wpietri
I'm not quite understanding. The yes-sayer worked alone on the project and is
now leaving? If so, why's it a problem for you?

~~~
EliRivers
Because he's not taking the godawful software with him. That's staying.

It's also a problem for me because he's done his damage. I want to make high-
quality software, on time, that does what the customers need. I want this out
of both a sense of personal pride, and also because I need the company to keep
making sales so they can keep giving me money.

~~~
wpietri
Sorry, I'm still not understanding. What's stopping you from making high-
quality software on reasonable schedules?

~~~
EliRivers
I don't run the company, and even if I ignored everything I was told to do,
and didn't get fired, and instead followed sensible, professional processes, I
don't write the entire software by myself.

I am bemused that someone of your experience has trouble grasping this. I
thought perhaps you were some kid straight out of school who thinks the whole
world works like the marketing material for agile, but it turns out you've got
a decade of experience. You must, surely, have seen (or at least heard of)
companies that don't look like the marketing material for agile?

~~~
wpietri
Sure. Mostly when I see it, it's people who don't know any better. With a fair
number who do know better but do it anyhow. The former group I understand. But
the latter is a mystery to me.

------
pjungwir
The #1 thing I look for in a job ad is a salary range. I don't see one in the
ad he links to, and I don't see any discussion of salary in the article.
Without that I won't bother to apply.

~~~
agildehaus
Then there are employers that hide entirely behind a recruiting agency. Why
should I apply if I have little idea who you are and what you do?

~~~
sopooneo
Or _are hidden by_ a recruiting agency. A lot of agencies will do anything
they can to make sure you don't go around them.

~~~
prodigal_erik
Or employers who don't actually exist, because the agency is secretly trying
to collect enough résumés to convince employers to engage them.

~~~
sopooneo
Right. As I've heard it discussed, they've borrowed the term "honey-potting"
for this in an almost exact analogue of how it is done on dating sites.

------
afarrell
> Don’t require a particular language

But do indicate language in the nice-to-haves at least. Some programmers find
that they work much better with certain tools than others and it is useful to
know if you are able to use those tools.

~~~
elwell
Also, depending on the language, it _should_ sometimes be a requirement. If
you're hiring for a Haskell developer, and you're a startup, you don't have
time for a top python engineer to spend 2 months getting up to speed in
Haskell.

~~~
wwweston
> If you're hiring for a Haskell developer, and you're a startup, you don't
> have time for a top python engineer to spend 2 months getting up to speed in
> Haskell.

I'm curious. Are there projects/organizations anyone can think of that were in
this position went on to success?

I have a suspicion that by the time an organization gets itself in a position
where it needs a dev with niche skills and the need is so urgent that it can't
spare even two months to get a top generalist developer up to speed... it's
already made some bad decisions that might mean that it's not going to
survive.

Highly specialized knowledge directly in the product domain is one thing.
That's understandable. If what we're talking here is language/stack
preference, that's something else.

~~~
wpietri
Yeah. Especially at a startup I think you should be optimizing for engineering
growth. A company that a) has very specialized language needs, and b) isn't
set up to mentor doesn't sound well set up to grow quickly.

------
krazydad
As someone who is currently job hunting, and freshly familiar with excessively
long & arbitrary "requrements" sections and tedious application forms, THANK
YOU.

------
wpietri
I'm the author, and I'm glad to discuss!

~~~
xigency
I liked most of the decisions you made and how you addressed the problem of
hiring coders. One question, do you think, maybe not in your case but in some
situations, that a process like this might be too drawn out or too selective?

Recently I spent some time interviewing and jumping between jobs, and compared
to the amount of time I spent working at one company, I was spending a lot of
time interviewing, preparing for interviews, and applying to companies.

Basically, my impression from being a high school programmer was walking in
the door, being qualified, and being hired essentially in the same afternoon.
After getting through college, it seems to be way more of a _contest_ to win a
job.

Similarly, I earned an internship at a high-profile company in New York City,
which I didn't actually complete due to extenuating circumstances, but the
impression I had from the interview and from a few days on the job was that
the role was trivially easy and they were somehow scouting the absolutely most
qualified and talented programmers in the country, anyway. This might happen
to work out but something seems broken in this situation, too.

~~~
wpietri
As to being drawn out, I think that I would love to find ways to make it
quicker. At startups, where you're basically always hiring, it's easier
because you can hire on a rolling basis. At my last company if somebody was
eager, they could do all the stages over one or two days and we could quickly
make an offer.

In this case, though, this team had only one position to fill and hadn't hired
together before, so we needed to see a fair number of candidates in a batch so
that we could collectively calibrate. That took more time than I wanted.

I definitely don't think we were too selective, though. Good developers can
quickly improve both a team and a code base. Bad ones can harm both in ways
that are expensive to fix. I think a lot of typical selection criteria are
bunk (e.g., fancy schools, fancy companies on the resume), and I'm not always
looking for amazing technical qualifications. But I definitely think it's
worth time to find people who are great fits for the job.

~~~
xigency
Thanks, those are good points. I enjoyed the article.

