Hiring Developers: look for the ability to abstract and not for experience
blog.rinatussenov.com
blog.rinatussenov.com
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.
An interesting difference between software and mass-produced physical goods is that a single Willy Wonka can do a fair without needing oompa loompas. It’s not an especially fashionable way of doing things right now, but don’t dismiss the possibility.
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.
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.
- Ability to abstract.
- Ability to communicate their abstraction.
- Ability to reuse abstractions.
- Ability to accept and work with colleagues abstractions.
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.
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.
See point one. It's up to you if you have oompa-loompa work to be done or are trying something entirely new. But the reality is there is a lot of talent out there - the oompa-loompas are out there too, but it's for low paying, uninteresting work (which i tried to exclude).
> 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.
no. The point I was trying to make is that we can overthink hiring, when in reality it's not that mysterious. And the reason hiring is so bad in the industry is because we think it's something it's not.
> 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
The stigma is not around "superstars", but the quest for them and solely them in our industry. We as an industry are hyper-focused on this one type of person and missing out on all other kinds of people than can bring a variety of things to the table (aka diversity). The stigma is not that superstars are anti-social, it's that non super stars have nothing worthwhile to contribute. Which is just a recipe for the classic SV echo chamber.
Diversity might be good for an established company but for a startup, it's not important at all. I encourage everyone to look for the right person and not waste their time on others. It's their startup, they are the person taking all risk. It's up to them to figure out what kind of person is best fit to solve their problem. After all, they've thought about both problems and solution and long enough to consider taking this risk. It's all or nothing game, no person who succeeded elsewhere can be deemed qualified to change their perception.
If you need a superstar, chase him with passion.
You're right, it's not important - it's critical. Diversity means stretching boundaries, broader perspectives, and greater quality; not to mention playing a huge part in shaping the company's culture and values.
There are a lot more amateur & semi-pro basketball players in the world than in the NBA. Make sure you're playing a game that requires all star gameplay (like space jam!) before setting the bar that high. Most games just need players who are reasonably good. And likewise, beware what happens when a team is packed with nothing but allstars - they all play their own way but not together (and typically lose)
The knowledge acquired through their backgrounds will have taught them different approaches to problems, often allowing them to pick a better solution to a problem in (as an example) the development of a web application than an equally experienced web-only team would've come up with.
Diversity of skill absolutely DOES NOT MATTER in a startup. You really want to get your money's worth on a team that will not stumble and leave a project in limbo due to technical issues (which can easily kill any small company); and for that you always want to get the best possible talent.
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.
I guess you work in a service oriented company and not the product because this is exactly what results in a bad product.
Just like everyhing else, the optimum strategy varies from project to project.
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.
Do employees these days stay long enough for a company to even be able to think long-term?
How about just offer good pay and don’t pretend like email archival or configuring LDAP or trudging through poorly-designed databases is sexy, exciting work because it isn’t?
Bad news: most work isn’t interesting, and I absolutely loathe when companies, even “exciting” startups that are “changing the world”, pretend that configuring their Jenkins server is somehow life-altering, fulfilling work.
Most work isn’t interesting, and that’s fine. I don’t mind configuring Jenkins, or setting up LDAP, or fixing crappy databases, or writing Yet Another Feature. I’m good at those things, and a job well-done is certainly satisfying, but let’s not pretend that my 9 to 5 is anything more than a job. I get excited about my job like I get excited about going to the dentist: it’s something I have to do to maintain a good life, and while I am certainly more than willing to do it, I don’t try to pretend like it’s particularly fun or special.
This is 100% fair as well. Some companies really do have interesting work and problems to be solved, and the work is enjoyable and satisfying. But I get that all work won't be like that, and there may be plenty of boring work as well.
in your case, i think what would be relevant is making it known that these technologies are used, and that they are configured in the best way possible to ensure they're maintainable. If it's going to be boring work, it should at least be orderly.
Another issue however is that there truly are people who like fixing database, configuring LDAP and other similar practical work. I have met them. They don't find that life altering, but they dont want life altering. They want to come to work, fix stuff, do the job and go home.
There is no universal interesting work. What is interesting to me is not interesting to you or other people. I enjoyed fixing bugs in someone elses code, I found it interesting challenge, but quite a lot of people hate it. I like large long lived projects, quite a lot of people hate them. Too many people think that what they find interesting is what everyone finds interesting.
What happens in this industry is that the company has a job that requires a lot of routine, but goes out of its way to pretend the job is exciting for people who don't. Because generic idea of superstar. So they hire someone who does not fit position at all. And they would not hire that person who would gladly do the routine thing to them and would be good at it, because he does not fit the expected profile of excitement.
As someone who has hired a lot of people and offered a 1M+ salary to some of them, they'll take your salary and start their own business with it. Pay what market will bear, never regret again. People are not that loyal no matter what you pay. Even if you pay someone lot more than what they worth, they'll attribute it to their talent and will never feel indebted or loyal to you. (as you might be thinking).
Quoted for truth.
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.
OP is confused about what abstraction is actually for
"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
“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
The full paper is wonderful and will make you a better developer.
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.
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.
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.
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.
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.
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.
Obviously this kind of complex logic is written by smart people who can keep long chains of logic in their minds but it doesn't mean that it's a good thing.
A less intelligent developer would probably have a hard time keeping long chains of logic in their mind and so would be more likely to keep their code simple and readable... Which often means better code.
But it depends what kind of problem is being solved. If it's a very complex problem like working with distributed systems then complexity cannot be avoided.
I'm not sure abstraction is the correct thing to look for.
There's an engineering joke about the difference between an engineer and a hobbyist being that anyone can build a thing for $20, but you need an engineer to build something that works just as well - or better - for 20c.
There's a lot of $20 code out there. 20c code is much rarer.
This isn't entirely related to IQ or the ability to hold a model of the entire codebase your mind, although both help a lot if someone has a talent for seeing the essence of complex relationships.
Some people get there after a few iterations, some people never get there at all, and a talented minority of developers tend to get there on the first try.
I disagree.
I'll give you a team of psychologists and I'll take a team of mathematicians and we can see who can build the better software.
Empathy and psychology are game changers only when they are built upon a broad and deep base of analytical thinking and problem solving.
If the project is like a game or something heavy on physics then mathematicians will have the upper hand.
I actually did a project for a professor of psychology at a university in the US. They didn't know much programming but I was impressed by the specifications document which they sent me because it didn't have any gaps or inconsistencies like most engineering specifications that I've seen before. The requirements were very clearly expressed.
Being able to share very complex ideas with a high degree of accuracy is is an extremely valuable skill.
Interesting. I've taught third year maths and psychology students and the maths students almost universally produce more sophisticated applications.
Of course it's hard to directly compare because the courses had different focuses.
> because it didn't have any gaps or inconsistencies
Mathematicians are very good at this - where they might fall down is eliciting complex requirements from others.
> like most engineering specifications
This is more of a deliberate choice on software projects than a lack of ability.
I remember the pre-agile days and specs were a lot better.
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.
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.
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.
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?
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.
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!
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.
But all other things being equal, when looking at code, it literally comes down to practice. The more code you've written, the more things you've had to research and the more mistakes you've already made, the faster you'll be able to produce good code in the future.
Side projects help that aspect. Because there's only so much you can do and learn during your day job. You can always make up for it with other skills, experience, or just the difficulty level of the projects you've been on and nail the job anyway.
Side projects help people who DON'T have all of that nail jobs. They can go "Look, I may not have worked for Google, or I may be only a few years out of school (if I ever went to school), but I made up for it with these projects".
And of course, you can always have both :)
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.
Side projects have no bearing on the quality of an engineer.
I started the latest one during a 1 week transition between jobs. I was able to work full time on it while my SO was working. Since then, I have been working between 0 and 10h each weekends. I usually only read (both code related and general litterature) during week days.
It’s entirely possible, just requires a bit of organisation.
Some company that doesn't want me because I don't have side projects, that's fine, they saved me the trouble.
My current side project is a Rack framework for making OpenAPI3-first APIs. "It's certainly not Twitter in a weekend." I learned Swagger/OpenAPI 2.0, so I used grape-swagger; found it frustrating and limited to OpenAPI 2.0 so now I'm using OpenAPI 3.0 and writing `Modern` to properly embed my understanding of it.
If I were looking for a job (I'm not), I would fully expect that this speaks to my understanding of and my comfort with designing and implementing good APIs.
These were generally people who did really great work while using normal hours, but who would put in the hours when necessary, such as during a deadline push. Often their organizational skills and general engineering hygiene helped keep the crazy hours at bay.
At night these people went home to their families and led their lives. Some were good woodworkers or were into other hobbies, some did sports, some taught classes. Oh, a few wrote code [I do], but not that many.
Don't get me wrong: Side projects can be an interesting window into how a candidate works and thinks. But if you use them as a hard requirement then I'm pretty sure you're missing out on some great talent.
I never, ever ask for side projects because it biases for younger programmers with lots of time and against all others.
Which, come to think of it, matches my personal experience. I have zero spatial ability---back in the 80's in California they actually gave us standardized tests in elementary school including a spatial ability section, and my scores were always like 90+%-ile math, verbal, and like 20%-ile spatial. Never been able to draw for shit. But was always advanced in math, 99th percentile lsat (logic-heavy) scores, top grades in stats, etc. So am I at the 4th level but not at all at the first three?
My definition of abstraction is moving from specific examples to more general systems. I definitely remember the process as I was teaching myself programming through my childhood of learning and improving my software abstraction skills in particular ways.
One type of abstraction that took a bit of practice to get good at when I was starting out like eight years old was recursion. I got better at using this type of abstraction by specifically practicing with the goal of converting loops to recursion.
Another type of abstraction is creating classes in order to reuse your code. This was something I learned about and gradually got better at over the years through practice and initially from a few books like Turbo Pascal Disk Tutor when I was in middle school.
Sure there are some innate abilities but I think it's not quite so cut and dry as the author makes it out to be with innate versus learned ability.
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.
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.
No. They are distinguishable from each other. One may feed the other, but they are separate.
> I don't really consider the ability to write a generic function (instead of copy-paste) to be the same as the ability to abstract. To write a good abstraction you need to understand both the underlying system and the consumption pattern to avoid abstraction leaks, boilerplate, hiding of useful features, etc.
You are confusing abstraction with data and function hiding. In the article abstraction means the ability to meta program, translate one problem into a simpler generic problem, etc. This is a skill most of the industry lacks _in practice_. It is a skill that all 1% coders have, but it also doesn't make experience go out the window.
That can absolutely be true. Though, seeing other's abstractions is not always helpful, if what they created was poorly done or ill-thought through.
At least if I'm thinking for myself, my ability to abstract seems to have steadily increased over the years; PeterisP-10-years-ago was much worse at this and the changes were mostly driven by experience, seeing how all kinds of different systems are built, which kinds of abstraction tend to work out in practice and which seem nice at first but turn out to be horrible after a few years.
Heck, machine learning is basically abstraction as well, and it is something that arises naturally with intelligence. Good programmers must be especially good at it, but so do many other professions as well (even say doctors).
"I want to say that I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong"
"This is especially useful when you are hiring junior developers. You are not looking for hard practical skills, instead you are looking for the potential."
Clearly he is talking about keyword based hiring
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.