
As a recruiter, what shortcuts can I use to tell if a person can do the job? - niccl
We&#x27;re a tiny development group providing analysis tools and reports to support a consulting group. There are just three full time developers. I&#x27;ve recently been made tech lead. Prior to starting here 3 years ago I&#x27;d been contracting&#x2F;self-employed for 20+ years, so I&#x27;ve got very little experience of the recruiting process. I&#x27;ve been largely responsible for hiring developers (usually on contract) for a couple of years here, and to be honest my hit rate is not good. We&#x27;ve had a couple of outstanding people, some ok, and some ... less so.<p>I&#x27;ve read many articles here about how hiring is broken, long interview sequences don&#x27;t test what matters, etc., and I don&#x27;t have the time, skills, resources or experience to come up with a massive interview protocol anyway. We seem to do stuff that&#x27;s out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report) so the pool of candidates here is limited.<p>I think I know what I want: A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly but are sometimes not good at translating the problems they see into words that make sense to a developer who doesn&#x27;t have that underlying understanding of the business domain. And who understands about Chesterton&#x27;s Fence<p>Are there effective techniques that can help me sort the good from the less good, and if so what are they?
======
muzani
The most common complaint with interviewing is that it's too slow, too
exhausting, and doesn't test relevant skills. So interview faster and
interview easier.

First off, offer above average market rate. It doesn't have to be high, but it
keeps everyone's minds off money and their main focus is to work rather than
using you as a stepping stone. Make this rate clear. Make the interview
process clear. People dread being dragged through 5 interviews only to get
lowballed.

First level: filter. Ideally do it in the application form. Pick something
that correlates to skill level. Lots of small questions is better than one big
question because it reduces the randomness. Like I've seen things like
"explain grep", "use functional programming to solve this problem", or "how do
you keep up with the latest tech trends?" It should filter about 3/4 of your
applicants. Your personality/attitude interviews should go here too.

I'd recommend finding one good question that takes a few hours. It can be take
home or on site or whiteboard. Since you only have one, make it good. It
should test that they can read instructions, ask if instructions are unclear,
and code. If your goal is to fix bugs, take an old, bugged snippet of your
code and watch them figure it out.

Try to do that process as fast as possible, ideally within a week or two. The
more skilled someone is, the faster they'll get jobs.

If you want an even lazier system, just pay for Codility for a bit and make
them do some tests. It tests quickly enough, has a broad range of questions,
catches cheating, tests that they can read instructions, and there are even
some bug fixing challenges.

------
randombytes6869
> . We seem to do stuff that's out of the normal experience (Python to create
> thousands of individual reports on thousands of rows of postgres data per
> report)

Sounds like you need somebody that knows Python and SQL, should be easy to
find. Everybody thats been in the business for a while has done reports.
However everybody also hates doing reports, so you might have to pay more than
you want to, or hire interns to do it.

> A maintainer who can find their way through an ugly codebase and quickly fix
> bugs that are identified by people who know the business domain thoroughly

I would just look for somebody experienced then, maybe 3 years +. Its going to
cost more though, especially if the codebase is ugly and most of the work is
reports.

> I've been largely responsible for hiring developers (usually on contract)

Hiring on contract is unlikely to get you desirable hires. Good devs have a
lot of options.

My somewhat generic advice is to have a coding assignment. Some people won't
do them but its the best way I've found to screen candidate quality. Equally
important is to have a good developer look at the submissions. The quality of
code as rated by good devs has always correlated strongly with the quality
produced once hired, at least from what I've seen.

Advice for your situation specifically is to offer a lot of money and don't do
contract-to-hire. Reports suck, your codebase sucks. Good developers can find
another job within weeks and won't stick around unless you make it worthwhile.
Most desirable hires will outright refuse contract-to-hire so you're
restricting yourself to a low quality talent pool already.

You can nab good people for a lucklustere job without paying a premium if
you're willing to give rare concessions. Fully remote work, flexible hours,
part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay
well turnover will remain high.

