20 ms·

Stop requiring specific technology experience for senior-plus engineers

362 points by Amorymeltzer 5y ago

Aeolun 5y ago
I can’t help but notice it’s always engineers writing these articles. Why aren’t managers or directors writing about their views on this?
- tomrod 5y ago
  Liability.
- renewiltord 5y ago
  We are. We’re just also engineers.
  - xcambar 5y ago
    If every (engineering) manager or director you know around you is also a trained engineer... you're the exception, not the norm.
    - renewiltord 5y ago
      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.
      - xcambar 5y ago
        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.
        renewiltord 5y ago
        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.
- bentlegen 5y ago
  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.)
btbuildem 5y ago
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?
- giantg2 5y ago
  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.
PaulHoule 5y ago
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.
- zepolen 5y ago
  Of course you can also get those who have years of doing the same year of experience.
bluedino 5y ago
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?
- mmcdermott 5y ago
  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.
WarOnPrivacy 5y ago
I'm waiting for an article with all the non-counterproductive hiring practices that applicants usually encounter. I figure it'll take up an entire line.
- TrevorJ 5y ago
  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.
  - sokoloff 5y ago
    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.
    - Hasu 5y ago
      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.
      - TrevorJ 5y ago
        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.
  - yuliyp 5y ago
giantg2 5y ago
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.
- orra 5y ago
  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.
thesuperbigfrog 5y ago
Master Foo and the Recruiter 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 http://www.catb.org/~esr/writings/unix-koans/recruiter.html
- Jugurtha 5y ago
  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.
  - mLuby 5y ago
    One learns to walk differently in San Francisco, to avoid stepping in **it.** And of course if you walk without rhythm, it won't attract the worm.
    - Talanes 5y ago
      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.
rp1 5y ago
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.
- TrevorJ 5y ago
  >How far would you take this? 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.
  - tshaddox 5y ago
    > 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.
  - EarthLaunch 5y ago
    > 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. These hidden filters are interesting.
    - rp1 5y ago
      Yes, let’s build the Android app on iOS :)
jaywalk 5y ago
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.
ActionHank 5y ago
Seems like on the frontend side everyone requires React. Weird thing is that there are many devs who "know React", but have no clue how to play outside of that sandbox.
- c0decracker 5y ago
  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)
lbriner 5y ago
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.
throwawaygh 5y ago
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).
- datameta 5y ago
  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.
  - throwawaygh 5y ago
    Yeah, totally fair. Nuance is king. 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.
carlsborg 5y ago
Exceptions exist. If you need a key cloud infrastructure hire, a super smart person who hasn't worked in cloud wont cut it.
rhacker 5y ago
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.
- victor9000 5y ago
  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.
  - rhacker 5y ago
    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.
obedm 5y ago
I strongly disagree. 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.
- atwebb 5y ago
  Those are discipline differences. At least I am getting the JS to TS (or tSQL to pgSQL or something) from this reference. Technology is a bit overloaded though so we may be picking up different meanings entirely.
  - orra 5y ago
    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).
- ketzo 5y ago
  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. Every message in moderation, I guess.
  - xxpor 5y ago
    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.
halfmatthalfcat 5y ago
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.
- gjvc 5y ago
  "by and large" https://books.google.co.uk/books?id=qCaK0pOz2EoC&pg=PA32&lpg=PA32&dq=%22by+and+large%22+%22by+in+large%22&source=bl&ots=30MNiAPPXL&sig=ACfU3U1b6cn2cXejZbEC1DqLw9MUUpJmaQ&hl=en&sa=X&ved=2ahUKEwjSyuWbp4n0AhVCt6QKHYHWAzMQ6AF6BAgWEAM#v=onepage&q=%22by%20and%20large%22%20%22by%20in%20large%22&f=false https://books.google.co.uk/books?id=qCaK0pOz2EoC&pg=PA32&lpg...
  - halfmatthalfcat 5y ago
    Ah thanks
mostertoaster 5y ago
I think it makes sense for hiring a contractor, but not for someone you want to be a long term employee.
- xcambar 5y ago
  I'd have said the exact opposite. A contractor is typically on a short(ish) term mission, so they need to be very cost-effective. After all, they're costly yet disposable. An employee is an investment, so you can take the time to onboard/train them properly.
  - RNCTX 5y ago
    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.
    - dboreham 5y ago
      Often contractors are engaged because there are no viable candidates to be found as permanent employee hires.
      - xcambar 5y ago
        that, or when you need flexibility re. your workforce and you're not willing/ready to commit long term.
  - mostertoaster 5y ago
    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.
    - xcambar 5y ago
