
Hiring Developers: look for the ability to abstract and not for experience - rinchik
https://blog.rinatussenov.com/hiring-software-developers-look-for-the-ability-to-abstract-and-not-for-experience-24ac483cc1ea
======
cyberpanther
The problem is most people get abstractions wrong. Abstracting too much can
lead to Architecture Astronauts.
([https://www.joelonsoftware.com/2001/04/21/dont-let-
architect...](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-
astronauts-scare-you/)) And not abstracting enough can be a mess in your code
and make a product dull.

By focusing too much on abstraction, you’ll get a really lopsided team. And
remember it only took one really abstract thinking Willy Wonka and a bunch of
oompa loompas to make really great candy. Too many Willy Wonkas and nothing
would ever get done.

Lastly, most people only get abstractions right with experience. So there is
still some value in experience.

~~~
ben_jones
I often get abstractions wrong the first time through. Usually the second or
third attempt (often days later) I'll come across something concrete that can
be put into production. So while I agree abstraction in and of itself is not a
silver bullet, the ability to _iterate_ on abstraction(s) is immensely
valuable.

Also the plain desire to seek a better abstraction despite a "working
solution" is a powerful trait when kept in check. The desire to continually do
better that is.

~~~
crdoconnor
Yeah, the best abstractions I've built have been 3rd or 4th iterations after
persistently refactoring to account for unexpected impedance mismatches.

I'm skeptical of the notion that great code is designed up-front by "clever
architects". I think the best code is usually the result of dirty hackjobs,
persistently refactored into clean code.

------
meesterdude
> Ideally all our interview problems should be built in a way that even a non-
> technical person with highly developed abstract thinking could answer.

why is this any kind of ideal? What about reality?

> your current technology stack is also irrelevant, the right candidate with
> great cognitive capacity will be able to adapt fast, pick up new things and
> bring new ways and ideas, breaking your team’s or company’s tunnel vision.
> Their fluid thinking and almost extreme ability to identify and extract
> patterns will exceed anything you have expected.

Hire a superstar that will steamroll your existing developers - great advice.
Let's not worry if they're collaborative.

> I can’t stress enough that hiring based on your current technology stack or
> domain is extremely wrong. Never do it. Never. If the only reason you are
> bringing on board new developer because he has a lot of experience in your
> domain or with the CMS, programming language or framework that you are
> using, then you are making a kind of mistake it is very hard to recover
> from.

don't hire them for any real reason you might have? Sounds like real sage
wisdom.

This post is classic silicon valley. Out of touch with reality, and
discriminatory towards diversity. People are different. No person is more than
one person.

I have a lot of experience with hiring software developers. This is mostly
drivel.

You want to hire talent? Offer good pay, interesting work, and freedom to do
it. That's step one. Step two is finding people who can do the work in the
given domain(s) of your organization, and step three is finding people who can
do said work with your team. There is no step four.

~~~
rinchik
Good points.

I think the topic is more complex than just finding an oompa-loompa for your
current technology stack. If you think about long-term benefits for the team
and company as a whole, it will be highly beneficial to bring highly able,
rational and driven people on board.

I'm guessing what you probably have in mind is consultancy, where you need a
highly specialized individual to complete this, one, particular project, which
is very different from full-time employees.

Also we need to carefully start destructing and eliminating this stigma around
people who are being perceived and labeled as "superstars". Great mental
capacity and ability does not imply bad social skills. This marginalization
hurts the industry.

Great note about collaboration! This post doesn't cover an entire hiring
process, just one aspect of it. Collaboration and communication skills are
definitely a must.

~~~
sz4kerto
> If you think about long-term benefits

One long-term benefit is a company that's alive. If I need feature X to be
delivered in 12 months for because that'd benefit the company immensely, then
I rather hire someone who can be productive on day one (as she knows the tech
stack, has experience with similar problems, etc.) than someone who re-
imagines how our tech stuff is implemented. The latter is also useful in some
cases, but article somehow claims that this is the general rule. No, it isn't.

~~~
xstartup
>> than someone who re-imagines how our tech stuff is implemented. The latter
is also useful in some cases, but article somehow claims that this is the
general rule. No, it isn't.

I guess you work in a service oriented company and not the product because
this is exactly what results in a bad product.

~~~
TheAdamAndChe
Not always. Think of how Google has repeatedly tried to reinvent the world
with their 20 messaging apps. That inconsistency combined with a lack of
steadfastness and a tendency to shut down old apps has prevented their
products from thriving, and hurt their reputation in the process.

Just like everyhing else, the optimum strategy varies from project to project.