You're not in a good spot right now. If you're open and honest about the job
"writing reports in a crappy codebase" you won't get many interested hires and
those you find will ask for more money. If you lie/deflect you will hire more
but turnover will be insane. Your best option may be to hire interns. They
will expect the job/code to suck and ask for little money. Turnover will
remain high and quality will be all over the place, but at least it will be
cheap.

~~~
perl4ever
>Most desirable hires will outright refuse contract-to-hire so you're
restricting yourself to a low quality talent pool already

That seems like an odd thing to say. Where do you jump from "undesirable" to
"low quality"? Isn't it exactly the undesirable but fair quality people who
are stuck doing contract to hire? That is, those who are undervalued in the
marketplace? It seems like a doubtful plan to insist on only chasing people
who don't need the position you want to fill and probably don't want to do it.

------
tucaz
My shortcut is to look for people who get stuff done. During interviews I
don’t ask technical questions or test the candidate but talk about
accomplishments.

How many projects have they deployed to production and what problems does it
solve?

A lot of developers work just during the development phase of a project and
then jump to the next one. As a consequence they have no experience
deliverying real life products and support systems in production.

I always look for people who finished things. Anyone can start or work on an
ongoing project but just a few go through the whole process and have to
maintain their stuff running.

I also talk about what the project does, in details, for the business. A good
developer has to understand they are building something that is not just a
piece of software but a tool to solve problems.

If they have these 2 things, I think we can work on the rest if needed.

~~~
dyingkneepad
Don't you end up hiring a lot of people who are very good at bullshitting?

Because that's what happened before we started introducing fizzbuzz-like
problems.

~~~
tucaz
I should have been more complete I’m my response.

What I described is the first step to narrow down candidates that I choose for
in-person interview.

After that step, if I think they are worth “investing” I’ll give them some
assignments and drill down on the tech questions.

But yes, this process still fails. It just fails less, I think.

------
thorin
I'm not a great fan of technical interviews with specific technical questions
or coding exercises, probably because I feel like I probably wouldn't do well
in them so interview style may be self-selecting in that sense.

What I'd normally do is ask someone to describe what they've done as if they
can't describe it well then they're unlikely to understand it properly and I
value verbal or written communication highly. I'd also ask them the technical
and business reasons for that implementation and what could be improved. I'd
start with something as simple as possible and hopefully build up.

I'd perhaps ask them to describe a solution to a difficult but not impossible
problem relating to their area of expertise. For instance in SQL I'd ask how
to describe how one might write a report that looks like a calendar by
selecting all dates for a year and grouping by month, day, week etc. This is
something that might take a few hours if you haven't done it before, but you
could probably describe the process. If I can't explain a problem like that in
10mins to them we're probably going to struggle to work together.

I'd also ask them about any personal areas of interest. A lot of people in IT
in the UK don't have any interest in it outside of work, which is kind of
understandable. I wouldn't expect massive github repos or personal projects,
but I would expect them to have technical "interests".

------
andy800
>> I'd been contracting/self-employed for 20+ years,