renewiltord 5y ago
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.
0xB31B1B 5y ago
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.
- malux85 5y ago
  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.
  - hpoe 5y ago
    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.
    - malux85 5y ago
      The article just talked about $TECHNOLOGY in a general form, it didn’t even limit the discussion to web technologies. Hence my comment.
booleandilemma 5y ago
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?
theandrewbailey 5y ago
> 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.
nrclark 5y ago
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.
- flutas 5y ago
  > 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.
  - JAlexoid 5y ago
    I mean... There's plenty of android work available. The cost of switching domains is that you loose your "senior" status.
  - 999900000999 5y ago
    Arguably you could do any Java job. I don't think a React role would be a great fit. I've been boxed into a very specific field for 7 years. The pay is good and I have no complaints. I don't think said field is going anywhere, as someone who went though a few evictions as a kid I appreciate having work.
lordnacho 5y ago
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.
deepsun 5y ago
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.
revskill 5y ago
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.
wly_cdgr 5y ago
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
dboreham 5y ago
I've been doing this stuff for > 30 years. I've never ever had a discussion where this was said: “They won’t do. We need someone with at least $X years in $TECHNOLOGY" I have never had a anything to do with recruiters, either in hiring or candidate role. That may be related.
johngalt 5y ago
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.
deleted 5y ago
[deleted]
ehutch79 5y ago
I don't see why recruiters shouldn't be looking for engineers with 20+ years of kubernetes
es7 5y ago
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.
matthewmacleod 5y ago
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.
abeppu 5y ago
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.
wccrawford 5y ago
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.
logfromblammo 5y ago
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.
andrewstuart 5y ago
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.
- mbrodersen 5y ago
  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.
oblib 5y ago
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.
Felicitas785 5y ago
My juicy pussy is SOO hot, i want a man, fuck me here — http://gg.gg/wluus http://gg.gg/wluus
danielmarkbruce 5y ago
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...
stjohnswarts 5y ago
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.
robomartin 5y ago
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". Not saying this is the only way, just my way.
Blackstrat 5y ago
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.
firstfewshells 5y ago
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".
EVa5I7bHFq9mnYK 5y ago
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.

362 points by Amorymeltzer 5y ago

I can’t help but notice it’s always engineers writing these articles. Why aren’t managers or directors writing about their views on this?

tomrod 5y ago
Liability.
renewiltord 5y ago
We are. We’re just also engineers.
- xcambar 5y ago
  If every (engineering) manager or director you know around you is also a trained engineer... you're the exception, not the norm.
  - renewiltord 5y ago
    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.
    - xcambar 5y ago
      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.
      - renewiltord 5y ago
        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.
bentlegen 5y ago
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.)

btbuildem 5y ago

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?

giantg2 5y ago
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.

PaulHoule 5y ago

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.

zepolen 5y ago
Of course you can also get those who have years of doing the same year of experience.

bluedino 5y ago

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?

mmcdermott 5y ago
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.

WarOnPrivacy 5y ago

I'm waiting for an article with all the non-counterproductive hiring practices that applicants usually encounter. I figure it'll take up an entire line.

TrevorJ 5y ago
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.
- sokoloff 5y ago
  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.
  - Hasu 5y ago
    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.
    - TrevorJ 5y ago
      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.
- yuliyp 5y ago

giantg2 5y ago

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.

orra 5y ago
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.

thesuperbigfrog 5y ago

Master Foo and the Recruiter 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 http://www.catb.org/~esr/writings/unix-koans/recruiter.html

Jugurtha 5y ago
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.
- mLuby 5y ago
  One learns to walk differently in San Francisco, to avoid stepping in **it.** And of course if you walk without rhythm, it won't attract the worm.
  - Talanes 5y ago
    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.

rp1 5y ago

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.

TrevorJ 5y ago
>How far would you take this? 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.
- tshaddox 5y ago
  > 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.
- EarthLaunch 5y ago
  > 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. These hidden filters are interesting.
  - rp1 5y ago
    Yes, let’s build the Android app on iOS :)

jaywalk 5y ago

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.

ActionHank 5y ago

Seems like on the frontend side everyone requires React. Weird thing is that there are many devs who "know React", but have no clue how to play outside of that sandbox.

c0decracker 5y ago
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)

