This blog post is all about how spoiled we are when it comes to our salaries :), why theory alone doesn't make you a "senior", that stepping back may be the best way to make a meaningful step forward, who is Salva Ballesta, why you need to start finishing & why skills make only 1/3 of proper candidate evaluation.
Disclaimer: not all companies are alike, not all hiring managers are alike & there's always someone desperate enough to break all the rules :) What I present here is my point of view & the rules I follow personally. Feel free to disagree, I don't mind :)
I do a lot of technical recruitment. It's time-consuming & draining emotionally (if you want to do it right), but that's the investment (in team & engineering culture as well) I find absolutely necessary, so I'm not complaining :) Especially as talking to so many technical candidates ...
- ... makes me able to meet a lot of interesting people
- ... keeps me up-to-date with current job market situation - trends, fluctuations, big shifts (e.g. due to new, large players entering the local market)
- ... (at last but not least) helps me trace the changing attitudes of subsequent developer "generations" - what they expect, what they look for, what drives them & how they perceive job in general
Today I'd like to focus on the 3rd point from the list above - I don't mean to cover it end-to-end but rather focus on some interesting misconceptions I've seen recently frequently enough to convince me that they are quite common. Here we go then ...
A. "Senior" theoreticians
"I've read the best book on technology X (incl. the part marked as "Advanced techniques"), I've been at 2 meet-ups about it & yesterday I've seen a related conf video as well. Indeed, I may have not used it in anything more advanced than a tutorialesque sample, nevertheless I am clearly an expert on the topic now, hereby applying for a Senior Developer position ..."
No, you're not (an expert).
Real-life is incomparably more complicated than any tutorial. Books present just the basic syntax & happy path scenarios - the best of them qualify as great STARTERS for you to begin a particular tech journey. Our industry (software engineering) is all about hands-on & practice - ability to apply theoretical knowledge, our past learnings, abstract thinking, communication skills ... and many, many more ... to build great products.
Books don't make you an expert, they make you a novice candidate for a particular technology practitioner. Howgh.
B. Salary obviously always has to go up
I've worked for X years in company Y. I've proved my value there & my current salary is Z - obviously I'll move only if you offer more than that, this doesn't need any clarification, right?
In theory all of that makes perfect sense. But it doesn't :)
Your current value in company Y is not defined only by your "absolute" skill level that can be utilised in the very same way (& with similar final effects) in a different work environment. You may have been worth Z because ...
- ... of specific domain/product knowledge you've accumulated (that will be useless out of your current employer)
- ... company Y may have fallen into a dependency on you (bus factor ~1) - either you've siloed knowledge or its other bearers have already left, so that Y absolutely can't afford letting you go
In fact it's a trap. A very dangerous one.
I've seen people who've worked for several (6, 10, more) years in the same organisation doing pretty much the same stuff & not developing themselves (so called "10 x 1 year of exactly the same experience") - the distance between their value for current employer (well, someone has to take care of the legacy ...) & the reasonable job market valuation was a whole abyss!
Their only response to the truth was a denial - they were blaming everyone but themselves.
C. Case of Salva Ballesta
Have you heard about Salva Ballesta? Probably not. He was a football player in Spain in 90s/00s - never considered a top talent, he played for solid, yet not top-tier club - Racing Santander. In season 1999/00 Salva has surprised everyone (probably including himself) by winning Trofeo Pichichi (award for the top goalscorer of the whole league). Major clubs were very surprised - how could have we missed such talent? Being a top goalscorer meant regularity & stable, high form during whole seasons - that could have not be accidental, right?
Long story short:
One of La Liga's powerhouses - Valencia CF - has bought Salva Ballesta in exchange for a full truck of money - it was their 2nd highest transfer ever (at that point in time). And (as it has turned out ...) one of worst transfer mistakes ever. Salva was not able to achieve 20% of what he has presented in Racing ...
In pretty much the same time Real Madrid has snatched another Racing's player - Pedro Munitis - for half of the money Valencia payed for Salva Ballesta. Who was Munitis? He shot some goals (8), but it was nothing when compared with Ballesta's score of 27. But apparently Real Madrid scouts was smart enough to look deeper - they've noticed that it was Munitis who was an architect behind Salva's terrific goal-scoring efficiency. It was Pedro who was creating goal opportunities, absorbing opponent's defenders & serving deadly opening passes.
Salva was useless without Pedro. His value was created mainly by his team - to be precise: by a particular team-mate - a real out-of-the-focus hero.
Back to software development: many junior engineers who were a member of a successful team in their first job, already do think they've reached the top of the world. Surely, they've done their job, but maybe there was someone else who did the heavy-lifting ... - something they are not even really aware of.
That's why single job, single project, single assignment is far from being enough to validate someone's capabilities - to gain epaulettes one needs to smell the gunpowder in the front-line of many battles, under different circumstances, facing various obstacles - that's how you harden the steel & eliminate the factor of sheer luck.
IMHO a candidate who've worked only in a single environment is a risk - not fully proven, her/his actual input into presented accomplishments may be far from what (s)he thinks her/himself.
D. Ones who can't stop starting
"I did a project in Angular, three in React, two in Vue, one in Ember, three in Aurelia. How many of them went live? I don't know, I didn't work there long enough for any of those to reach production - I was building the app & then the interesting part was done, so it was time to depart, so I could do something interesting somewhere else. I'm not much into maintenance ..."
Yikes.
So you've missed 90% of the learning.
None of your ideas (of how to build an app) were validated in the REAL life (real usage by the end-users). You can craft code using particular library, but there's no proof you can create products - maintainable, performant, efficient, effective, stable, etc. And that's what employers want to pay you for!
You may be good in starting, but this is the easiest part - the real challenge appears with the accumulated growth of codebase, pivots in business expectations, increased end-user interest, team's headcount increasing by 100%. The way you handle evolution of production-deployed system is how you prove yourself (& your market value) as a software engineer.
E. Skills are (only) 1/3 of success
"These guys have to be idiots. They didn't make me an offer, despite the fact I'm far better than any of the developers they currently have in their team. Pure madness, they can't even recognise top notch craftsman when they meet him ..."
Indeed, technically you may be a star, but that doesn't make you a good candidate for hiring.
When evaluating candidates, I classify them using three non-discrete measures: attitude, aptitude & skills.
- attitude is all about your motivations, whether you're task-based or goal-based, what are your personal goals & ambitions, whether you're a doer & problem-solver or a victimiser, how much grit do you have in your guts, what are your passions & what does drive you ...
- aptitude means both potential & adaptability (documented & proven) - how flexible (intellectually & emotionally) you are when facing new conditions/expectations, how fast do you learn & what are your constraints in the process of learning, do you think like an engineer ("engineering common-sense"), are you self-organised enough to progress & self-develop ...
- skills seem obvious, but ... they are NOT only about tech! Clear & focused communication, teamwork, emotional intelligence, domain expertise, leadership & teaching, foreign languages (when required) & many, many more. Preferably learned in practice, even if from your own mistakes. We want scars, scars are good :)
All of these three are equally important. And each candidate represents a different combination of them - some are strong in skills, but their attitude is abysmal; some have great attitude & beginner's skills, but their aptitude suggests that they will be able to catch on very quickly.
The secret is to properly recognise individual's features & evaluate her/him (also in terms of proposed salary) as whole - not being able to assess properly even one of these three measures may mean you've built a completely wrong impression: which may result in a wrong hiring decision (e.g. bringing in a skilful asshole, hopelessly unfulfilled talent or a dogmatic zealot) and/or wrong assumptions for future.
What would you say? Did you encounter these misconceptions "in the wild"? Or maybe you're facing some different ones that do not match (or even conflict with) the ones mentioned above?
All comments are more than appreciated :)