How did you convince companies & clients to hire you? What are the questions
you were repeatedly asked? I'd think you actually have plenty of experience in
the recruiting process, just from a different angle. (and congrats by the way,
it's always interesting how contractors line up work and keep a client
pipeline going -- something at which I've only had sporadic success)

~~~
niccl
I was outstandingly lucky! Most of my work came by word of mouth. I live in a
comparatively small town in a small country, I used to work in a small but
tight-knit industry, and I have an unusual name. I tried to make sure to have
coffee with someone every week and the work just came in. It didn't seem to
matter who the coffee was with, as long as I did it to keep my name current.
Hence the lack of recruiting experience.

------
he11ow
You may want to consider the possibility that the poor hit rate could be a
cause not of your inferior hiring skills, but due to the fact that you are
looking for a rare combination of skills, for a job that doesn't sound very
appealing:

You want someone who's technically solid, while also good at understanding
problems as described by laypeople, and doing all that without understanding
the business domain. Way before Chesterton's Fence, you're looking for someone
who is very good at communicating human-to-human, human-to-abstract and
abstract-to-software.

Tons of people can do one of the three. Lots of people can do two out of
three. Three out of three is rare. That is not a "maintainer".

So a different way to approach your hiring would be to revisit the process. If
you were able to direct the conversations with the business side to a person
who's good at linking between them and what needs to be solved, your
maintainer could be just that - a maintainer who goes through a bunch of fixes
in that ugly code base.

------
sloaken
List needs and wants, separately. Too many job ads list requirements which
they will never find in a combination. As such they attract liars or
exaggerators. Your posting should list no more than 5 REAL must haves,
preferably only 3.

Wants and nice to haves can be long, I would put them in priority order.

Describe what the real job is. If you are looking for a maintainer, say so.
But I think you might want to also bring in a consulate to clean up your 'ugly
codebase'.

With that 'ugly codebase' you are almost begging a person to come in and
replace the fence. Need to pay that tech debt. Otherwise anyone you hire will
either hate the job, or want to throw the fence away.

When I interview people I have a set list of questions. Then I have like 5
questions tailored to their resume. 'So tell me when you were involved in the
design of space-x what did you do?' Then is often followed by deeper probing
questions on their exact role.

When looking over a persons resumes I watch out for items that are just
bragging. Typically this is a list of too many accomplishments in too short of
a time. I look for 3 month jobs where they list items that would be
appropriate for a 3 year job.

Given your situation I would specifically ask: 'Scenario: you are given a 4000
line program to fix, you look at it, and the code looks like it was written by
a child. Just a load of crap. How do you address fixing the code?' You would
expect the first question back is: 'What is the criticality of the fix? Does
it need fixing now? Do I have time to clean it up?'

I worked at one place where this one guy hated when people would rewrite code,
but he was the worst, as in he always rewrote others code.

Personally I find people who do not see the value in code reviews, are not
worth the trouble. They tend to leave 'ugly codebase'.

------
dyeje
IMHO, the easiest way to evaluate if a candidate can do a job is to give them
tasks that they would do on the job. In your case, it looks like you should
have them generate a report and try to find a bug in some business logic
starting with an ambiguous problem statement.

------
tychonoff
Interview programmers like you would a carpenter:

1) Describe some projects you've worked on, and your role in them

2) Describe some of your favourite projects, or accomplishments

3) What are your favourite tools?

4) How do you think you can help?

3) Provide resume, references and a cover letter

As someone mentioned already, look for people who get stuff done.

~~~
sloaken
Oh I like your answer so much better than mine

------
cpach
You might want to say what country and region you’re in. Are you trying to
hire devs in Silicon Valley? Madrid? Flensburg? Etc. The way to go about it
and your expectations might vary a lot depending on the locale. Devs in SV can
demand very high salaries and can afford to be very picky. Not so for every
other region in the world. So how experienced devs you can hire for a certain
salary will very much depend on where the company is located. And the advice
that holds true for Silicon Valley might not be the same for other places.

~~~
muzani
I've always felt that it was the opposite. I'm nowhere near as good as your
average junior Stanford-graduated SV engineer, but I usually just highball a
salary and people pay it anyway. Whereas SV engineers complain a lot on the
interview gauntlet.

------
mrfusion
Make a small db with a subset of your data and give them a simplified report
to make. Have them do it as homework.

If they do a great job, hire them. Don’t bring them in for a day long
interview and try to prove they can’t code. (True story)

------
ChrisMarshallNY
You probably don't want me. Not because I'm no good; but because I'm the wrong
stack.

However, I do have something that will tell you an unbelievable amount about
me; the StackOverflow Story[0].

I have a gigantic portfolio, with dozens of repos, hundreds of thousands of
lines of code, a decade of commit history, dozens of published articles, going
into tremendous detail about the way I think, work, architect and code. I also
have a bunch of apps on the App Store, with full source[1].

TL;DR: There should be _no question_ as to my abilities, or even "soft"
factors, like personality and team dynamics.

Maybe you don't want a "shortcut." I was a development manager for a quarter
of a century. It was a small, high-functioning team. Every person we hired
became part of the "family," and was a commitment. When they finally rolled up
our team, the person with the _least_ seniority had a decade.