lbriner 5y ago

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.

throwawaygh 5y ago

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).

datameta 5y ago
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.
- throwawaygh 5y ago
  Yeah, totally fair. Nuance is king. 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.

carlsborg 5y ago

Exceptions exist. If you need a key cloud infrastructure hire, a super smart person who hasn't worked in cloud wont cut it.

rhacker 5y ago

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.

victor9000 5y ago
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.
- rhacker 5y ago
  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.

obedm 5y ago

I strongly disagree. 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.

atwebb 5y ago
Those are discipline differences. At least I am getting the JS to TS (or tSQL to pgSQL or something) from this reference. Technology is a bit overloaded though so we may be picking up different meanings entirely.
- orra 5y ago
  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).
ketzo 5y ago
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. Every message in moderation, I guess.
- xxpor 5y ago
  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.

halfmatthalfcat 5y ago

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.

gjvc 5y ago
"by and large" https://books.google.co.uk/books?id=qCaK0pOz2EoC&pg=PA32&lpg=PA32&dq=%22by+and+large%22+%22by+in+large%22&source=bl&ots=30MNiAPPXL&sig=ACfU3U1b6cn2cXejZbEC1DqLw9MUUpJmaQ&hl=en&sa=X&ved=2ahUKEwjSyuWbp4n0AhVCt6QKHYHWAzMQ6AF6BAgWEAM#v=onepage&q=%22by%20and%20large%22%20%22by%20in%20large%22&f=false https://books.google.co.uk/books?id=qCaK0pOz2EoC&pg=PA32&lpg...
- halfmatthalfcat 5y ago
  Ah thanks

mostertoaster 5y ago

I think it makes sense for hiring a contractor, but not for someone you want to be a long term employee.

xcambar 5y ago
I'd have said the exact opposite. A contractor is typically on a short(ish) term mission, so they need to be very cost-effective. After all, they're costly yet disposable. An employee is an investment, so you can take the time to onboard/train them properly.
- RNCTX 5y ago
  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.
  - dboreham 5y ago
    Often contractors are engaged because there are no viable candidates to be found as permanent employee hires.
    - xcambar 5y ago
      that, or when you need flexibility re. your workforce and you're not willing/ready to commit long term.
- mostertoaster 5y ago
  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.
  - xcambar 5y ago

renewiltord 5y ago

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.

0xB31B1B 5y ago

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.

malux85 5y ago
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.
- hpoe 5y ago
  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.
  - malux85 5y ago
    The article just talked about $TECHNOLOGY in a general form, it didn’t even limit the discussion to web technologies. Hence my comment.

booleandilemma 5y ago

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?

theandrewbailey 5y ago

> 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.

nrclark 5y ago

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.

flutas 5y ago
> 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.
- JAlexoid 5y ago
  I mean... There's plenty of android work available. The cost of switching domains is that you loose your "senior" status.
- 999900000999 5y ago
  Arguably you could do any Java job. I don't think a React role would be a great fit. I've been boxed into a very specific field for 7 years. The pay is good and I have no complaints. I don't think said field is going anywhere, as someone who went though a few evictions as a kid I appreciate having work.

lordnacho 5y ago

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.

deepsun 5y ago

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.

revskill 5y ago

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.

wly_cdgr 5y ago

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

dboreham 5y ago

I've been doing this stuff for > 30 years. I've never ever had a discussion where this was said: “They won’t do. We need someone with at least $X years in $TECHNOLOGY" I have never had a anything to do with recruiters, either in hiring or candidate role. That may be related.

johngalt 5y ago

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.

deleted 5y ago

[deleted]

ehutch79 5y ago

I don't see why recruiters shouldn't be looking for engineers with 20+ years of kubernetes

es7 5y ago

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.

matthewmacleod 5y ago

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.

abeppu 5y ago

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.

wccrawford 5y ago

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.

logfromblammo 5y ago

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.

andrewstuart 5y ago

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.

mbrodersen 5y ago
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.

oblib 5y ago

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.

Felicitas785 5y ago

My juicy pussy is SOO hot, i want a man, fuck me here — http://gg.gg/wluus http://gg.gg/wluus

danielmarkbruce 5y ago

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...

stjohnswarts 5y ago

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.

robomartin 5y ago

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". Not saying this is the only way, just my way.

Blackstrat 5y ago

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.

firstfewshells 5y ago

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".

EVa5I7bHFq9mnYK 5y ago

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.