[HN Gopher] Stop requiring specific technology experience for se...
___________________________________________________________________
Stop requiring specific technology experience for senior-plus
engineers
Author : Amorymeltzer
Score : 230 points
Date : 2021-11-08 15:41 UTC (7 hours ago)
(HTM) web link (mikemcquaid.com)
(TXT) w3m dump (mikemcquaid.com)
| renewiltord wrote:
| 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.
| btbuildem wrote:
| 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 wrote:
| 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.
| revskill wrote:
| 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.
| abeppu wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| mixmastamyk wrote:
| 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.
| JAlexoid wrote:
| > The old phrase, "a bird in the hand is worth two in the
| bush," comes to mind.
|
| It's also applicable to training vs paying for experience.
| (paying for experience being the bird in your hand)
|
| It's always a tradeoff, that you have to balance. The idea
| that you must never require a particular tech is a poor
| strategy.
| plorkyeran wrote:
| 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.
| jonas21 wrote:
| Quite the opposite. If skills are infinitely transferrable,
| then the skill level of a developer is a function of time
| they have spent in the field.
|
| This makes a senior developer extremely valuable because they
| will always be more qualified for any job than someone more
| junior than them and there is a limited (and shrinking)
| number of people who are at their skill level or higher.
|
| (to be clear, I don't believe that skills are infinitely
| transferrable)
| gopher_space wrote:
| I wonder where the break point is on looking for specialists vs
| raising them yourself.
| malux85 wrote:
| 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 wrote:
| 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 wrote:
| The article just talked about $TECHNOLOGY in a general
| form, it didn't even limit the discussion to web
| technologies. Hence my comment.
| JAlexoid wrote:
| But you're failing to recognize that some tech is almost
| synonymous with a domain.
|
| In my experience I've seen very cocksure senior engineers
| come in with the mindset that "this is just another tech
| stack, that I can learn in a week"... failing miserably to
| recognize that said tech stack is exclusively used in a
| domain that they're not at all comfortable with.
| morelisp wrote:
| > a senior frontend web engineer is not going to transfer to
| senior compiler engineer
|
| Arguably XHP/React is successful because some senior compiler
| engineers plied their trade in the front-end world. Or was it
| senior front-end engineers digging into compiler tech?
|
| How about Servo pulling a bunch of game development
| techniques into the browser development world?
|
| There are definitely technical domains you can gain or lack
| expertise in, but "frontend" vs. "backend" isn't one of them.
| Those are business contexts, not technical knowledge.
| carlsborg wrote:
| Exceptions exist. If you need a key cloud infrastructure hire, a
| super smart person who hasn't worked in cloud wont cut it.
| es7 wrote:
| 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.
| giantg2 wrote:
| 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 wrote:
| 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.
| wccrawford wrote:
| 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.
| booleandilemma wrote:
| 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?
| WarOnPrivacy wrote:
| 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 wrote:
| 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.
| yuliyp wrote:
| My first week at any job is mostly trying to get my bearings,
| and spending most of my time reading / listening. It's hard
| to skip ahead a few weeks and get _that_ day instead of the
| first day, though.
| TillE wrote:
| Beyond a simple FizzBuzz filter to screen out the truly bad
| applicants, it seems extraordinarily difficult to sort the
| rest. A probationary period (the norm in many countries)
| theoretically can do this, but in practice I think it again
| only helps screen out the egregiously poor employees.
| sokoloff wrote:
| 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 wrote:
| 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 wrote:
| 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.
| danielmarkbruce wrote:
| 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...
| wly_cdgr wrote:
| 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
| stjohnswarts wrote:
| 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.
| rhacker wrote:
| 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 wrote:
| 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 wrote:
| 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.
| [deleted]
| matthewmacleod wrote:
| 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.
| thesuperbigfrog wrote:
| 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
| golergka wrote:
| 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.
| JAlexoid wrote:
| Correct.
|
| There's a reason why you get geographically specialized
| pilots - little bits matter a lot
| Jugurtha wrote:
| 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.
| [deleted]
| biztos wrote:
| I've never been to Algiers but having done a lot of walking
| in Bangkok, I like this metaphor.
|
| The fact that I love to walk in Bangkok proves that I am into
| Walking in a way more regular, more fit, longer-distance,
| better equipped walkers generally are not.
|
| Dunno what the programming equivalent would be... maybe if
| you're into coding Windows apps in Brainfuck?
| datameta wrote:
| I like expanding a good metaphor, but I think the idea is
| that I wouldn't discourage a prospective tourist from
| travelling to Odessa, Ukraine* because of the belgian block
| streets or to Anytown USA because their road infrastructure
| isn't pedestrian oriented.
|
| *disambiguation added
| Jugurtha wrote:
| Given that you mentioned the U.S., I assume that by Odessa
| you don't mean the capital of Ukraine, but the town in
| Texas?
| datameta wrote:
| I do mean Odessa, Ukraine. As far as I am aware Odessa,
| Texas was not built in the 18th-19th centuries so there
| would be no belgian block streets to be found.
| jedmeyers wrote:
| > I assume that by Odessa you don't mean the capital of
| Ukraine
|
| Odessa is not and was never the capital of Ukraine.
| datameta wrote:
| Odessa was the 2nd or 3rd largest city in the Russian
| Empire and currently holds a similar status in Ukraine,
| afaik. This is largely due to it being a warm water port.
| Jugurtha wrote:
| I had a fleeting brain fart. Thanks/sorry for catching
| it. I know Ukraine's capital, but what's done is done.
| marnett wrote:
| I would very much consider Odessa, Texas as "Anytown
| USA". Not to mention I would question if the small town
| had Belgian blocks. I read the post as referring to
| Odessa, UK.
| ethbr0 wrote:
| Because this made me curious, apparently "San Jose" [0]
| is the most popular worldwide place name.
|
| [0] https://en.m.wikipedia.org/wiki/List_of_popular_place
| _names
| Jugurtha wrote:
| By the number of "San", it either questions the sailor
| expression "a woman in every port" as either saints
| getting around a lot, or that the Spanish got around a
| lot.
| datameta wrote:
| Not to take this into the realm of pedantry but unless
| you're referring the the United Kingdom, I should point
| out the country acronym for Ukraine is 'UA'.
| Jugurtha wrote:
| Isn't pedantry why we come to HN to read comments of
| precise people educating us and learn a bunch! Thank you
| for this.
| omegalulw wrote:
| Tbh your comment is an exemplar g what OP said: most people
| who know how to walk have probably have fallen on slippery
| surfaces and slopes, so they can easily figure out what to do
| when though the rules are different ("yellow tiles are bad
| when it rains").
| Jugurtha wrote:
| Yes. The example was a beautiful parable and I tried to
| write one, albeit more 'concrete' (pun intended on both
| concrete in construction and sidewalks, and programming
| with reference to concrete classes).
| savant_penguin wrote:
| Except if the language is c or c++. Then a misstep shoots you
| and your dog.
|
| Better know those floors goddam well
| queuebert wrote:
| You have stepped on a polymorph trap and segfaulted your dog.
| jedberg wrote:
| 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. :)
| yumraj wrote:
| And you are correct. The issue is that there are very people
| who have walked this floor already, and many are already in
| the building (company) walking the floor. So, if you can find
| people who have already walked this floor, great, they may be
| better.
|
| But, if you want access to a larger pool, then the next best
| is people who:
|
| 1) know how to walk and have been walking for years, and
|
| 2) have walked on many floors so that you can have confidence
| that they can walk this particular floor.
| JAlexoid wrote:
| Sometimes the learning curve is so high, that you would
| rather pay extra for upfront experience.
| Chris_Newton wrote:
| I imagine there must be roles in the programming world
| that are specialised enough for this to be true. However,
| at least in my own experience, it is mostly general
| programming ability and/or domain-specific knowledge that
| set one developer apart from another in the speed and
| quality of their work. Both of those take time to acquire
| and have value accordingly, but they are highly
| transferrable across specific tools. Soft skills also
| matter alongside the technical ones, and much more so as
| seniority increases, but it's the same story there. I
| can't immediately think of a field of programming where
| hands-on knowledge of specific technologies matters more
| than these other factors.
| TrevorJ wrote:
| It depends. There are people who's core skill is that they
| are amazing at learning generalizable lessons about
| approaching new terrain. They have a toolkit of methods that
| allow them to move into new territory and quickly gain
| competency, while avoiding most of the 'newbie' mistakes (or
| making them on the weekend on their own time).
|
| Other people excel at going deep on specificity. They know
| every detail and arcane quirk about THIS specific
| language/build system/toolchain.
|
| Both of these traits are desirable, but they will be great at
| slightly different things and under slightly different
| circumstances.
| ModernMech wrote:
| > while avoiding most of the 'newbie' mistakes (or making
| them on the weekend on their own time).
|
| Why would one wait to make mistakes on their own time?
| TrevorJ wrote:
| Well, let me clarify. It's not something that employers
| should expect from employees.
|
| But it _is_ a trait I notice in a lot of highly competent
| folk who are high achievers. They 'll see something
| coming on the roadmap that they feel like they want to
| prep/educate themselves on, and then they will noodle on
| it for an hour or two when they get a chance. By the time
| it comes time to implement it 'for real', they have
| already gotten most of the learning curve out of the way.
| gfxgirl wrote:
| 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?
| hippich wrote:
| I am one of these python+go+javascript+perl+php folks (minus
| go and python)... Yet somehow I know about memory access and
| associated gotchas. I am even able to heavily modify, debug
| obscure C codebase. Even made my own LLVM pass that does
| quite a tricky modification of the LLVM bytecode prior to
| final compilation and linking. I learned about LLVM bytecode
| existence about 3 months ago. I started tinkering with this C
| project about 8 months ago...
|
| Yes, there are differences, but they are not fundamental. And
| with google, it really takes little time to learn things on
| the go. And with a team sharing necessary experience it will
| take no time at all.
|
| EDIT: "I might want someone who can hit the ground running" -
| this is luxury, so one wanting it gotta pay up... And such
| short projects where such quick ramp up is important perhaps
| will be a better suited for contracting out the work anyway.
| JAlexoid wrote:
| Know of and being proficient are two different things.
| hippich wrote:
| I've solved serious problem using these two technologies,
| and it makes a significant impact right now. (sorry,
| can't discuss in more details).
|
| Sure LLVM or C pro will cringe looking at my code. But
| the business problem is solved, by someone who is not
| LLVM/C pro, and there is no need for more of that LLVM/C
| skills for now at the organization...
| morelisp wrote:
| Unless you are a startup that needs someone cranking out
| features within two weeks, the time it takes a senior[0]
| developer to get familiar with the company's actual work
| vastly outstrips the time it takes to get familiar with
| their commodity tech stack.
|
| (And if you are such a startup, you want mostly senior
| generalists anyway.)
|
| [0] Well, this is also probably begging the question. For
| me that's part of the definition of senior. Based on
| resumes I see lately it's far from everyone's.
| JAlexoid wrote:
| That's not universal.
|
| The lat thing I need about any of my colleagues is to
| learning all gotchas, at the same time as integrating
| into our team.
|
| Some tech I'll argue against, other tech I will require.
|
| Some tech is fundamental to a domain. Some tech is a nice
| to have. Some tech is just generic.
|
| My current team will not hire anyone for a senior role,
| without Spark experience. No matter how good you are in
| C++...
| morelisp wrote:
| > My current team will not hire anyone for a senior role,
| without Spark experience.
|
| An example close to my heart. The company I'm currently
| at had a totally ossified Spark monolith and data eng
| team because they only wanted Spark developers. Drop one
| C++ developer in there to start spreading the good news
| about data-oriented design and suddenly there are a dozen
| previously-intractable "big data" problems we can rip out
| of the ball of mud and run outside of the cluster. Drop
| in another SRE who doesn't know shit about Java but can
| actually write shell scripts, and hey alerts from bad
| orchestration from weekly to twice yearly.
|
| Yeah if you have a Spark job, you probably need _a_ Spark
| dev. But if you have a team of Spark devs, suddenly
| everything that involves more than 1MB of input data
| looks like a Spark problem and you 're in for a real bad
| time in a couple years.
|
| C++ programmers know map/reduce/filter too.
| JAlexoid wrote:
| Well... Funny enough. The person that our team of Spark
| engineers is cleaning up after was - a C++ dev. For some
| reason we, Spark engineers, had to rewrite his all Spark
| application into different components with relevant tech.
|
| Thanks for generalizing Spark engineers to an insulting
| level, though.
| tialaramex wrote:
| I was hired into my current role where a lot of code is in C#
| never having written any C# in my life. That was about six
| weeks ago. The interviewers correctly assumed that since I
| have written numerous other semi-colon languages for 20+
| years and know what I'm doing it won't be a problem. I use
| some modern C# idioms (because to me no idiom is more or less
| "modern" as I learned them all in the last six weeks) more
| than my colleagues do, and I think I'm perhaps squinting at
| the async feature wrong, but it's basically fine at this
| point.
|
| I would not have taken a C++ role. But that's because I don't
| like C++. Could I learn C++? Presumably, I assume it'd take
| quite a bit longer than C# but I don't want to.
|
| A _lot_ of programming skill that 's transferable from one
| role to another is also transferable from one general purpose
| language to another. Almost everything about programming
| generally is transferable. All the practical implications of
| architecture is transferable. All the theory is transferable.
| Data structures are transferable (albeit if you've got very
| narrow experience you may not be aware of just what's
| possible). A _lot_ of high level APIs are transferable.
|
| On the other hand corporate knowledge isn't. So, the fresh
| graduate hire who is an expert in your preferred language
| does not know that around here nobody above an Engineer Lead
| reads their Teams chat, and nobody above Group Manager reads
| email. They don't know that tweaking the CSS requires a
| Design Team Lead authorisation because once somebody made the
| text the wrong colour and branding were furious - and they
| equally don't know that "Normal Minor" changes take six
| months to approve around here so they should mark small
| changes "Urgent Minor" instead and then pester a Senior
| Engineer to OK them, but _never_ pester a Senior Engineer if
| it needs a Config change because _that_ is an ops problem
| and... you are going to need to hire internally if you
| actually need them to "hit the ground running".
| c0decracker wrote:
| Great point IMHO. I think the ability to learn these somewhat
| different languages depend on the experience. Like roots of
| different trees -- once you groked Asm/C, C++, Python and
| such, Lisp and such enough, you can get productive in most
| general purpose languages quickly enough that language
| learning time will be negligible compared to
| platform/ecosystem/domain time at least for any reasonably
| complex domain.
|
| I think more pragmatic question in such situations however,
| is why the potential employer is requiring $A years of
| experience in $TECHNOLOGY. For example, why they need someone
| to be productive from the say day $N and what does it
| actually mean (for them) to be productive?..
|
| IMHO getting to shared understanding of what drives such
| requirements can help find a better path forward for both
| sides.
| codegeek wrote:
| Yes but then it is not comparable. Using GP's analogy, I
| would say Walking = Web Development (whether you do in PHP or
| Go, http is http etc). However, if you are talking about C++,
| let's call it "Para sailing" and not walking. Since you are
| not just writing a bunch of http API for the most part (I am
| simplifying a bit but you get the point).
| WalterBright wrote:
| I find now and then that less experienced programmers can be
| adroit with programming techniques, but will use those
| techniques inappropriately.
|
| Sometimes, the right tool for the job is just a hammer :-)
| mixmastamyk wrote:
| You can find exceptions but it's generally true. For example
| the high level data structures in Python and Java are both in
| the collections package.
|
| I haven't done C or asm since college but haven't forgotten
| the concepts. Probably know more now than then.
| ourmandave wrote:
| Where's the Zen Slap? Don't leave me hanging bro!
| jaywalk wrote:
| 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.
| theandrewbailey wrote:
| > 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.
| obedm wrote:
| 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.
| zerkten wrote:
| 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.
| ketzo wrote:
| 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 wrote:
| 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.
| falcolas wrote:
| The forklift analogy is pretty bad; you can get proficient
| enough to move basic pallets with about around half an hour
| of effort and instruction if you've driven a car. Using one
| is more of a matter of thinking through the various moves
| than being swift and confident with the controls.
|
| Or so says my wife, who is not a truck driver but can drive
| a forklift.
| xxpor wrote:
| I do wonder how long it would take me to get used to
| driving with rear wheel steering...
| falcolas wrote:
| Surprisingly quickly, especially if you've ever done
| any... shenanagains... in reverse.
| JAlexoid wrote:
| Actually, forklifts are rear wheel steering equipment. So
| your truck driving experience is not at all relevant... and
| may be a hindrance.
|
| From my perspective a HS graduate with a lot of hand-eye-
| coordination experience is a better choice - than you.
| ketzo wrote:
| Right, which is the main thrust of the linked article. I
| think it's useful, though, to try and pick apart the
| boundaries where that argument breaks down; how different
| of a forklift do you need for your experience to stop
| applying, etc.
| todd8 wrote:
| 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.
| DeathArrow wrote:
| >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
|
| You can't know everything even in one domain. But once you
| are a good programmer, you can pick up fast most domains.
|
| If you want to do GUI, just try it. You will be amazed that
| you can actually pick it up pretty fast.
| DeathArrow wrote:
| 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.
| redisman wrote:
| It also gets easier the more things you already know.
| Nowadays learning a new domain is mainly a mapping exercise.
| Oh this is kind of like X. Neat so that is basically a twist
| on Y. Especially after you've lived through a few hype cycles
| and start to realize there's not all that much that's
| foundationally new under the sun.
|
| I've also worked on web frontend, games and physics, web
| backend, databases, near metal, very far from metal. I never
| felt like anything was out of my reach to pick up while
| working on said thing for the first time at a new company.
| ghotli wrote:
| 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.
| JAlexoid wrote:
| > Just be able to walk the walk after you talk the talk.
|
| Lucky you. You must not have been burned and haven't wasted
| your time on someone that couldn't walk the walk.
|
| I have wasted enough months of my life on people like that.
| ghotli wrote:
| I have and adjusted how I interview accordingly.
| Proficiency at the glossary problem of a given domain is
| for sure not the only thing worth covering in an interview
| :)
| JAlexoid wrote:
| That's why one of the first things I check - proof of
| walking.
| xxpor wrote:
| 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.
| goodpoint wrote:
| > 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.
|
| Spot on. That's why you hire people that can learn and think
| - not robots.
| [deleted]
| pornel wrote:
| 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.
| filoleg wrote:
| > _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.
| area51org wrote:
| Exactly this. A capable engineer can learn whatever's needed.
| The idea that you should hire only niche specialists _sounds_
| good but is completely wrong-headed. The best engineers I 've
| ever worked with were good because they would and could pick
| up whatever was needed. Specialists OTOH are usually narrow-
| minded and lacking in motivation--and of little use outside
| of their one small niche.
| mywittyname wrote:
| Hire for smart, capable people first.
|
| Being an OS-level C++ engineer is definitely a marker for
| smart and capable.
| Felicitas785 wrote:
| My juicy pussy is SOO hot, i want a man, fuck me here --
| http://gg.gg/wluus
| filoleg wrote:
| Yup, that's pretty much why he got hired. He was clearly an
| all-around smart guy who knew his fundamentals, had zero
| issues with learning new things (in fact, seemed to enjoy
| it, which is always a great mark in my book), and seemed
| very socially smart (i.e., great to work with as a
| teammate). As a sidenote, "socially smart" isn't a synonym
| for "that guy who cannot stop obnoxiously bothering
| everyone with their constant chatter". "Socially smart"
| means that he has enough sense of tact and awareness to
| know when and what to say (or not to say anything at all).
|
| The fact that he wasn't familiar with front-end tech at the
| time was just a tiny blip that absolutely no one was even
| slightly concerned about when he joined.
| zepolen wrote:
| 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.
| stank345 wrote:
| Things a frontend dev would know that a backend may not:
| - HTML and CSS (facility with selectors) - JS syntax
| and semantics, common patterns and idioms, gotchas -
| Web APIs - CORS - Frontend data persistence
| mechanisms (cookies, local storage, etc.) - Critical
| rendering path - Service workers (how and when to
| use) - Accessibility (ARIA)
| DeathArrow wrote:
| >They'd probably make the frontend app faster, less
| complicated and use less memory.
|
| And while at that, get rid of those nasty frameworks.
| nsotelo wrote:
| 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.
|
| Etc.
| drdaeman wrote:
| I believe it's not about learning how to do things. That's
| not that hard. It's about knowing about the gotchas - things
| _not_ to do. Every technology stack has its warts and
| oddities.
|
| It's not that hard to write some code that would do the job,
| it's hard and cost prohibitive to realize all the initially
| hidden nuances that might require redesign because of
| shortsightedness of the original one.
|
| Requires either a really bright fast-thinking mind or just a
| lot of experience making one's fair share of mistakes. There
| are geniuses out there who can make perfect models in their
| heads, but I believe a lot of people just scrape by knowing
| where them or others had shot themselves in the foot before.
| And such experience only comes with time.
| atwebb wrote:
| 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 wrote:
| 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).
| yumraj wrote:
| > 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/.....
|
| And, so on...
| RussianCow wrote:
| > 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.
| falcolas wrote:
| 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.
| JAlexoid wrote:
| There are massive differences between front-end and backend
| engineers.
|
| Backend engineers deal a lot less with network instability,
| than frontend engineers. Frontend engineers have multiple
| ways of dealing with failure. And frontend engineers have a
| different ways of dealing with parallel and async tasks, than
| backend engineers.
|
| It's not a massive challenge for a smart person to learn, but
| we shouldn't pretend that people don't try to apply their
| previous experiences to future tasks. Which is a cost, when
| hiring someone without specific domain experience.
| danenania wrote:
| I think going from backend to frontend can be more of an
| issue. Being a really good frontend engineer requires a
| strong sense of ux and design that can be completely at odds
| with how a backend specialist's mind works. It's not
| impossible, but might be really tough.
|
| Going the other direction, there will be new concepts, more
| focus on algorithms and scalability, more focus on ops and
| infrastructure, etc. But it's all still in the realm of
| programming.
| falcolas wrote:
| In my ideal world, theres a UX designer to take in (and
| mentor in) that work. Perhaps design is baked into frontend
| work in smaller companies, but every place I've worked has
| had a specialist devoted to that work.
|
| Even I, an infrastructure monkey, can follow a design doc
| with explicit values for widths, lengths, and font colors,
| faces, and sizes.
| danenania wrote:
| I think that in practice a frontend engineer is still
| going to be making a bunch of ux and design-oriented
| decisions during implementation, since no design ever
| translates perfectly. Botching these over and over really
| slows things down (or hurts overall quality if they never
| get cleaned up) compared to someone with enough design
| sense to improvise and fill in the gaps.
| [deleted]
| speby wrote:
| 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.
| logfromblammo wrote:
| As one of those back-end-preferring developers, the thing
| about front-end development is that the correctness of UI
| code is subjective, and furthermore subject to the _user 's_
| opinion. On the back end, I can write heaping piles of unit
| tests to verify objective correctness of math and data
| consistency. But on the front end, this button needs to be
| further to the right, and labeled in a different font.
| rp1 wrote:
| 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.
| Const-me wrote:
| > If you do, you're going to have a very bad time.
|
| GUI libraries are pretty similar to each other. I have never
| written an Android app before, but in a hypothetical case when
| I would want to make one, I'm pretty confident it would take me
| a week or two to learn these things. I'm very familiar with
| quite a few other platforms: everything Windows from WinAPI to
| UWP including phones, iOS, I made my own GUI frameworks even...
|
| If that lead developer does not have _any_ experience writing
| rich GUI apps in any language, and no experience with computer
| graphics either, now that would be a red flag for me. That's
| too much new stuff to learn in reasonable time: computer
| graphics in general with these pixels and vectors, Unicode
| shenanigans, UX shenanigans especially touch screen related,
| and quite a few others.
| bluedino wrote:
| >> in a hypothetical case when I would want to make one, I'm
| pretty confident it would take me a week or two to learn
| these things.
|
| The thought might be, how long would it take you to make a
| _great_ one? An 'expert' might be able to create it by the
| time someone else has started figuring out lower to mid-level
| concepts.
| Const-me wrote:
| The low-level concepts are exactly the same across all
| modern platforms. Specifically, GUI on all platforms is
| made of bitmaps (in modern world often encoded into
| jpeg/png/astc/etc.), vector graphics (polygons, quadratic
| and cubic Bezier), and font glyphs (same Bezier as in
| vector graphics + typesetting). These 3 things were
| invented many decades ago, and stayed pretty much the same
| over these decades.
|
| Mid.level concepts are more diverse, but not dramatically
| so. All popular GUI libraries are object oriented, web
| included. MVC on iOS does have some differences compared to
| MVVM on Windows, but conceptually they're still very
| similar.
| rp1 wrote:
| It's funny, your comment highlights exactly why
| experience is important. You don't know what you don't
| know about Android development. You have a set of very
| basic assumptions about how the API works, and have no
| idea what the challenges of Android development are.
| Sure, you could figure out how to build a basic app
| quickly, but you probably wouldn't do a good job building
| the foundation of a large app being worked on by dozens
| or hundreds of engineers.
| SavantIdiot wrote:
| The principal doesn't have to make a "great" android app:
| the principal has to correctly train and marshall their
| engineers to create a "great" android app. I think you
| might be stuck in the narrative of the "solo contributor
| genius". In reality, the vast majority of great products
| require teams.
| TrevorJ wrote:
| >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.
| EarthLaunch wrote:
| > 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 wrote:
| Yes, let's build the Android app on iOS :)
| sidlls wrote:
| The programming language and any platform SDKs (like Android)
| are the least interesting aspect of this. The history behind
| any existing applications, libraries, and customized
| frameworks is far more important to consider. Someone who is
| engaged in learning Android development systems from scratch
| is going to be less effective at understanding why decisions
| were made the way they were, and therefore will definitely be
| less efficient at leading an effort than someone who already
| knows the platform well.
| pizza234 wrote:
| > How much time would it take for a smart, competent and self
| motivated person to get up to speed on this new but related
| field?
|
| This depends on the position; smarts are not a replacement
| for (domain) experience, because certain knowledge can be
| learned only through trial and error and/or through long-term
| exposure to a domain (in other words, experience).
|
| I believe that domain experience is the more necessary the
| higher level the position is (e.g. seniors who can decide on
| architecture, leads, architects...).
|
| Having said that, I certainly agree that in the (hiring)
| industry it's common to be excessively attached to the
| specific tools used; I also suspect that smaller companies
| tend to think like this more than bigger ones.
| TrevorJ wrote:
| I think it probably depends on what the domain _is_. If the
| position is highly technical in nature then I would agree.
| However, I do think that beyond a certain point the ability
| to become highly competent on the fly in a new domain is
| extremely valuable. If the person will be giving input on
| business strategy, tech pipeline, then the ability to move
| laterally and adopt new ways of doing things should be
| highly valued.
| tshaddox wrote:
| > 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.
| morelisp wrote:
| > Would you hire a senior Android developer to lead your app
| development who has never written an Android app before?
|
| I assure you a million companies did exactly this ca. 2010. And
| that was back when it was much more difficult to write one,
| both devices and the SDK had orders of magnitude more sharp
| edges and restrictions than they do now.
| dllthomas wrote:
| ... in a very different competitive environment, and with
| probably a larger number of failures to get to market
| (although it would be interesting to put numbers to that, if
| they can be found).
| morelisp wrote:
| If anything the additional stacks means both app quality
| _and_ the platform-specific knowledge a senior dev needs
| has declined, since today you 're probably working on a
| pile of React Native bullshit or something that has very
| little to do with Android anyway.
| rm8x wrote:
| True in the case of React Native bullshit, false in the
| case of a native app that isn't just CRUD. A senior
| without android experience could jump on the apps that
| are glorified websites and be productive relatively
| quickly.
|
| A senior without android experience is going to have to
| learn the platform; this will take longer than learning
| the language. The pace of change updates the best
| practices often enough to serve as a kind of catch-up
| mechanic but native mobile does in fact require domain
| knowledge. I would be comfortable putting a senior iOS
| dev on native android but certainly not as the lead.
| ActionHank wrote:
| 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 wrote:
| 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)
| oblib wrote:
| 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.
| halfmatthalfcat wrote:
| 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 wrote:
| "by and large"
| https://books.google.co.uk/books?id=qCaK0pOz2EoC&pg=PA32&lpg...
| halfmatthalfcat wrote:
| Ah thanks
| PaulHoule wrote:
| 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 wrote:
| Of course you can also get those who have years of doing the
| same year of experience.
| lbriner wrote:
| 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.
| lordnacho wrote:
| 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.
| nrclark wrote:
| 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 wrote:
| > 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 wrote:
| I mean... There's plenty of android work available.
|
| The cost of switching domains is that you loose your "senior"
| status.
| bluedino wrote:
| 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 wrote:
| 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.
| deepsun wrote:
| 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.
| andrewstuart wrote:
| 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.
| throwawaygh wrote:
| 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 wrote:
| 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 wrote:
| 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.
| logfromblammo wrote:
| 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.
| mostertoaster wrote:
| I think it makes sense for hiring a contractor, but not for
| someone you want to be a long term employee.
| xcambar wrote:
| 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 wrote:
| 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 wrote:
| Often contractors are engaged because there are no viable
| candidates to be found as permanent employee hires.
| xcambar wrote:
| that, or when you need flexibility re. your workforce and
| you're not willing/ready to commit long term.
| mostertoaster wrote:
| 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 wrote:
| thanks for the clarification :+1:
| ehutch79 wrote:
| I don't see why recruiters shouldn't be looking for engineers
| with 20+ years of kubernetes
| Aeolun wrote:
| 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?
| renewiltord wrote:
| We are. We're just also engineers.
| xcambar wrote:
| If every (engineering) manager or director you know around
| you is also a trained engineer... you're the exception, not
| the norm.
| renewiltord wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tomrod wrote:
| Liability.
| dboreham wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2021-11-08 23:01 UTC)