There was _no way_ that I would “shortcut” that hiring process. Each engineer
was a _major_ deal. I would have killed for the type of information that even
a quick glance at a GitHub ID will give, let alone an SO Story.

It has been my experience that the "shortcut" everyone wants, is a 50-line
binary tree leetcode test; which I am pretty terrible at, as are many
experienced engineers.

For some reason, that tells more about me than the portfolio; which recruiters
have always immediately ignored. It was insulting. It was meant to be. After a
few of those, I just gave up looking for work long ago. I now just do my own
thing. I don’t have a thing to prove to anyone.

I am not alone. I routinely visit GitHub pages jammed with detail about how
people work.

I often see solid green activity logs (like mine[2]).

You should look for a portfolio, and ask why not, if they don’t have it. Also,
don’t wait for them to come to you. Seek them out. Use your network. It’s a
big deal. It’s worth the time and effort.

[0]
[https://stackoverflow.com/cv/chrismarshall](https://stackoverflow.com/cv/chrismarshall)

[1]
[https://littlegreenviper.com/AppDocs/](https://littlegreenviper.com/AppDocs/)

[2] [https://github.com/ChrisMarshallNY](https://github.com/ChrisMarshallNY)

~~~
quickthrower2
I don’t have one and mainly the reason is I don’t need one to get a job. The
other reason is I’m not selling myself as someone who has a lot of open source
code, and any code I write on the weekends is going to be dogshit from a clean
code perspective. Because I am learning and prototyping.

That said the main thing the company hiring needs to know is does SO story
predict success in the job? Probably a little bit - it at least highlights
commitment and you could scrape HN to find good stories then reach out. But if
you ask “do you have a story/why not” to people coming in from regular
channels even SO applicants I think it’ll waste a lot of people’s time in both
sides.

~~~
ChrisMarshallNY
That depends. My “nights and weekends” code is _not_ “dogshit”[0]. I spent a
lot of time as a manager, and it was how I “kept my chops up.” One of my side
projects[1] has turned into a worldwide standard; used daily by tens of
thousands of people.

I fail to see how, if we are talking “clean code,” a short leetcode test will
say anything more than a portfolio; even one with “quick and dirty” code
(which is all you’ll get in the test, anyway).

Also, if companies start using portfolios as material for hiring, then folks
are a _lot_ more likely to take care, in their extracurricular work. That
won’t hurt. I think there’s a real crisis of quality, in today’s software.

I see a _lot_ of pretty impressive stuff, daily on GitHub; even “experimental”
projects. There’s a great deal of code and history out there. The fact that
someone is working on side projects; especially if they are doing so as part
of a team, can speak volumes on their behalf.

The SO Story is less common. I wouldn’t expect that from everyone, but it can
be quite helpful. It organizes this stuff.

Have you ever seen a graphic designer apply for a job?

When they arrive for their interview, they come in, holding a large, flat,
black case. It’s called a “portfolio,” and contains samples of their work.
They often also contain interim work, showing the person’s process.

Even students, fresh out of school, are expected to have one. It’s so
standardized, that companies don’t even mention the need to bring one with
you.

Today, it’s probably quite common for the portfolio to be digital.

No design company on earth would ignore that, flip a matchbook into the
interview table, and ask the designer to “draw Spunky,” but that is _exactly_
what most tech companies are doing, these days.

Basically, what I am saying, is that many folks have a lot of pretty good
stuff available as some kind of portfolio, and it’s, quite frankly, ridiculous
to think a whiteboard test will tell us more about someone than that.

Even if the work is not suitable for our use, it can be the structure for a
conversation. One of my favorite things to do, in an interview, was to find a
“story” the applicant wanted to tell, so a lot of my questions were designed
to find the “hook,” where they suddenly smiled, and started to tell me about
problems they solved, or teams they worked with.

Those conversations are _gold_. They are what we look for. All the rest is BS,
and many developers aren’t “people persons.” Getting them to “open up” like
that is really the job of any interviewer.

It has been my experience that hiring managers and recruiters completely
ignore portfolios. Even companies that ask for GH or HN handles seem to ignore
the contents. I think they just want to find out if people have them, as some
kind of “cultural flag” (I have also seen a lot of GH handles that tell me the
developer is not so good, but I’d not know that, unless I looked; and what
people write here...well, not so sure that’s helpful to convince managers that
we’d be good team members).

[0] Don’t take my word for it; look for yourself:
[https://github.com/ChrisMarshallNY](https://github.com/ChrisMarshallNY)

[1] This shows the reach of the project. It’s a “live” dashboard:
[https://tally.bmlt.app/](https://tally.bmlt.app/)

~~~
quickthrower2
Graphic design is a bit different in that it take a lot less time to evaluate
than code, and you can probably use IP protected work in your portfolio, since
it is protected as a trademark not as a trade secret.

Yes you have, prima facie, written good code. I don't have 2 hours now to
fully critique it though. If I were interviewing you and using this code to
see whether to hire you, I need to do a lot of work to see if (a) you really
wrote it and (b) it is well engineered given the problem space. I'd mark you
up for the great documentation though - I can see at a glance that there are
lots of code comments, and a good README.md - so that is positive. But it's
not a deciding factor, I still need to see if you can code.

If I am looking at Githubs, well I have 20 candidates. 20 different code
bases, trying to achieve 20 different things. That's a lot of work to weed
out. I don't mind that at a late stage, but not an early one. Some companies
say - 2 hour coding test or BYO open source project - BUT that should be a
small volume and you need screening rounds before that.

However if I were interviewing you and gave you a leetcode or similar test, I
know the answer, and I can probably run some auto tests on it. Much easier and
practical for early rounds.

Also switching it around a lot of good devs don't do side projects at all.
Doctors who do doctors without borders are probably better on average (?) but
would it be a hiring criteria?

Or builders who help their local church rebuild a wall.

Builders can have portfolios. Luckily that can be based on the work they were
paid for, due to IP not being an issue. When a new architectural techniques
comes out, say a new kind of render, they can add this to their portfolio. If
a new tech comes out, say "Rust", I need to make a mirror project for my
portfolio as the work project is IP protected. I need to build that church
wall to get a job if a FOSS project is expected.

~~~
ChrisMarshallNY
That (a) is amusing. I’ve encountered it before.

If someone is able to hack GitHub to fake tens of thousands of lines of high-
quality code, ten years of commit history, dozens of Medium articles and blog
entires, multiple Web sites, and documentation up the wazoo, then you should
hire them on the spot; even if they are fronting for a Hyderabad shop.

Like I originally said, and this goes double for small teams and startups,
_every employee is a huge commitment_. I would gently suggest that
“shortcutting” the process is kind of reckless. It’s pretty easy to figure out
if someone wrote something, by simply saying “This project you did is pretty
cool. Tell me a bit about it.” Bang. You just struck gold. A portfolio would
be a perfect opening for these types of questions. I would struggle to find
those "hooks," with some applicants.

In my stint as a manager, I had to fight like hell for every headcount, and I
kept employees for _decades_. There was _no way_ that I’d “shortcut” that
process.

YMMV

I think that we’ll be seeing a lot more open source for proprietary work, in
the future. Decompilers are so good, that it’s damn near impossible to truly
hide how we do stuff.

Another thing that needs to DIAF, is the "shower clause." This is the clause
in the employment contract that says "Every idea you come up with in the
shower at home belongs to us."

I didn't have it with my job, so I was able to design a lifesaving
infrastructure that is being used by thousands of people around the world, and
has now been passed on to another generation of engineers. It's going to
become a ubiquitous infrastructure, and will directly impact many, many lives.

That would not exist, if I had had a "shower clause."

If someone has a great idea in an extracurricular venue, then don't try to
bully them into handing it to you for free. Figure out another (more
equitable) way to get it.

The whole deal with employees, is that we're not "Programming Modules." We're
_humans_ , and we need to be treated as humans, from the job ad, to
retirement.