~~~
dasmoth
The Google that released something new every week (and had beta tags
everywhere) did at least seem to be able to innovate. And some of that
innovation stuck (and even some of the things they probably rated as “misses”
had lasting impact — witness the various Reader clones...)

I’m struggling to think of Google changes in the last few years that have made
the slightest difference to me as an end user. Except maybe tweaks to search
that make it less useful for any vaguely obscure query.

------
dwaltrip
Perhaps I'm misunderstanding what the author means by "no connection to the
real world", but good abstractions should be deeply connected to reality.

Wikipedia describes abstractions as:

> a conceptual process where general rules and concepts are derived from the
> usage and classification of specific examples, literal ("real" or
> "concrete") signifiers, first principles, or other methods.

> Conceptual abstractions may be formed by filtering the information content
> of a concept or an observable phenomenon, selecting only the aspects which
> are relevant for a particular subjectively valued purpose.

[https://en.m.wikipedia.org/wiki/Abstraction](https://en.m.wikipedia.org/wiki/Abstraction)

~~~
platz
"Being abstract is something profoundly different from being vague … The
purpose of abstraction is not to be vague, but to create a new semantic level
in which one can be absolutely precise." \- dijsktra

OP is confused about what abstraction is actually _for_

~~~
ramzyo
What a great quote, thanks for sharing!

~~~
mikmoila
Another: "Abstraction is selective ignorance. - Andrew Koenig."

~~~
danidiaz
Two more:

"The abstract is no more than an instrument, an organ, to see the concrete
clearly." —José Ortega y Gasset

"Good general theory does not search for the maximum generality, but for the
right generality."—Saunders Mac Lane, who knew a thing or two about
abstraction

~~~
notduncansmith
I’ll drop one of my favorites, from Ken Iverson’s “Notation As A Tool Of
Thought”:

“The utility of a language as a tool of thought increases with the range of
topics it can treat, but decreases with the amount of vocabulary and the
complexity of grammatical rules which the user must keep in mind. Economy of
notation is therefore important.”

[http://www.jsoftware.com/papers/tot.htm](http://www.jsoftware.com/papers/tot.htm)

The full paper is wonderful and will make you a better developer.

~~~
platz
This one seems odd. Jargon is a barrier, but also an efficiency to the extent
is solves a problem.

~~~
dwaltrip
Jargon should be as minimally complex and extensive as needed to express the
relevant concepts, given the context.

The complexity and amount of jargon is proportional to the difficulty of using
that jargon, so overly complicated jargon imposes an unnecessary cost on
everyone who encounters it or interacts with it.

It sounds like you are saying that jargon is good if it can more effectively
express some idea than was possible before. I totally agree with this, it's a
great point.

But sometimes the additional expressiveness does not compensate enough for the
unfamiliarity or peculiarity, making it not worth it, and so it probably won't
be adopted by others.

------
jondubois
I disagree. Programming is a social activity. Developers who are too smart are
not necessarily good developers.

They might overengineer things and make them more complicated than they need
to be and it just slows down everyone else in the team.

Good engineering is really all about empathy and psychology.

~~~
white-flame
If somebody cannot abstract, then they will not be a good software developer,
period. Code will be copy-paste, genetically engineered, and not understood
even by the author why it does or does not work, meaning an inability to
document it or even explain it to coworkers.

Assuming people can keep fully in mind about 7-10 things at once, a person who
can abstract can keep entire constructed systems in mind as one of those
"things". A person who cannot abstract will only be able to hold that many
immediately tangible source-code level concepts in mind, having a hard limit
on the amount of complexity they can have in their projects before their
mental organizational capabilities collapse, in the same way people throw up
their hands and give up at math problems that are beyond them.

It's a necessary but not sufficient skill; as you mention, social tuning and
business mindedness tend to round out effectiveness from just raw skill.

And if somebody's being an Architecture Astronaut in their "abstraction", then
they're not abstracting what they're doing in context of making a workable
system; they're just rote copy-pasting architectural memes that they think
matches a pattern, just like the ineffective programmer.

~~~
GuiA
This seems like a strawman. Are there any humans with a high school
diploma/college degree who "cannot abstract"?

~~~
white-flame
It's obviously about being able to abstract computational processes and
programming constructions, as done by Developers who are Hired to build
software.

And yes, I've dealt with real people on all ends of this spectrum, and there's
stark common denominators in their respective successes and failures. That's
not to say this article is any good, but the skill of abstraction is still
paramount to software development.

~~~
GuiA
Sure, but phrasing it as “abstract/can’t abstract” seems reductionist and
arbitrary.

By and large, the overwhelming majority of humans will bring you a cup or
bottle of water if you ask them for “water”, rather than bringing you water in
their cupped hands. Clearly all these humans can abstract.

If this conversation is to be meaningful in any way, it’d be helpful to use
well defined, measurable properties (“can count to 10 without using their
fingers”) rather than fuzzy things like “they can’t abstract” which is clearly
plainly false.

Otherwise, these conversations merely devolve in “10x programmers are real and
I only hire 10x programmers!” vs “anyone can be a 10x programmer given the
right environment” and it just doesn’t go anywhere.

~~~
white-flame
Again, you're projecting things nonsensically into non-programming fields.
There are plenty of wannabe programmers out there who simply like computers or
like the idea of money in the field, who regardless of age cannot muster the
required abstract thinking as applied to programming to be a developer that
can put out minimum-acceptable-quality code.

Regarding your last sentence, that's why I've been careful to call it a
"skill", because it can be exercised, apprenticed, and gleaned. But for some
people it just never gels.

This isn't the distinction between "10x programmer" and "regular programmer",
it's the distinction of "has programmer skills" and "does not have programmer
skills". And as much as the pointy-haired inclined hate it, software
development heavily involves creativity and bespoke research, for which
there's no reasonable objective skill measure besides simply doing the work.

------
dep_b
I think there can be different reasons to hire someone.

If I'm running a project and I'm having all kinds of problems to get my
node.js performance to an acceptable level I'd look for a programmer that
knows how to tweak node.js and all parameters associated with it (scripts,
server, OS).

If I'm starting a project and I already have a node.js specialist aboard and I
need to hire someone for the long term I can basically hire anyone with the
right talents.

But it's a very different story depending on the parameters.

------
kylnew
I generally agree with this article and wanted to just post some thoughts I’ve
had on this when it comes to hiring juniors out of boot camps when the
expectations of CS knowledge would be tough.

1\. I think they need more than 1 project, either in your domain or multiple
domains better yet. To me this is one way of demonstrating abstraction
capability.

2\. Ask a problem that involves modeling several objects where a hierarchy
might be involved. Ie modeling a service like Instacart, that has both
customers and employees, but maybe are all types of Users. Do they catch on to
these common traits? A question like these can even extend to more senior
roles it may just be a matter of how much hinting.

3\. I still believe some sort of whiteboard challenge has value, but make it
fair. A lot of O(n) type problems are straight forward looping over array and
doing work type things. These aren’t killer gotcha problems intended to haze
or assess depth of CS skill, they are for stimulating dialogue. I was anti
whiteboard for a while, particularly because I felt like I was hazing, even
when I gave lots of time and did everything I could to make the candidate
comfortable. But without it I feel something is missing. So my new principle
is just don’t make it tricky.

~~~
madeofpalk
> [not] intended to haze or assess depth of CS skill, they are for stimulating
> dialogue

This 100%. We do an in-person 'pairing exercise' where they work on a
simplified tax calculator. We expect people to solve the problem, but really
what we're looking for is their thinking and to see _how_ they solve it. By
gradually ramping up the requirements/difficulty, and by asking more questions
we're able to learn a lot about the applicant.

~~~
kylnew
I really like the idea of pairing exercises too. I’ve done an interview before
as the interviewee where I didn’t actually do the typing but did all the
dictating to build out a class with a TDD approach. It never felt like I was
under heavy scrutiny and there was so much conversation. It’s amazing when you
walk away from an interview feeling like the experience was
positive/educational regardless of outcome.

------
booleandilemma
Hiring Doctors: look for the ability to abstract and not for experience.

Hiring Lawyers: look for the ability to abstract and not for experience.

Hiring Mechanics: look for the ability to abstract and not for experience.

What is with this industry and its strange disdain for experience?

------
pixelperfect
> _Ideally all our interview problems should be built in a way that even a
> non-technical person with highly developed abstract thinking could answer._

This technology is more than a century old and is called an "IQ test."

But giving IQ tests is legally dicey, so SV companies use algorithmic
challenges instead.

------
cjcenizal
Funny, I see where the author is coming from and agree to an extent: capacity
for abstract thought is marked by ability to mentally manipulate concepts, not
things.

But in software engineering, I think the ability to analyze the information
which constitutes a domain and then synthesize ergonomic abstractions out of
that information is more relevant. Martin Fowler would call it domain
modeling, I just call it software design.

Of course I also obsess over names of things, interface design, and mental
models, so I’m biased!

~~~
rco8786
I didn’t read the article, but what you described sounds a lot
like...abstraction. Right down to using the word explicitly.

~~~
s_ngularity
I think he's trying to get at the distinction between being able to think in
abstractions versus choosing the correct abstraction for the problem at hand.
The first is a prerequisite for the second, but the second is far more
important.

------
aytekin
I have done countless developer interviews. I did bad hires and made good
hires. Two things I learned:

1\. Get them to write code (using their language of choice and google searches
allowed when stuck)

2\. Did they do any projects on the side?

A lot of people who sound great on paper can’t write code. Or write shitty
code. People who are passionate about their work read a lot and do side
projects.

~~~
rco8786
I hate the side projects trope. I’ve worked with tons of great engineers who
have lives outside of code.

~~~
mlevental
you know what i hate? recklessly divisive rhetoric.

a life out of code and side-projects: the two things are not mutually
exclusive. op isn't suggested he expects candidates to have written an os
kernel. all op says is he/she looks for side-projects. if you were really
interested in discussing the matter you would've asked some exploratory
questions (e.g. what is the threshold for substantial side-project). then you
would've really had an interesting conversation (because it is possible to
have a life outside of programming and still be interested/engaged enough to
have a couple of small side projects. and it's completely fair to expect
engineers to get extra training. many many many other professions have exactly
the same requirements. doctors/dentists have to regularly get re-tested on
certain skills/attend conferences/etc.).

but no instead you with the one-liner. try just a little harder and maybe
you'll actually change someone's mind that's blindly obsessed with side-
projects.

~~~
rco8786
I seemed to have hit a nerve with you. Sorry if my comment offended you. I
have no interest in actually discussing what constitutes a side project and
what doesn’t. Let me more clearly articulate my point:

Side projects have no bearing on the quality of an engineer.

~~~
lsadam0
But quality side projects are quite helpful in identifying a valuable
engineer. A lack of them is not a warning sign either.

------
tasuki
The ability to abstract surely is important. However, I find the "four levels"
a little strange. The first three aren't even abstractions! Abstract is the
opposite of concrete. Abstraction is by definition not a concrete object.

~~~
SAI_Peregrinus
And there's at least one extra level: the ability to think about things that
can't be imagined.

It's not that difficult to visualize a hyperbolic plane and learn to visualize
hyperbolic space. It's much, much harder to visualize the real projective
plane, and essentially impossible to visualize a quaternionic projective
space. Yet these can still be worked with using geometric and topological
intuition in a way that feels (to me) fundamentally different from
manipulating abstract formulae or matrices.

~~~
tasuki
This is a great point. I wanted to add something along those lines but wasn't
able to formulate it this well.

------
jrochkind1
So how does one screen for abstract thinking in an interview process?

~~~
mixmastamyk
Was waiting for this in the article, then it ended.

------
ddebernardy
Just have a senior software engineer or two supervise mathematicians (or to an
only so slightly lesser degree, physicists). The latter are excellent at
abstraction, usually pick up programming languages in no time, and can readily
get steered towards using software best practices by their senior peers
provided the latter can articulate a rational explanation as to why this or
that best practice is just better.

~~~
potta_coffee
I hope you're joking. I've worked with these kinds of academics and while they
tend to have excellent capability for abstract thought, they also tend to not
give a shit about practical matters like usability or even just shipping code.

------
guelo
If you step back for a moment it will be obvious that the idea that experience
is worthless is just plain wrong. Many times I have had to deal with the work
of supposedly genius coders that is either a complete reinvention of some
standard way of doing things for no benefit or overly complicated because they
weren't aware of known simpler solutions.

A humble strong programmer who stands on the shoulders of the aquired
knowledge of their whole industry and has learned from his failures and
successes will always beat the arrogant but naive 10x super abstracting
genius.

~~~
Bucephalus355
Yeah what I got from this post is “discrimination against older Americans”.

~~~
IncRnd
I've seen this type of hiring practice, and most of the time it was to hide
the desire to hire monkey coders who are micro-managed. It's a shame for the
coders, as it can destroy their abstraction capability, while pretending to
foster it.

------
s0mesayitsluck
I see abstraction as the ultimate misconception of modern software engineering
/ development.

There's so much abstraction nowadays, software developers have not the
slightest clue what they are doing anymore besides copypasting some framework.

We're basically at the point of developers competing in abstraction without
any fundamental understanding. "I can do this with only two lines of code."

In terms of the article, those people getting hired, are not necessarily the
ones especially good at abstraction. They just have experience in what others
have abstracted for them, to use as a tool.

