A technical recruiter, having discovered that that the ways of Unix hackers were strange to him, sought an audience with Master Foo to learn more about the Way. Master Foo met the recruiter in the HR offices of a large firm.
The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
“I am learning to walk,” replied Master Foo.
“I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
“Yes, but this floor is new to me.” replied Master Foo.
It really depends doesn't it? Would it be a good idea to hire someone with 20 years experience in Python+Go+JavaScript+Perl+PHP for a C++ role? (note: my assumption is the first 4 languages rarely deal with direct memory issues were as the C++ role probably does. Ownership, allocation, deallocation, binary structure packing, more complex/low-level cross process issues, etc...
Not to suggest this all can't be learned.
Is GPU work unique or is it generic programming such that I should be ok to hire a programmer with zero GPU experience for a GPU role?
Similarly, sometimes you're hoping for someone that can be productive immediately, not after 2-6 months of getting used to something new. For example, I trust that a Java programmer could write C# or Swift or Python, but I'd expect the Java programmer to know the Java standard library and common solutions fairly well but not know the C#, Swift, or Python standard library. I get it might short sited not to hire them for long term growth but right this second I might want someone who can hit the ground running?
I was hired into my current role where a lot of code is in C# never having written any C# in my life. That was about six weeks ago. The interviewers correctly assumed that since I have written numerous other semi-colon languages for 20+ years and know what I'm doing it won't be a problem. I use some modern C# idioms (because to me no idiom is more or less "modern" as I learned them all in the last six weeks) more than my colleagues do, and I think I'm perhaps squinting at the async feature wrong, but it's basically fine at this point.
I would not have taken a C++ role. But that's because I don't like C++. Could I learn C++? Presumably, I assume it'd take quite a bit longer than C# but I don't want to.
A lot of programming skill that's transferable from one role to another is also transferable from one general purpose language to another. Almost everything about programming generally is transferable. All the practical implications of architecture is transferable. All the theory is transferable. Data structures are transferable (albeit if you've got very narrow experience you may not be aware of just what's possible). A lot of high level APIs are transferable.
On the other hand corporate knowledge isn't. So, the fresh graduate hire who is an expert in your preferred language does not know that around here nobody above an Engineer Lead reads their Teams chat, and nobody above Group Manager reads email. They don't know that tweaking the CSS requires a Design Team Lead authorisation because once somebody made the text the wrong colour and branding were furious - and they equally don't know that "Normal Minor" changes take six months to approve around here so they should mark small changes "Urgent Minor" instead and then pester a Senior Engineer to OK them, but never pester a Senior Engineer if it needs a Config change because that is an ops problem and... you are going to need to hire internally if you actually need them to "hit the ground running".
I am one of these python+go+javascript+perl+php folks (minus go and python)... Yet somehow I know about memory access and associated gotchas. I am even able to heavily modify, debug obscure C codebase. Even made my own LLVM pass that does quite a tricky modification of the LLVM bytecode prior to final compilation and linking. I learned about LLVM bytecode existence about 3 months ago. I started tinkering with this C project about 8 months ago...
Yes, there are differences, but they are not fundamental. And with google, it really takes little time to learn things on the go. And with a team sharing necessary experience it will take no time at all.
EDIT: "I might want someone who can hit the ground running" - this is luxury, so one wanting it gotta pay up... And such short projects where such quick ramp up is important perhaps will be a better suited for contracting out the work anyway.
Unless you are a startup that needs someone cranking out features within two weeks, the time it takes a senior[0] developer to get familiar with the company's actual work vastly outstrips the time it takes to get familiar with their commodity tech stack.
(And if you are such a startup, you want mostly senior generalists anyway.)
[0] Well, this is also probably begging the question. For me that's part of the definition of senior. Based on resumes I see lately it's far from everyone's.
We just hired some new guys who had never developed in the language we use. They had some Java, Python and PHP background.
Sent them on a course and within a couple of weeks they were committing stuff with minimal review needed in terms of language things.
It's now been a year and they're still learning about our code base. For me it took about two-three years before I felt comfortable on my own in the most-used areas.
> My current team will not hire anyone for a senior role, without Spark experience.
An example close to my heart. The company I'm currently at had a totally ossified Spark monolith and data eng team because they only wanted Spark developers. Drop one C++ developer in there to start spreading the good news about data-oriented design and suddenly there are a dozen previously-intractable "big data" problems we can rip out of the ball of mud and run outside of the cluster. Drop in another SRE who doesn't know shit about Java but can actually write shell scripts, and hey alerts from bad orchestration from weekly to twice yearly.
Yeah if you have a Spark job, you probably need a Spark dev. But if you have a team of Spark devs, suddenly everything that involves more than 1MB of input data looks like a Spark problem and you're in for a real bad time in a couple years.
Well... Funny enough. The person that our team of Spark engineers is cleaning up after was - a C++ dev. For some reason we, Spark engineers, had to rewrite his all Spark application into different components with relevant tech.
Thanks for generalizing Spark engineers to an insulting level, though.
I can't know for sure, but I think person you are replying to meant that in a team lacking diversity (in this particular case, diversity of expertise) all solutions tends to receive same, less than optimal treatment no matter what. If anything, it is insult of managers who create such bubbles, not engineers stuck in these bubbles.
> Thanks for generalizing Spark engineers to an insulting level, though.
I have no clue how you got that from what I wrote. I even said a Spark project needs a Spark dev!
It really sounds to me like you're the one generalizing from "the one C++ dev we hired couldn't do data engineering right at all" to "senior programmers are dangerous to us unless they are Spark developers" (which imo, is more indicative of serious deficiencies in your architecture / design process), to "all senior programmers crossing subdomains are dangerous."
I've solved serious problem using these two technologies, and it makes a significant impact right now. (sorry, can't discuss in more details).
Sure LLVM or C pro will cringe looking at my code. But the business problem is solved, by someone who is not LLVM/C pro, and there is no need for more of that LLVM/C skills for now at the organization...
> Similarly, sometimes you're hoping for someone that can be productive immediately, not after 2-6 months of getting used to something new.
I've often seen organizations spend 6 months or more to find the perfect Foo developer when they could have hired someone right away who had Foo-adjacent skills and was very willing to learn Foo.
Sunk costs, I guess? I feel like the idea that your codebase and business is so simple that all anyone needs to know to "hit the ground running" is how to use your build system and which ng-whatever keyword produces the right UI element should be deeply worrisome.
Let’s say you have a requirement for 5 years in a particular language.
Would you rather hire a developer with 20 years experience but only 3 in the language you want, or would you rather hire the guy who has 6 years experience in the language you want and that’s it?
Personally, I’d hire the former every single time, even though he didn’t have the requisite 5 years in the language.
Great point IMHO. I think the ability to learn these somewhat different languages depend on the experience. Like roots of different trees -- once you groked Asm/C, C++, Python and such, Lisp and such enough, you can get productive in most general purpose languages quickly enough that language learning time will be negligible compared to platform/ecosystem/domain time at least for any reasonably complex domain.
I think more pragmatic question in such situations however, is why the potential employer is requiring $A years of experience in $TECHNOLOGY. For example, why they need someone to be productive from the say day $N and what does it actually mean (for them) to be productive?..
IMHO getting to shared understanding of what drives such requirements can help find a better path forward for both sides.
Yes but then it is not comparable. Using GP's analogy, I would say Walking = Web Development (whether you do in PHP or Go, http is http etc). However, if you are talking about C++, let's call it "Para sailing" and not walking. Since you are not just writing a bunch of http API for the most part (I am simplifying a bit but you get the point).
> Would it be a good idea to hire someone with 20 years experience in Python+Go+JavaScript+Perl+PHP for a C++ role?
I my experience, when working in a programming job, your programming skills rather degrade quite fast if you are not actively working in your free time to work hard against this degradation.
I rather get better in programming almost exclusively by the side projects that I do in my free time.
So, I would rather say that x years of job experience show nothing; what is important is what you do in your free time (if such side projects are possible).
This depends hugely on your job. If you spend all day writing variations on the same crud app handlers then yeah, you probably aren't learning anything new after two years. If you spend twenty years in that job, you probably aren't the kind of person that wants to learn new things anyway.
This is a delight, but there is some truth to it. Walking in Paris is different than walking in Algiers. I need to watch my steps in Algiers more than in Paris. There are yellow tiles in the sidewalk that are slippery and I must not walk on them when it trains (us, ud friction stuff).
There also are loose tiles in Algiers that are similar to traps in the first Prince of Persia. You step on them, and they rotate to let your foot into the water.
Master Foo would do well in Algiers. This is not an instance where the master points to the moon and me looking at the tiles.
I like expanding a good metaphor, but I think the idea is that I wouldn't discourage a prospective tourist from travelling to Odessa, Ukraine* because of the belgian block streets or to Anytown USA because their road infrastructure isn't pedestrian oriented.
I would very much consider Odessa, Texas as “Anytown USA”. Not to mention I would question if the small town had Belgian blocks. I read the post as referring to Odessa, UK.
Not to take this into the realm of pedantry but unless you're referring the the United Kingdom, I should point out the country acronym for Ukraine is 'UA'.
By the number of "San", it either questions the sailor expression "a woman in every port" as either saints getting around a lot, or that the Spanish got around a lot.
I do mean Odessa, Ukraine. As far as I am aware Odessa, Texas was not built in the 18th-19th centuries so there would be no belgian block streets to be found.
Odessa was the 2nd or 3rd largest city in the Russian Empire and currently holds a similar status in Ukraine, afaik. This is largely due to it being a warm water port.
Tbh your comment is an exemplar g what OP said: most people who know how to walk have probably have fallen on slippery surfaces and slopes, so they can easily figure out what to do when though the rules are different ("yellow tiles are bad when it rains").
Yes. The example was a beautiful parable and I tried to write one, albeit more 'concrete' (pun intended on both concrete in construction and sidewalks, and programming with reference to concrete classes).
If you come from anywhere rural, watching your step in San Francisco is nothing. At least in SF you won't run into a cowpie that was barely submerged below the desert sand.
I’ve never been to Algiers but having done a lot of walking in Bangkok, I like this metaphor.
The fact that I love to walk in Bangkok proves that I am into Walking in a way more regular, more fit, longer-distance, better equipped walkers generally are not.
Dunno what the programming equivalent would be… maybe if you’re into coding Windows apps in Brainfuck?
Well, if you come to Algiers, hit me up. It's very cheap to live here. 1700 sqft ~ 170 square metres for 500 euros per month (this: https://mobile.twitter.com/jugurthahadjar/status/14513681938...). Hotel rooms downtown overseeing the sea for 15 euros per night.
The problem with this is that it works both ways. Someone who has walked on this floor already, who is familiar with the spot where it dips and the spot where that pole sticks out, will be able to walk more efficiently than someone who is walking across the floor the first time and must learn about these edge cases and gotchas specific to this floor. :)
It depends. There are people who's core skill is that they are amazing at learning generalizable lessons about approaching new terrain. They have a toolkit of methods that allow them to move into new territory and quickly gain competency, while avoiding most of the 'newbie' mistakes (or making them on the weekend on their own time).
Other people excel at going deep on specificity. They know every detail and arcane quirk about THIS specific language/build system/toolchain.
Both of these traits are desirable, but they will be great at slightly different things and under slightly different circumstances.
Well, let me clarify. It's not something that employers should expect from employees.
But it is a trait I notice in a lot of highly competent folk who are high achievers. They'll see something coming on the roadmap that they feel like they want to prep/educate themselves on, and then they will noodle on it for an hour or two when they get a chance. By the time it comes time to implement it 'for real', they have already gotten most of the learning curve out of the way.
And you are correct.
The issue is that there are very people who have walked this floor already, and many are already in the building (company) walking the floor. So, if you can find people who have already walked this floor, great, they may be better.
But, if you want access to a larger pool, then the next best is people who:
1) know how to walk and have been walking for years, and
2) have walked on many floors so that you can have confidence that they can walk this particular floor.
I imagine there must be roles in the programming world that are specialised enough for this to be true. However, at least in my own experience, it is mostly general programming ability and/or domain-specific knowledge that set one developer apart from another in the speed and quality of their work. Both of those take time to acquire and have value accordingly, but they are highly transferrable across specific tools. Soft skills also matter alongside the technical ones, and much more so as seniority increases, but it’s the same story there. I can’t immediately think of a field of programming where hands-on knowledge of specific technologies matters more than these other factors.
I think part of the problem is that many companies hire external staffing companies and expect them to find the "perfect candidate", and not someone who is "good enough". This combined with the Great Resignation means that both candidates and employers are likely being extremely picky with who they choose hire / work for. As someone who was recently on the market, it was rather strange to see so many companies desperate for talent whilst also being frustratingly meticulous with hiring decisions. I made the joke to myself that companies are being far pickier with their next hires at the moment than most people are with their romantic partners. The arbitrage opportunities in the market for human capital right now are just staggering.
But if you extend this analogy to ship captains, then you encounter maritime pilots, and their entire profession is dedicated to knowing how to sail in one exact geographical area.
Of course the cost of learning on the fly and making mistakes is ridiculously higher for piloting a ship through a certain area than it is for programming/software work.
I'd say that language use-a-likes are very easily fungible. Some incomplete examples: Java/Go/C#/Python/JavaScript/Ruby/Kotlin (service languages), Scala/F#/Haskell/Ocaml (functional languages), and C/C++/Rust (system languages). As long as they have experience in the same category you're good.
This isn't true at all. Its obvious for a senior/staff/principal engineer to claim that their skillset is infinitely transferrable to any job role that needs a staff level skillse, but its simply not true. There are tooling agnostic skills you learn (managing complexity, upleveling team members, how to actually be a technical leader and make improvements that a manager doesn't explicitly tell you to do) and there are tooling specific skills that you need in an organization (EX: dependency management in java, performance issues in certain DBs, the unwritten/not explicit API issues in different cloud platforms). If I am hiring for a staff engineer, I will be trying to get the combination of "tooling agnostic" staff engineering skills AND "tooling specific" staff engineering skills for my job opening because you don't end up paying more for an engineer that has a well matched "tooling specific" skillset, but they will be more productive. The net cost to me as an employer is simply time, I might need to source 3x the candidates to get a good fit, but its worth it.
One skill takes a decade to develop, another three months. I know who I’d choose.
You’ve substituted one cost, finding a unicorn, in place of training a good dev that is available. The old phrase, “a bird in the hand is worth two in the bush,” comes to mind.
Not only does your post sound unaware of the trade-offs but quite confident. A very fixed-mindset.
> One skill takes a decade to develop, another three months. I know who I’d choose.
Not only that, but a senior's job is to mentor junior. Having a senior dev familiar with another part of the stack brings a new expertise to any team. Like a compiler engineer realizing that the app team is basically writing a DSL...
This happened to me once... we were suffering with a broken system for a while. Then it dawned on me that no one on the team understood it was fundamentally a poor-man's broken finite-state-machine.
I agree with you but it's never so cut and dried. Some types of work take way more than 3 months to spin up. More like a year. So it's hard to figure where to draw the line. Maybe hire a promising smart junior if you're going to have to train them anyway?
Great. Now you've hired someone who already knows everything about all the languages / tools / platforms you're using, and won't "need" to learn anything new. How long do you think it'll be before they get bored and leave?
I don't think that it even is in senior developers' self-interest to claim that their skillset is infinite transferable, as it has the very obvious corollary that their skillset is worthless. The whole idea is much more appealing to the business side who wants to pretend that developers are fungible.
Quite the opposite. If skills are infinitely transferrable, then the skill level of a developer is a function of time they have spent in the field.
This makes a senior developer extremely valuable because they will always be more qualified for any job than someone more junior than them and there is a limited (and shrinking) number of people who are at their skill level or higher.
(to be clear, I don't believe that skills are infinitely transferrable)
Exactly, a senior frontend web engineer is not going to transfer to senior compiler engineer, or senior embedded engineer, or senior game-dev, without a substantial ramp up period from lack of domain knowledge.
But now the question isn't specific technologies it's in entire domains.
The counterpoint is that if I am proficient in Ruby, and senior level in Node, and work well in Java, I can figure out and be fluent in Python or PHP within a week or so.
Sure if you had someone that was working as an aeronautics engineer designing planes for years they probably would require more ramp up before being able to work on ICBMs, but they would do just fine moving from Lockheed to Boeing.
But you're failing to recognize that some tech is almost synonymous with a domain.
In my experience I've seen very cocksure senior engineers come in with the mindset that "this is just another tech stack, that I can learn in a week"... failing miserably to recognize that said tech stack is exclusively used in a domain that they're not at all comfortable with.
> a senior frontend web engineer is not going to transfer to senior compiler engineer
Arguably XHP/React is successful because some senior compiler engineers plied their trade in the front-end world. Or was it senior front-end engineers digging into compiler tech?
How about Servo pulling a bunch of game development techniques into the browser development world?
There are definitely technical domains you can gain or lack expertise in, but "frontend" vs. "backend" isn't one of them. Those are business contexts, not technical knowledge.
Now we’re getting from “experience” to “creative abilities and acumen”. Not at all easy to spot on most resumes. Also not easy to spot in most hiring processes.
I've got mixed feelings on this. If you give a good engineer enough time, he/she can figure out anything -- but there's a shortage of good engineers in the world these days -- and often a shortage of time.
We once had a senior guy that claimed he was "devops" and worked with redhat, but didn't understand the bash shell, nor what "export" meant. It would be one thing if he said he didn't know unix/linux and was learning because he had been working in windows all of his life, but he was as fraudulent as they come.
It would have been fine had he been acknowledging this, and seeking me, or others out for help, but instead he started sending his PR's to junior people for approval, who just simply assumed his code worked.
It worked great until a prod deployment failed, and I was the one who had to spend a late Friday night figuring out why it failed. Turns out if the guy had just run the script, he would have seen it fail instantly.
A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
There's just too much to know about browsers and underlying tech and a myriad it things.
Same for a senior frontend starting to work on a complex backend all with god knows how many interconnected technologies.
Being able to go from JS to TS? Sure. Being able to go from JS to Rust + Docker + (all your backend stuff here) not so much.
Unsolicited advice to all that read this comment and feel like it must be true.
A senior engineer has shown proficiency understanding complex problem domains and swashbuckling through the jargon to accomplish a goal.
If you pidgeonhole yourself in your career to just learning the jargon of one area then this comment might make a little bit of sense. If you keep abreast of words and what domain they're attached to, ramp up speed on any project of any kind has inherently less friction.
Keep abreast of words, all of them. Make toys that have nothing to do with what you're paid to build. Next time you're looking for new work -- don't let anyone strongly disagree with the fact that your experience on paper is in a particular domain. Just be able to walk the walk after you talk the talk.
I have and adjusted how I interview accordingly. Proficiency at the glossary problem of a given domain is for sure not the only thing worth covering in an interview :)
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
And I strongly disagree with you, and I have a real life example to disprove it (i know, a single data point is just anecdata, but still).
Our team was doing mostly web front-end (your typical TS+React+Webpack+etc., you get the idea), and we got an internal transfer about 1.5 years ago. Senior engineer, not a "rockstar coder" by any means. He doesn't spend his free time working on tons of side projects, he has other hobbies that aren't related to coding. Just a really solid engineer all around.
Here is the catch: his sole experience for the past 8-10 years until that point was writing OS-level C++ code. Exactly zero experience with anything web or front-end related. In a month, he was already decently productive and pushing significant functionality-related PRs on regular. 3 months in at most, he was fully productive and indistinguishable from anyone else on the team, except he also had back-end skills that were better than those of at least half of the team.
And no, we weren't building a simple CRUD app (not that there is anything wrong with that), it was a pretty complex tool that worked and integrated across a bunch of different Office suite products.
Sidenote: Thought to mention that part about "other hobbies not related to coding" to make a point that he didn't just compensate for his lack of existing front-end knowledge by throwing some ungodly number of hours of his own free time at it to ramp up. The problem is that most people cannot afford throwing that many hours of their "free" time considering other life commitments. And no, there is nothing wrong with throwing many hours of free time to bruteforce a skill, that doesn't take away from the person's ability in it imo. But if the engineer I am talking about had done that, then my point wouldn't have generalized well.
Exactly this. A capable engineer can learn whatever's needed. The idea that you should hire only niche specialists sounds good but is completely wrong-headed. The best engineers I've ever worked with were good because they would and could pick up whatever was needed. Specialists OTOH are usually narrow-minded and lacking in motivation—and of little use outside of their one small niche.
Yup, that's pretty much why he got hired. He was clearly an all-around smart guy who knew his fundamentals, had zero issues with learning new things (in fact, seemed to enjoy it, which is always a great mark in my book), and seemed very socially smart (i.e., great to work with as a teammate). As a sidenote, "socially smart" isn't a synonym for "that guy who cannot stop obnoxiously bothering everyone with their constant chatter". "Socially smart" means that he has enough sense of tact and awareness to know when and what to say (or not to say anything at all).
The fact that he wasn't familiar with front-end tech at the time was just a tiny blip that absolutely no one was even slightly concerned about when he joined.
Yep agree. 25+ years of experience here. I went from not knowing JavaScript to delivering a complex 52 page web application using Typescript and React in 4 months. Doing web frontends is way simpler than writing compilers or optimisers in C++ (which is what I also do).
I was a reasonable good web developer and knew very few things about game development and yet I jump straight into it, pick it up fast and work at it for 7 years. After which I made a comeback to web development, picked up the new technologies and started being productive.
And before being a web developer I worked on desktop apps when they were still a thing.
I did a bit of embedded programming and worked on a few mobile apps, too.
Switching from one thing to another is not that hard as you make it sound.
I'd even argue that doing more than one kind of programming during your career is beneficial and not detrimental to both your skills and your career.
It also gets easier the more things you already know. Nowadays learning a new domain is mainly a mapping exercise. Oh this is kind of like X. Neat so that is basically a twist on Y. Especially after you’ve lived through a few hype cycles and start to realize there’s not all that much that’s foundationally new under the sun.
I’ve also worked on web frontend, games and physics, web backend, databases, near metal, very far from metal. I never felt like anything was out of my reach to pick up while working on said thing for the first time at a new company.
Of course you're right about the ramp up speed, but if you can't trust the person to figure it out: you don't want to hire them regardless.
As time goes on, I've become more and more convinced the skill to really look for in hiring is knowing how to learn. I think I've always thought this implicitly, but as I've been forced to articulate why someone someone is doing well or not, it's become more conscious.
Even if you use 100% popular languages/frameworks/infrastructure, what you do will always be new and proprietary in some (unless it's an explicit open source project that the new hire has already worked on, which is a pretty rare situation in the scheme of things). So there will always be new stuff to learn. Does the person know how to diagnose an issue when they get an error that they can't Google? For a lot of folks, even with years of experience, the answer turns out to be no.
I've jumped from game development in C to webdev in PHP to front-end in JS to image compression to native app development in Rust.
I've managed just fine. Switching required reading documentation, specs, papers, blogs, etc. but that's a norm even if you're staying within a single field and don't want to be left behind. It's not even a lengthy process. Reading is this magical process of quickly uploading expertise to your brain.
On top of that a lot of skills are transferable, even between seemingly-far domains. Algorithms, debugging, testing, refactoring, research, project management, and general development wisdom are transferable.
Here's the thing. Those differences are smaller than you might think.
An experienced frontend developer already knows how to program. They know how to write parallel and asynchronous code. They know how to deal with network instability. They know how to write and send of queries to a datastore. They know how to profile and debug code. They know how to work with a complex, mutable data structure safely. They're used to working inside of sandboxed environments and the need to use APIs.
These are all valuable skills for backend developers too. The flavors of the various low level components... matters less than most think.
There are massive differences between front-end and backend engineers.
Backend engineers deal a lot less with network instability, than frontend engineers. Frontend engineers have multiple ways of dealing with failure. And frontend engineers have a different ways of dealing with parallel and async tasks, than backend engineers.
It's not a massive challenge for a smart person to learn, but we shouldn't pretend that people don't try to apply their previous experiences to future tasks. Which is a cost, when hiring someone without specific domain experience.
Nope not true. I routinely switch between working on Typescript/React web applications and hard core C++ servers, compilers and optimisers. Most of the skills you need are the same.
I think going from backend to frontend can be more of an issue. Being a really good frontend engineer requires a strong sense of ux and design that can be completely at odds with how a backend specialist’s mind works. It’s not impossible, but might be really tough.
Going the other direction, there will be new concepts, more focus on algorithms and scalability, more focus on ops and infrastructure, etc. But it’s all still in the realm of programming.
In my ideal world, theres a UX designer to take in (and mentor in) that work. Perhaps design is baked into frontend work in smaller companies, but every place I’ve worked has had a specialist devoted to that work.
Even I, an infrastructure monkey, can follow a design doc with explicit values for widths, lengths, and font colors, faces, and sizes.
I think that in practice a frontend engineer is still going to be making a bunch of ux and design-oriented decisions during implementation, since no design ever translates perfectly. Botching these over and over really slows things down (or hurts overall quality if they never get cleaned up) compared to someone with enough design sense to improvise and fill in the gaps.
This is itself too much of a generalization. Great developers with a lot of experience across tech stacks, even if mostly back-end focused, will have very little problem getting up to speed on a complex (e.g. Angular) front-end. Learning curve? Sure, but these are the people that have proven time and again they have no problem and no fear picking up new tech stacks and applying their general problem solving skills across a huge variety of languages, frameworks, etc.
A more concerted challenge is not whether a senior developer can pick up front-end technologies, but rather whether a strongly backend focused engineers wants to do front-end. I find the latter scenario (which is more about desire and preferences) to be far more important than whether or not they have the ability, experience and aptitude to do so.
As one of those back-end-preferring developers, the thing about front-end development is that the correctness of UI code is subjective, and furthermore subject to the user's opinion. On the back end, I can write heaping piles of unit tests to verify objective correctness of math and data consistency. But on the front end, this button needs to be further to the right, and labeled in a different font.
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
Why not? I know plenty of people who have switched domains for new jobs, and unless you are moving into something highly specialized that requires tons and tons of domain knowledge, it should take you no more than 3 months to become productive with the new tech.
I think context is important. It is good to outline why they need to be up to speed quickly.
If someone has the need for a senior frontend engineer to contribute immediately on a complex frontend app where they are directly replacing a key engineer who left, then what you said makes a lot of sense. Lots of stakeholders are likely to nervous about bringing in a solid developer who isn't already working in the discipline. Often there can be fall out in organizations from this that results in the support systems failing for the hire which compounds problems for them.
When you are thinking about the long-term health of your organization though it is useful to support people in making this transition. Why would they want to stay with your organization long-term if they can't make these kind of changes? They can likely do some frontend projects on the side and go somewhere else combining a salary bump and a discipline change.
Ultimately, you can't guarantee these opportunities for anyone, but it's a case of appearing to be reasonable. That's not the feeling you probably wanted to convey, but it's what came across.
I was gonna quibble with you, but I realized that the article title is “specific technology experience,” not “specific programming language experience,” so I think you have a point.
I mean, forklifts are a technology, but I feel pretty confident that three years as a React developer proooobably doesn’t qualify me to just hop on one of those.
But let's say you'd worked in a warehouse for 10 years before, and now wanted to upgrade to forklift driver, and were previously a truck driver. It wouldn't be unreasonable to expect you might do well in forklift training, and be able to get up to speed faster than a random 18 year old who just graduated from HS.
The forklift analogy is pretty bad; you can get proficient enough to move basic pallets with about around half an hour of effort and instruction if you've driven a car. Using one is more of a matter of thinking through the various moves than being swift and confident with the controls.
Or so says my wife, who is not a truck driver but can drive a forklift.
Right, which is the main thrust of the linked article. I think it's useful, though, to try and pick apart the boundaries where that argument breaks down; how different of a forklift do you need for your experience to stop applying, etc.
Ok I'll bite, what exactly is there to 'know' about browsers and underlying tech? Apart from the overly complex build eco systems the js frontend devs have forced upon themselves, I see no reason why a senior backend engineer can't pick that up in a week or two.
They'd probably make the frontend app faster, less complicated and use less memory.
Things a frontend dev would know that a backend may not:
- HTML and CSS (facility with selectors)
- JS syntax and semantics, common patterns and idioms, gotchas
- Web APIs
- CORS
- Frontend data persistence mechanisms (cookies, local storage, etc.)
- Critical rendering path
- Service workers (how and when to use)
- Accessibility (ARIA)
Most senior backend engineers were generating this in the server response long before frontend frameworks were a thing.
> JS syntax and semantics, common patterns and idioms, gotchas
JS syntax is based on the most common C style syntax there is. You can reach a good enough level just by knowing that. The rest of the idioms/gotchas, well those are not really necessary and are mostly flaws which JS itself is trying to fix it with the new iterations.
> Web APIs
These are well documented, are you saying a senior backend engineer will have trouble reading the docs were a frontend dev won't?
> CORS
Come on, let's be serious here.
> Frontend data persistence mechanisms (cookies, local storage, etc.)
... so a backend engineer will not know how to use state persistent mechanisms? Think about that for a second.
> Critical rendering path
A backend engineer has responses to return in the milliseconds, not hundreds afforded by frontend, they know much more about getting data ready as fast as possible.
> Service workers (how and when to use)
A mini backend in the browser, and you're saying a backend engineer won't understand that?
> Accessibility (ARIA)
Are you talking about learning the available tags, which would take less than a day, or designing for accessibility (eg. color/full blindness).
Ignoring your extreme snark and least charitable interpretation of what I've written, I'm not saying any of these things are insurmountable or even necessarily hard to learn, but they are _things to know_. I don't think you should completely dismiss all of the frontend "domain" knowledge with a wave of your hand.
As a full-stack developer who started off more frontend and leans more backend these days, JS is one of the languages I know best, for better or for worse, and knowing it has paid off for every job I've had so far. Understanding about the prototype chain has been useful for monkey-patching abandoned 3rd party library plugins that I've had to use in a pinch because there was no alternative aside from writing and maintaining my own. Knowing about variable hoisting has gotten me out of a jam when working with legacy code. Also, saying "the flaws of JS don't matter since they're going away" isn't really true since there's still a lot of old, crappy JS out there in the wild that you may be forced to interact with and browsers still have to support; things like there existing null _and_ undefined in JS aren't going away, so you need to know about them and have a plan for dealing with them. As it turns out, knowing one of the most used languages and all of its baggage is useful.
Please realise that what is complex and hard for you might not be complex or hard for a senior engineer with 20+ years of experience in different languages and frameworks. I write compilers for a living and have written 3D game engines from scratch for commercial games. I learned JavaScript and delivering a complex 52 page web application written in Typescript and using React in 4 months. It was fun and easy compared to what I normally have to deal with. So please realise that your experience is very different from somebody with a lot of experience. I am not being snarky or arrogant. Just pointing out that different experiences shape how well you adapt to new tech.
Right, and they can be picked up in a week or two by anyone who has any sort of senior level experience. Literally everything you described is not limited to JS and almost every dynamic language contains their own version of them.
Not to mention you backpedalled away from the original question about browsers and underlying tech and focused on a couple nuances in JS.
All of that is easy to learn. You just learn the bits you need to solve the specific problem you have. I went from not knowing JavaScript to completing a complex 52 page web app in 4 months. I simply just-in-time learned what I needed to learn. It wasn’t hard. It was fun actually.
Not much. I went from not knowing JavaScript to delivering a 52 page complex web application in 4 months. You just learn what you have to learn to solve the problem you have. That’s the key skill you need. If you can figure out how to quickly learn what you need to solve a problem then nothing is hard.
Yes, when I was younger and had just 20 years of experience with programming it was before 1990! Back then I knew a small amount about virtually everything in CS and virtually everything in a small portion of CS.
However things in CS changed rapidly and I made the decision to work on operating systems and basically let go of writing user interfaces. The landscape for user interface development was a mess MS Windows, NextStep, X, MacOS, and Sun Window System were all different. The web and especially browser support for JavaScript really accelerated the rate of change and I found it impossible to catch up with GUI development.
For years, I did consulting work for firms helping them with system architecture, but in the last few years I found myself unable to help with the inevitable requests for assessment of companies user interface designs. It's a bit sad for me to know so little about such an important part for so many applications.
Oh well, I've been very happy in my career, but I still remember the "good old days" where it was possible to take on virtually any task without needing a lot of time to ramp up my understanding of the tools, frameworks, and programming languages.
Nothing is absolute, of course if you take it far enough the seams of the argument tear but there is merit to it.
A senior browser frontend developer is likely to pick up mobile development quite quickly.
Likewise someone who's been doing Spring Boot Java backends for years and is proficient with databases, caching, etc. Isn't necessarily going to find it hard to switch to a serverless nodejs paradigm.
The network card person is probably able to handle the embedded microwave oven.
I believe it's not about learning how to do things. That's not that hard. It's about knowing about the gotchas - things not to do. Every technology stack has its warts and oddities.
It's not that hard to write some code that would do the job, it's hard and cost prohibitive to realize all the initially hidden nuances that might require redesign because of shortsightedness of the original one.
Requires either a really bright fast-thinking mind or just a lot of experience making one's fair share of mistakes. There are geniuses out there who can make perfect models in their heads, but I believe a lot of people just scrape by knowing where them or others had shot themselves in the foot before. And such experience only comes with time.
Yeah, I'd parse the article as saying, for example, job postings for React roles shouldn't specifically require years of experience with React. This is because Vue knowledge is highly transferable.
There's an insulting premise in such job postings that engineers are incapable of learning anything new.
When I hire a painter, I don't ask how many years experience they have with pink paint (as opposed to say white or magnolia).
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
Of course we can nit pick and poke holes all we want. But the basic premise, to use your example, is that an experienced backend engineer can work in a backend written in C/C++, Java, Go, Rust, Python, Ruby and so on. An experienced frontend can work in Angular, React, Vue, Svelte, JS/TS/Elm/ClojureJS/.....
Not true. I went from not knowing JavaScript to delivering a 52 page web application using Typescript and React in 4 months. Meanwhile an “experienced” front-end developer spent 3 months trying to decide which framework to use. It depends on the person not whether he/she is back/front/experienced.
What you really want is the Jeet Kune Do guy, who has tried a bunch of things and is good at learning whatever he sets his mind to. You've all met him, that guy who's never written a mobile app and then when it crosses his mind, a few weeks later he's written a Swift app that talks to APNS and all that. A colleague of mine went from his PhD in Biology to writing low latency c++ HFT code.
The problem is we all like to kid ourselves that we're that guy, and we'd like to kid other people (hiring managers) as well.
So to guard against this, the natural thing to do is to restrict the entry criteria.
I'm not saying you won't turn away any genuinely great people who can learn your system super fast, just that in this case the baby/bathwater ratio seem pretty reasonable, and so that's why people do it.
I would think that in a tight job market like we have now, the criteria are a bit looser, so it's not all bad.
Working in embedded Linux, I don't require experience in my exact technology stack for a senior engineer. But I certainly do expect some experience in the same problem domain.
Like let's say I build systems with Yocto Linux. Somebody who uses a competing system like Buildroot is fine. Somebody who's never done embedded Linux but knows how to construct Debian packages might be fine too. I'd also consider an old school Unix wizard.
But somebody who can't use SSH and only writes Javascript isn't going to be a good fit, no matter how good they are at Javascript. An iOS app developer also wouldn't be a good fit. Either could be OK for a junior role maybe, but not a senior/staff role.
> Working in embedded Linux, I don't require experience in my exact technology stack for a senior engineer.
> An iOS app developer also wouldn't be a good fit. Either could be OK for a junior role maybe, but not a senior/staff role.
Tangentially related at best, but this is essentially my current dilemma...
Sr Android engineer, leading a team of 8 on a multi-million install app for a well known multi-national (not software) company. No one will give me the time of day for anything but Android work, and I'm really feeling the burnout.
How far would you take this? Would you hire a senior Android developer to lead your app development who has never written an Android app before? If you do, you’re going to have a very bad time. With experience comes lessons learned and best practices. Hiring someone who can apply best practices across a team lifts everyone else on the team up and has a multiplier effect on productivity.
How much time would it take for a smart, competent and self motivated person to get up to speed on this new but related field? Given that number of hours, is it worth accepting that period of relative 'unproductivity' in order to hire them?
That seems like the right heuristic to answer your question.
> How much time would it take for a smart, competent and self motivated person to get up to speed on this new but related field?
This depends on the position; smarts are not a replacement for (domain) experience, because certain knowledge can be learned only through trial and error and/or through long-term exposure to a domain (in other words, experience).
I believe that domain experience is the more necessary the higher level the position is (e.g. seniors who can decide on architecture, leads, architects...).
Having said that, I certainly agree that in the (hiring) industry it's common to be excessively attached to the specific tools used; I also suspect that smaller companies tend to think like this more than bigger ones.
I think it probably depends on what the domain is. If the position is highly technical in nature then I would agree. However, I do think that beyond a certain point the ability to become highly competent on the fly in a new domain is extremely valuable. If the person will be giving input on business strategy, tech pipeline, then the ability to move laterally and adopt new ways of doing things should be highly valued.
The programming language and any platform SDKs (like Android) are the least interesting aspect of this. The history behind any existing applications, libraries, and customized frameworks is far more important to consider. Someone who is engaged in learning Android development systems from scratch is going to be less effective at understanding why decisions were made the way they were, and therefore will definitely be less efficient at leading an effort than someone who already knows the platform well.
> How much time would it take for a smart, competent and self motivated person to get up to speed on this new but related field?
Hiring someone willing to learn a new field filters for generalists and people who need jobs. Neither of those qualities are bad.
Specialists, or people in love with a stack, don't want to use 'some other tech'. As a senior, I pick the stack, because I have an idea where the industry's at and what's best for the type of software I'm experienced with making.
> How much time would it take for a smart, competent and self motivated person to get up to speed on this new but related field?
I think the more appropriate question is about the relative effectiveness of someone who has been leading Android development teams for 10 years and someone with the same experience but in a different (but related) field.
> If you do, you’re going to have a very bad time.
GUI libraries are pretty similar to each other. I have never written an Android app before, but in a hypothetical case when I would want to make one, I’m pretty confident it would take me a week or two to learn these things. I’m very familiar with quite a few other platforms: everything Windows from WinAPI to UWP including phones, iOS, I made my own GUI frameworks even…
If that lead developer does not have _any_ experience writing rich GUI apps in any language, and no experience with computer graphics either, now that would be a red flag for me. That’s too much new stuff to learn in reasonable time: computer graphics in general with these pixels and vectors, Unicode shenanigans, UX shenanigans especially touch screen related, and quite a few others.
>> in a hypothetical case when I would want to make one, I’m pretty confident it would take me a week or two to learn these things.
The thought might be, how long would it take you to make a great one? An 'expert' might be able to create it by the time someone else has started figuring out lower to mid-level concepts.
The principal doesn't have to make a "great" android app: the principal has to correctly train and marshall their engineers to create a "great" android app. I think you might be stuck in the narrative of the "solo contributor genius". In reality, the vast majority of great products require teams.
The low-level concepts are exactly the same across all modern platforms. Specifically, GUI on all platforms is made of bitmaps (in modern world often encoded into jpeg/png/astc/etc.), vector graphics (polygons, quadratic and cubic Bezier), and font glyphs (same Bezier as in vector graphics + typesetting). These 3 things were invented many decades ago, and stayed pretty much the same over these decades.
Mid.level concepts are more diverse, but not dramatically so. All popular GUI libraries are object oriented, web included. MVC on iOS does have some differences compared to MVVM on Windows, but conceptually they’re still very similar.
It’s funny, your comment highlights exactly why experience is important. You don’t know what you don’t know about Android development. You have a set of very basic assumptions about how the API works, and have no idea what the challenges of Android development are. Sure, you could figure out how to build a basic app quickly, but you probably wouldn’t do a good job building the foundation of a large app being worked on by dozens or hundreds of engineers.
> You don’t know what you don’t know about Android development
What’s that? If you gonna mention Java shenanigans like memory management and garbage collector, .NET is fairly close. Mobile-specific things like multi-touch UX and power management are shared by all battery-powered devices. Many kernel-specific things are shared with all Linuxes including desktop, server, and embedded.
> you probably wouldn’t do a good job building the foundation of a large app
I probably will. I already did a few times in my career. When I found that iOS development job a decade ago, I had zero prior experience with the platform. I had many years of prior experience developing stuff for Windows, game consoles, and some older mobile platforms.
> Would you hire a senior Android developer to lead your app development who has never written an Android app before?
I assure you a million companies did exactly this ca. 2010. And that was back when it was much more difficult to write one, both devices and the SDK had orders of magnitude more sharp edges and restrictions than they do now.
... in a very different competitive environment, and with probably a larger number of failures to get to market (although it would be interesting to put numbers to that, if they can be found).
If anything the additional stacks means both app quality and the platform-specific knowledge a senior dev needs has declined, since today you're probably working on a pile of React Native bullshit or something that has very little to do with Android anyway.
True in the case of React Native bullshit, false in the case of a native app that isn't just CRUD. A senior without android experience could jump on the apps that are glorified websites and be productive relatively quickly.
A senior without android experience is going to have to learn the platform; this will take longer than learning the language. The pace of change updates the best practices often enough to serve as a kind of catch-up mechanic but native mobile does in fact require domain knowledge. I would be comfortable putting a senior iOS dev on native android but certainly not as the lead.
It depends on how specific we're talking. If I need to hire a senior-plus to work on a web application, I probably won't care if they don't have any experience with the exact frameworks I'm using. But if they have no experience with HTML/CSS/JavaScript at all, then I'm probably skipping over them.
Yeah, I don't agree with several of these "assumptions" and it def sounds like an engineer protesting that somehow their multiple experience is obviously a qualification for any job they think they can do.
> Much of the job involves tasks unrelated to writing $TECHNOLOGY. True but doesn't negate the point that you want previous experience. Also think the OP is exagerating the other work that most of us do
> Engineers who already have experience can often pick up new ones quickly. Common statement but again, fairly obviously wrong. Are you telling me that just because you know "stuff" that if I wanted someone to do e.g. Elasticsearch, that they could create production-quality work in a short time? How long does it take in real experience to get good at these things? DOes generic experience help? Almost certainly, that much? Not compared to someone who has already produced decent quality e.g. Elasticsearch
> Experience with different paradigms can make them better at writing all kanguages. Completely disagree. Writing Java, C#, F# etc. is VERY different, much more than the superficial similarities. Again, I could learn Java more easily with C# but still not be as good as someone who has written Java already.
> An engineer with other experiences might help you consider future alternatives. And conversely, they might steer you towards what they are comfortable with even if it isn't a good fit.
> You might not be using it in the medium/long term. No. But I'm using it now and my devs might not even be working for me in a years time so why choose someone who might be useful in the future over someone who can do stuff now?
> May not be something that many people have experience of. Maybe not but that is a different issue.
If I cannot find people with the experience then maybe I will have to employ somebody that doesn't have such a matching skillset and maybe it will work. Otherwise, I will definitely start with people who have cut their teeth on what I am using and don't have to learn all of those, "yeah, that doesn't work in C#" things.
Folks complain about LeetCode.
Folks complain about requiring experience with specific technology.
Folks complain about take home project assignment.
Folks complain about too many interview rounds.
The general sentiment seems to be, "Oh, I have XX years of experience and the world owes me my next job with a 25% increment, 4 weeks of PTO and fat RSUs".
I don't agree that senior developers can come up to speed on any technology "pretty quick".
I don't agreee that you should not ask for specific senior experience with specific technologies.
It takes years of working intensively with a programming language to really understand it well.
If you are wanting to hire in expertise - i.e. someone who really knows how to get things done with your technology stack - then you MUST select for specific previous experience.
If however you're not looking for someone with expert level skills then sure, hire openly for "smart people who get things done", but in that case, you need to be ready for the people you get to take a good chunk of time to really come up to speed - like six months at least.
That might be your personal experience but please recognise that some developers can do all of the above with ease. You might not be able to but they can.
Context: I’m a senior manager for a unicorn startup. I spent the first half of my career as an software engineer, and co-wrote a technical book about some of that work. I’ve been paid professionally to write C, Python, PHP, JavaScript, and Java, but FWIW I’ve never held the title “Staff Engineer”.
Basically, I never imagined an article titled “yes, experience in a particular stack is probably material to your success at another company” would make for an interesting or even controversial take.
(To be clear, I would and have hired many people with different $technology backgrounds. It’s not a blocker. But I wouldn’t dismiss it either.)
In the Bay Area it’s pretty standard, I’d say. Be surprised if there were any at a Bay Area tech company without any engineering in their past.
Unless you mean something specific by “trained”. Like most Software Engineers, I’m not a PE nor did I undergo any specialized training. Pretty much just have Maths and CS degrees and lots of work experience.
Have you never met a business-school alumnus/alumna that had zero knowledge about the craft of software engineering and software development, still getting a management position?
That is sad, especially wrt the effects on the team mood.
---
To be fair, same goes with a software engineer turned manager without any guidance, landed there by sheer inertia.
I’m aware of the concept but haven’t encountered it in any Bay Area company - my work experience is across a bunch of startups here and I have contacts at FAANGs and midsize.
This rings true especially for people in senior positions. The higher you go, the less the technology matters, and soft skills become more valuable. Is mentoring a junior dev more about the specific language, or the ability to communicate and guide someone?
I sort of agree, but not fully. I think if deep technology details don't really matter, then the person should be more of a technical project manager or an architect, not a senior developer.
If you're hiring for a senior role and having trouble finding someone, then it can help to broaden your search.
But if you're hiring for a role and have plenty of good applicants, you actually want to reduce the choice down. If you had to pick between 2 good applicants and 1 had experience in the technology and 1 didn't, with all else equal, you'd pick the one with experience.
And if you've got a dozen applicants like that with various differences, but some have experience and some don't, you're going to favor the ones with experience.
Of course, nothing is ever quite so clear as that. But when you're already trying to filter the applicants down to a set you want to interview, broadening the search isn't a good choice.
I think this is what I meant. A senior level contractor you need to have the specific skills for specific tech, a senior level employee you plan to train so you don’t need to filter on specific tech familiarity.
Yeah, the main reason for hiring a contractor is because the contractor has very specific experience with all of the quirks and flaws of XYZ thing that I need to implement, and can do in a few days what would take me a few weeks of learning the hard way.
The article contains some decent advice if you're hiring folks with 10-15 yoe. But if you're hiring someone with 5 yoe as a "Senior", then you'd better only hire them to work on what they have experience with. And the latter is more common than the former IME.
In other words, there's been significant title creep in the last decade and "Senior" no longer means what the author of this post seems to assume (experience with multiple frameworks, languages, orgs, etc).
I think there is a difference between hiring someone with C# experience for a Java role, or someone with C++ experience for a Rust role, and hiring someone for a diametrically opposed software stack. There is nuance.
Though I would say someone with at least intermediate abilities in half a dozen languages has a great track record for learning new things. Carpenters are not sifted for how much experience they have in soft woods, hard woods, or plywood.
Still. I can see hiring someone with 5 yoe C# to serve as the Senior on a Java project. However, I wonder about hiring someone with 5 yoe C# to serve as the Senior on a Java project. There would have to be some sort of additional major value add (e.g., domain expertise).
At 15 yoe C# experience this starts to make a lot more sense.
I also think it's worth highlighting that "years" is a terrible measure of experience with a technology.
Suppose I'm a backend engineer on a team where the production services are all in java, we do some low-scale data analysis in python, and in one corner of the repo there are automation scripts in ruby. If resources aren't available, infrequently do a tiny bit of frontend work in js to unblock my projects. I constantly am reading/writing/maintaining java. I frequently am writing python, in a jupyter notebook, but not building anything large. A couple times a quarter, I need to make a small change in a ruby script. Rarely I write javascript and every time I need to relearn whatever react/redux/whatever else the frontend team has moved to.
I work here for k years. But it's silly to say that in doing so I got k years of experience in java, python, ruby, and javascript, plus a year in each of the frameworks that the frontend team drifted through.
If I tell an engineering manager "years are not a good unit of measure; I have >5 years of overall experience with ruby, but am not a rubyist" they'll probably understand. In general, if I say the same to a recruiter working through a checklist, I'm perceived as being unhelpful.
I'm very experienced in many languages, however I wouldn't hire myself to lead a C++ job, as I heard there is a big bag of hidden knowledge of how not to shoot yourself in the foot.
With an experienced mentor that would patiently review all my PRs for a while? Sure. To architect and lead the C++ project? No.
A months-long hiring process can't compete with simply working alongside somebody for a day. It's a shame we haven't been able to scale up a solution that would allow for this and be fair to all involved.
What I find most amazing about those discussions is the passionate vitriol from future job-seekers for arrangements like that. Maybe it’s because they’re imagining it having all of today’s downsides plus taking longer, but it seems like it could so obviously be better yet it’s so loudly shouted down.
For every company that introduces a positive change into their hiring process that is 'obviously better' for both employers and employees, there are 9 (or more?) companies that will thoughtlessly add it to their already endless interview process.
It's also super inconvenient to need to take an entire day for a job interview when I'm probably talking to several other companies and still have a full-time job. It can be worth it for the right offer, but it usually isn't.
Yeah, I definitely don't see this as something that can be reasonably implemented into any standard hiring process. The closest approximation might be to work with someone on a contractor basis and then offer them a full time position, but this filters out a lot of people who only want full-time work.
Beyond a simple FizzBuzz filter to screen out the truly bad applicants, it seems extraordinarily difficult to sort the rest. A probationary period (the norm in many countries) theoretically can do this, but in practice I think it again only helps screen out the egregiously poor employees.
My first week at any job is mostly trying to get my bearings, and spending most of my time reading / listening. It's hard to skip ahead a few weeks and get that day instead of the first day, though.
Sort of agree, but not entirely. I think it's reasonable to require some limited years of experience in the core tech. I think it's too common to see an unreasonable number of years required, or an unreasonable number of technologies known.
Often the number of years required is discriminatory. Asking for 1 or 2 years experience is probably fine, but quite a few posts ask for five years. Without a particularly good reason, I suspect this is nominally unlawful in many jurisdictions.
Remember, what employers actually want is competency (and replaceability), not years of possible mediocrity.
I think how much it matters really depends on the domain and situation. If you're hiring someone to optimize and extend the low-level graphics pipeline for your industrial-grade CAD application,it makes sense to look for someone with deep experience in the graphics API you're using. If you're a seed stage startup hiring a founding full stack engineer to build out your web dashboard product, asking for specific tech experience is stupid - you need velocity, ownership/initiative, judgment under tight time constraints, etc experience, not X years in Z framework. Lots of room in between, I guess
I think these companies know how to hire for their tech stack. I once had a job that was all Lotus script (VB basically) and Java with Domino. They just mention that's a plus but not required. They already know that no one has experience with that tech stack.
The other problem with this is let's say you need someone with GQL experience. And everyone in the company knows it. It's not that hard to pick up, but when you get a senior that DOESNT know it... they tend to just grumble about it and want REST instead. It's sometimes better to hire what you know you need.
A good Sr Engineer knows that you don't change things just because you don't like how it's being done. Every change comes with risk and one's personal preference is not enough reason to justify the added risk.
I wasn't thinking the risk was that the tech stack would change. The risk is that this new hire will generally try to avoid GQL (for example) as much as possible.
I strongly disagree with the premise here. Anyone who hires based on this mentality will be compromising significantly on their team's performance.
Within a specific part of the stack, there is a vast quantity of micro-skills that a developer needs to know. The language syntax, the language built-ins, the language ecosystem, best practices, canonical designs, the debugging tools, other development tools, etc.
Many things are Google-able, but searching for answers to problems is like making a network call. It's WAY faster if you can pull from cache.
My specific context is frontend development. I would never hire a frontend developer who cannot clearly demonstrate their skills in the domain. There are ~140 HTML tags, each with different attributes and behaviors. There are ~200 CSS attributes with 2-10 meaningfully different values each. JavaScript as a language is moderately challenging for some developers and there are many hundreds of built-in methods, behaviors and functions to know.
I've seen time and time again the differences between a talented frontend engineer and a senior non-frontend engineer trying to solve the same problems. Given a description of a problem, an experienced FE dev can quickly identify the problem using dev tools and make the necessary changes to solve the problem. It might take them 20 minutes. The "senior" non-FE engineer might spend a full day searching, debugging, experimenting and learning. By the end of the day they might be proficient at Flexbox layouts and able to solve the same problem in 2 hours next time.
But depending on your business, can you afford to hire an engineer who takes 10x longer to do things, with the hope that after 6-12 months they might only be taking 2x longer to do things?
And don't get me started on architecture and design sense. How can you expect a senior to make wise decisions in a domain they know little about? Nearly every time I've seen mostly-BE engineers build FE projects, they create bloated, complex and over-engineered designs that are hard to develop and maintain. There's a thousand little details that you learn over the years when working in a specific domain.
For me, I hire based on demonstrated expertise in specific domains. When I do that, my teams move fast and effectively. It can be hard to hire the specific skills you need, but I've found it to be far more important than anything else.
Not all $technologies are equally easy to come up to speed on. Similar domain, different language? Mostly easy. Completely different domain, same language? Probably hard. Both? Really hard.
You wouldn't hire a senior javascript programmer to write CUDA c code, and vice versa. You'd happily hire someone who hadn't ever written web apps in c# but was a senior java person building web apps...
It would be great if this attitude were more prevalent, though I see some comments taking it to a bit of an absurd extreme—"you would't hire a React developer as a GPU programmer!!"—and this is both valid, and somewhat missing the point.
I don't think the argument is that we should pay no absolutely attention to domain expertise for software engineers. Skill in a particular domain of software development (or business) is valuable; an experienced front-end web developer is going to have a large library of knowledge that is just not accessible to someone coming from e.g. an embedded background. If we need a senior front-end engineer, I'm unlikely to be hiring people who have no experience with that area of development.
But I have seen some frankly silly objections to candidates in the past. If we're primarily using React and I've got a great candidate with 10 years of Angular experience, I'm not going to reject them outright. I am way more interested if you demonstrate a clear understanding of the problem domain generally, if you are able to talk about your work and the challenges in it, and are able to communicate effectively about your own skill and experience. My experience suggests that if you can do the above, you're not going to struggle to start writing e.g. Ruby as a developer with a Python background. Or even worse is the inclusion of specific technology – people including things like "Redis" as a requirement in a job posting is baffling.
Related: from a personal perspective, learning new languages and frameworks is by far the single most powerful tool I have ever encountered for increasing my own technical skill. Seriously, it's an absolutely insane effectiveness multiplier to be able to bring together knowledge and standard idioms from different systems and development paradigms.
I applied once to Digium. I was rejected, because they were "looking for someone who could hit the ground running" (in those exact words). Months later, I saw that the same job posting was still up, and still active.
It may not have occurred to them to lower the speed of their onboarding treadmill and revisit rejected resumes, because I never heard from them again.
The trouble is how do we determine who is a senior+ engineer if we don’t look for specific tech skills?
I interviewed a guy once who was applying for an architect position who didn’t know what DI was.
Not knowing what DI was meant there was a strong indication he didn’t know much Java either.
At what point do we say maybe he’s just not qualified for the job? Maybe he’s not yet architect material, nor a senior engineer, no matter what he claims.
Most importantly, why on earth would I pass up engineers who do know what DI is for this guy?
> the main blocker in getting up to speed quickly will be learning $TECHNOLOGY rather than learning your version control system, deployment system, company engineering culture, etc.
I guess the product's requirements and architecture aren't important as things like company engineering culture. While I agree with the rant, it doesn't mention the product anywhere. I must have had it the wrong way around this whole time.
Personally I have never been held back by that "years of experience" thing.
For instance I had "years of experience" with Java and had a recruiter realize those "years of experience" would translate to C#.
Presumably people will be getting hired to do "metaverse" related work. Only a handful of people have any experience now, recruiters will have to settle for people who know what is fundamental and universal.
After learning some very basics for html, perl, and JS I took a "need to know approach" to building apps. My skills are pretty well confined to that but fairly strong now.
But I've played around with quite a few other techs since the Raspberry Pi came out and some of them have pretty easy to jump into. Others quite daunting.
I barely poked around with C, C++ and left the building. I felt like a lefty in an all right handed tool shop.
I could not agree more with this. Among other things, I am interested in how a person thinks, how they solve problems, how they communicate and how they face new challenges. For the most part, I could not care less what languages they know today.
My perspective on this is likely very personal. Nearly 100% of the technologies that we use today did not exist when I was in school and started working as an engineer. I am fond of saying that they only things that survive the test of time are C, math and physics.
I do like people with low level experience. By this I do mean assembler. That tells me they did not come-up in an idealized world that is completely isolated from the underlying hardware. I like to remind people that Bjarne Stroustrup was very much into assembler and microcode before creating C++.
My standard test is to learn what language a person does not know and have them solve a problem using it. These days that typically means something like Forth, LISP or, my favorite, APL. Having used APL professionally for ten years, this is one of my preferred go-to interview languages.
I could not give a shit if someone memorized a hundred interview problems (Fibonacci and palindromes make me want to vomit).
I also find that this instantly relaxes the interview process. I'll say something like "I know you don't know the first thing about APL. No problem. I want to understand how you might approach having to write something in a language or framework that is completely new to you. I know the language well. You can ask me anything you want, google it, or, here's a couple of books for you to refer to." We then sit down, hack and talk.
Computational problem solving is a creative as well as technical job. If you want to hire robots who can memorize and spew out hundreds of trained little problems, by all means, go for it. It might be the case that large companies like Google and FB have no choice but to filter this way, I would not know. I'd rather work with people who can say "I have no clue, but I'll figure this out".
This is also common on the IT/Ops side of the house. E.g. Trying to explain that VLANs, LLDP and 802.1x are not Cisco specific. Often there are just flat misunderstandings of how to identify 'technical' experience. E.G. someone lists the ability to read SIP/RTP protocol decodes and they reject this person because they don't have VoIP experience.
Let's go back in time to something like 1994. You want to make a 3D shooter for DOS. Do you hire someone who's done a couple 2D Mac games? What about someone who's written some 16-bit console games? Or do you hire someone who's been in the PC games industry for the latest couple years and just released a 2.5D shooter?
I think a better question would be to ask which developer is more elastic. There are definitely developers who tunnel extremely deep into one area and cannot or will not branch out where others will jump in and learn new tools and techniques.
In the 1980s, when I was starting out, we tended to hire talent not skill sets. Today hiring managers tend to focus on specific skills, often learned haphazardly or only well enough to pass a certification exam. Memory and jargon trumps technology understanding. Project costs and overall quality have both been negatively impacted.
Specific technologies, no. But I see the difference between my engineering experience and that of the guys who are experts at things like web dev and I have to learn to be effective and their experience has already taught them everything.
Learning a technology requires understanding principles behind it. So the point is how deep the senior engineer understands principles, not technology. Treat technology as example/implementation of that principles though.
Titles vary so wildy between companies and even within companies. Titles could be meritorious or it could be based on time-spent at the company, you never know.
Titles are by and large vehicles for promotions, not an indication of skill.
I think it's great to list particular items in the "Great to have" section of a job posting, but "must have exact technology X" is stupid, and you're doing yourself a disservice otherwise.
The sad truth is, the more senior you are, the harder it gets to learn new tech. Especially things that just need to be memorized, like command line switches, library functions etc. Source: retired coder.
Yeah for now. In a year or two it'll be Shmeact and than something like Boomerangular and of course the framework to rule them all VanillaChocolateChip (or VCC.tjs)
A technical recruiter, having discovered that that the ways of Unix hackers were strange to him, sought an audience with Master Foo to learn more about the Way. Master Foo met the recruiter in the HR offices of a large firm.
The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
“I am learning to walk,” replied Master Foo.
“I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
“Yes, but this floor is new to me.” replied Master Foo.
Upon hearing this, the recruiter was enlightened.
Source: http://www.catb.org/~esr/writings/unix-koans/recruiter.html