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?
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.
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. :)
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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?
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.
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 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.
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.
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
[+] [-] thesuperbigfrog|4 years ago|reply
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
[+] [-] gfxgirl|4 years ago|reply
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?
[+] [-] Jugurtha|4 years ago|reply
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.
[+] [-] jedberg|4 years ago|reply
[+] [-] P00RL3N0|4 years ago|reply
[+] [-] golergka|4 years ago|reply
[+] [-] spullara|4 years ago|reply
[+] [-] ourmandave|4 years ago|reply
[+] [-] savant_penguin|4 years ago|reply
Better know those floors goddam well
[+] [-] 0xB31B1B|4 years ago|reply
[+] [-] mixmastamyk|4 years ago|reply
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.
[+] [-] redhale|4 years ago|reply
[+] [-] plorkyeran|4 years ago|reply
[+] [-] malux85|4 years ago|reply
[+] [-] bb88|4 years ago|reply
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.
[+] [-] gopher_space|4 years ago|reply
[+] [-] obedm|4 years ago|reply
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.
[+] [-] ghotli|4 years ago|reply
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.
[+] [-] filoleg|4 years ago|reply
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.
[+] [-] DeathArrow|4 years ago|reply
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.
[+] [-] xxpor|4 years ago|reply
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.
[+] [-] pornel|4 years ago|reply
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.
[+] [-] falcolas|4 years ago|reply
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.
[+] [-] speby|4 years ago|reply
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.
[+] [-] RussianCow|4 years ago|reply
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.
[+] [-] zerkten|4 years ago|reply
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.
[+] [-] ketzo|4 years ago|reply
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.
Every message in moderation, I guess.
[+] [-] zepolen|4 years ago|reply
They'd probably make the frontend app faster, less complicated and use less memory.
[+] [-] todd8|4 years ago|reply
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.
[+] [-] nsotelo|4 years ago|reply
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.
Etc.
[+] [-] atwebb|4 years ago|reply
Technology is a bit overloaded though so we may be picking up different meanings entirely.
[+] [-] yumraj|4 years ago|reply
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/.....
And, so on...
[+] [-] mbrodersen|4 years ago|reply
[+] [-] lordnacho|4 years ago|reply
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.
[+] [-] nrclark|4 years ago|reply
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.
[+] [-] rp1|4 years ago|reply
[+] [-] jaywalk|4 years ago|reply
[+] [-] lbriner|4 years ago|reply
> 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.
[+] [-] firstfewshells|4 years ago|reply
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".
[+] [-] andrewstuart|4 years ago|reply
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.
[+] [-] Aeolun|4 years ago|reply
Why aren’t managers or directors writing about their views on this?
[+] [-] btbuildem|4 years ago|reply
[+] [-] wccrawford|4 years ago|reply
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.
[+] [-] mostertoaster|4 years ago|reply
[+] [-] throwawaygh|4 years ago|reply
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).
[+] [-] abeppu|4 years ago|reply
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.
[+] [-] deepsun|4 years ago|reply
With an experienced mentor that would patiently review all my PRs for a while? Sure. To architect and lead the C++ project? No.
[+] [-] WarOnPrivacy|4 years ago|reply
I figure it'll take up an entire line.
[+] [-] giantg2|4 years ago|reply
[+] [-] wly_cdgr|4 years ago|reply