Hacker News Reader

Comment by tkiolp4 | Hacker News Reader

I don’t buy it. As software developers we learn technologies for breakfast. We learn them, and then we forget them. We recollect the wisdom gained and apply it in our next gig using a different technology. It works for mobile development, for frontend, for backend, for infra, for almost anything.

I have worked for years with PHP, Apache, Ansible and MySQL. Nowadays not anymore. And in 7 years I’ll be using something else. Learn the fundamentals (which is not a one-time job, btw) and you’ll be fine. If someone asks for technology X in their job offers when you know Y, but you know you won’t have difficulty in learning X, just take a few days in learning X and then put it in your CV. You’ll get pass HR screening and then you’ll have a chance to explain in tech interview that your are more of a technology-agnostic dev. You’ll do fine.

View on HN

Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

Better yet, since I did Windows CE development for ruggedized devices using C# Compact framework back between 2007-2010, I should have no problem picking up iOS development “in a few days” and start being a productive member of a team right? Or better yet, leading a team?

Third thing, I know the fundamentals of web development including JavaScript, HTML and CSS. But I haven’t done anything on the front end since 2012. Are you going to hire me to help create your website when you’re looking for a modern web developer?

Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

These days, I am only looking for jobs where I have some type of team lead/architect position. Are you going to hire me to lead a team working on a 10 year old complicated Java app when all of my “enterprise” experience is in the .Net ecosystem?

On another note: I haven’t randomly submitted my job to an ATS worrying about an “HR” screen since 2008 across 5 jobs. I’ve always either reached out to my network or had someone reach out to me.

Thanks very much for posting this, totally agree. I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I think this paragraph was key:

> Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

That said, I still nearly always hire for general skills and not specific technologies, as long as there is at least one expert in the specific tech under consideration on the team (which there nearly always is). And I budget anywhere from 3-6 months for a person to become truly proficient at a new platform technology.

I always read "learn" in this context as "be familiar enough with the basic language properties that I can pick the rest up on the job, get things done, and not be too dangerous, or annoying in code review"

and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack.

I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transferable.

What about your tech leads who are looking for top of market salary? By top of market, I mean within your hiring pool not senior staff principal engineer level at a hedge fund

What about them? I'm looking for someone who has lead a team, solved that level of problems, has good soft skills and leadership.

The language or stack is irrelevant.

A good lead knows the right questions to ask, understands they don't have all the answers and plays to their own and the teams strength.

Honestly the last thing I care about, especially here, is if they know the stack.

And the other part of “leading the team” is being able to mentor juniors and help them technically.

What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?

What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?

The team has a culture that knows full well someone is brought in for who they are ... what they know might need some catch up.

I'm not saying this is right in all circumstances. I wouldn't do this with, for example, realtime embedded.

For what I operate in, fairly bland web applications and stacks.

It works fine, exceptions excepted.

The team has a culture where the leads know less than they do and they are okay that?

You're generalising to win an argument.

The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.

For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.

Sorry that contradicts the black-and-white world view you're holding.

I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.

You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.

Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

> Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts.

Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”.

[1] My four experiences with dealing with mobile implementations

1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements

2. Railroad car repairmen in a rail yard

3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints.

4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.

There is a persistent attitude that developers are interchangeable, that the tech matters less than the knowledge of how to apply tech to solve problems.

I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with.

Consider if someone has written lots of PHP and jQuery

Now tell them to write a NodeJS server, React Frontend using NextJS.

It's not just "Oh I need to pick up ExpressJS" anymore. It's a whole beast.

Yeah the fundamentals stay the same. REST is still REST, SQL is still SQL, but actually writing lines of code is still a key activity of the job which people familiar with the technology will be better at.

Personally I run into this any time I try and write C#. There's a massive undercurrent of stuff that I feel I don't understand about C# and I bounce off that ecosystem every time I try

> SQL is still SQL

And you’re going to hit a brick wall at 100 mph thinking SQL is still SQL once you try to treat a columnar database like Redshift or Snowflake like you would a traditional database.

That would be an expensive lesson to learn on the job. That’s just one example of trying to pattern match based on what you know when you hit a new to you technology.

It’s like the old school operations people who study one course of ACloudGuru, get a certificate, call themselves “consultants” and duplicate an on prem infrastructure and internal process and their poor clients wonder why they are spending twice as much and not moving faster.

I've never actually used Redshift or Snowflake so I can't comment.

I will say that even moving from Postgres to MySql has a speed bump or two, so I completely agree.

Tech knowledge just isn't as interchangeable as hiring managers sometimes seem to think.

I agree with all of this - and the skill that leaders need isn’t demonstrating (intermediates can do this), but coaching - this will help develop the team to be able to solve the issues themselves.

You can’t coach what you don’t know. And the reality of leading an engineering team is that when your team members actually seek your opinion on a problem, you have to know the specific solution to specific details, not general patterns.

But as a leader, if you don't know - then it's an opportunity for you and the team members to learn it together, the real point of which is teaching the team members how to adapt. Half the crap people ask me, I don't know, but I'm happy to find out with them. And maybe next time they'll be able to figure it out on their own.

And while you are fumbling around trying to learn the technology, the market is leaving you behind, you’re burning through resources and you’re not creating business value by either making the company money or saving the company money.

Great, you learned swift and can do a bunch of leetcode with it. It has nothing to do with actually managing a complicated iOS software project with the zany decisions that have gone into the framework design and tooling. Also good luck with the lazy documentation from Apple and the extremely contrived examples from educators. Can you learn all this in somewhat reasonable time and not code something horrific as a result? Absolutely, lots of people do. In a couple days? Good luck.

Not to out myself and my level of skill, but it took me several days off and on just to wrap my head around the minutiae to get Apple signing for macOS and iOS to work just right. Learning the rest of the ecosystem came along eventually, but I think the real point is with a couple of days worth of intense study, I, and any other developer worth their salt, can bullshit your interview that requires a specific language, but no one requires a specific language for interviews anymore because everyone knows that!

Do your interviewers not ask you to talk through your real world experience?

Having sat on both sides of the table, the job of the one giving the interview is to suss out how much the candidate is full of hot air. The one being interviewed wants to put in the precise amount of hot air required to pass the interview and get to the offer stage. Talking through real world experiences, a candidate can prep and be able to pass despite not actually having had those experiences.

At my last job I was officially a senior software engineer. But I was the de facto “cloud architect”. I was looking for someone to off load some of the cloud work too. I could tell someone who was faking it from a mile away. I am objectively very good at behavioral interviews (my next job at AWS ProServe was based passing a 5 round behavioral interview loop). The guy I eventually chose moved on to be an IT manager at the next company my CTO went to.

I can tell a paper tiger from someone who just went through ACloudGuru and memory enough to pass an exam.

How though? what are some of the tells?

And you are probably not going to pay me the same as someone who already have the experience you are looking for (and you probably shouldn’t).

Because of the stupidity of hiring and raise practices (not your fault as a hiring manager), you can get HR to open a job req at market rates. But it’s a lot harder to get HR to allow you to give your current employees raises to get them at market rate.

That investment is then lost because your employee is going to jump ship.

its fundamentally wrong to treat your employees learning process as a long term investment that you maintain ownership of. paying someone for two months to come up to speed is an investment. if they become productive in your environment, that investment is very quickly paid off. if they don't, then your at-risk investment didn't pay off. the return is the work that you got from them afterwards. you don't get to claim ownership of what's in their head.

if someone gives you two years of good work and moves on because you aren't giving them what _they_ need, or because their father got ill, you still came out way ahead. you should be a human and accept that.

They didn’t though if I hired someone with no experience. They gave me six months of negative work as they took time away from the more experienced developers, did a year and a half of resume driven development (if they are smart) and then moved on.

If I hired someone with the experience I was looking for, then they gave me 2 years of productive work.

Why would I train someone new instead of just poaching your developer at market rates?

>Why would I train someone new instead of just poaching your developer at market rates?

Because you pay more, and still have the risk of less/negative productivity anyway? Who says experienced dev won't do 2 years of resume driven development instead? Who says they won't simply zone out and spend their last 6 months being poached the same way you poached them from the last company?

your argument works under the assumption that your experienced hire has no downsides, and there's no risk of upside for the less experienced hire.

having a mix of experience levels is really healthy for an organization.

streamlining onboarding and extracting the secret recipes from the seniors is really valuable

there is no better understanding than that gained by teaching

its clearly a higher risk investment, but often times that one super workhorse and brilliant jewel is the one that you helped grow

but yeah, I've had employees that just sat around learning the latest fad and left. it happens. but if it happens a lot then maybe you should look at your hiring and management

if I convince someone to come work for me, its not poaching. its life.

> but if it happens a lot then maybe you should look at your hiring and management

You as a hiring manager only have power of hiring and management. Your HR department at the behest of their management controls how much of a raise you can give your employees.

You can give them the meaningless platitudes of “we are family” for only so long.

> I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I

It is, maybe you aren't a good developer (yet). The more you do it, the easier it gets. It took me a good time to change from PHP to Python, but from there to Java, JavaScript, C#, Clojure and some 10 more, it only got easier. Toolchain frameworks, idiosyncrasies, foot guns, best practices also follow patterns and gets easier to learn.

Personally, yeah, I would have no trouble hiring you for any of those things, based on your experiences. I wouldn't have expectations that you'd be the most productive member of those teams "in a few days", but a few months, sure. And I would expect your wisdom from working on a bunch of different things to be a lot more impactful than whatever fine grained details you don't yet know of the exact technology we're using.

You're saying that in isolation. If you have 50 other resumes on your desk for a React job, there's no way you're going to choose the guy who hasn't touched front-end since 2012.

That's not been my experience with hiring. My experience has been that 9 out of 10 resumes that cross my desk have almost no relevant job experience at all.

I'd love to have someone apply to a .NET desktop app position with 5 years of solid experience building Java web services. I'd love to fill a Node.js web service position with at least someone who spent 10 years writing embedded C for home automation devices. Hell, I'll take a brand new CS grad who built a janky Unity3D app in their spare time, not because it was a school project, but because they just wanted to.

What I get is IT network technicians who took a programming certification, substitute teachers who 15 years ago did software QA testing, public policy majors who dabbled with Matlab or Python in grad school, boot camp grads who haven't touched programming again since they finished their 8 week course 10 months ago. People who have never had any experience with the care and feeding of any kind of software project that other people had to work with them on for any significant time.

I'll get 1 resume out of the batch (and they always come in groups of 10) that is just a software developer: for whatever N years of experience, at least the most recent .8N has been software. Then it comes down to figuring out if they were actually a contributing member or spent most of their time hiding in a large team.

> My experience has been that 9 out of 10 resumes that cross my desk have almost no relevant job experience at all.

We're all out here shedding a tear for you. Not too sure what you expect, as they say, the real talent doesn't need to apply to job postings and submit resumes blindly. With that said, is there anything in your .NET desktop job posting that would encourage a Java web service developer to apply? The first day of every month a bunch of people with widely varying backgrounds and experience post on this very site that they are seeking work... ever reach out to any of them?

This is what I find amazing about a lot of the replies I see here. I saw the writing on the wall four months ago that I was probably going to be “Amazoned” soon after my manager left.

I’ve been warming up my network like crazy over the past four months, preparing my resume and career document, etc. I keep my network semi-warm regardless.

When the day came and I had the offer to quit and get big check or stay, I chose the quit option, before my last day, I had one manager trying to create a position for me, a second round scheduled with another former company and a third and final round scheduled at a third company.

All based on networking.

It’s foolish in this market to hope something is going to happen quickly by randomly uploading your resume to an ATS and keyword stuffing your resume like an SEO technique from the 90s trying to juice your position on Altavista.

On the hiring side, a hiring manager also needs a network that they can call on when trying to find candidates.

>the real talent doesn't need to apply to job postings and submit resumes blindly.

I think there's a huge valley of difference between "no relevant job experience" and "real talent". I do a mix of job postings to stuff that looks interesting while also talking to my network.

Sure I would. My company builds stuff with React, but that isn't what's important to what we do. It's just an implementation detail.

I mean obviously it depends on a bunch of other stuff in the resumes and during the interview process. But no, it's not a huge advantage to know React or have done front end development recently, just because we do some front end development in React. It's like the tenth most important consideration for whether someone would be a valuable contributor.

I’ve done this exact thing. Stop telling people how they’d act.

Stop telling me how I should stop telling people how they’d act!

I kid.

I agree completely. Even if I did learn React. I still wouldn’t know the tricks to make a modern, usable, website. I would be no good as lead responsible for giving input on best practices and strategy.

Sure you would. It's all the same thing, just different details. You'd do the same thing you do with whatever stack you're currently using: you'd read a lot, do a lot of proofs of concept and prototypes, make a bunch of mistakes, but figure it out and do just fine.

Sure, you wouldn't be as fast as someone who has worked with these tools a million times, and sure, that would matter if you're being hired on a three-month contract to build something and part ways. But if you're being hired to be a valuable contributor and leader at a company, this learning period is going to come out in the wash.

Let me give you an example: At my current company, by my estimation our MVP employee on the engineering side spent most of his career making video games, largely within the Microsoft stack. We do python, go, and React. If we hadn't hired this person because he had never used any of those technologies, that would have been, by a very long shot, the stupidest decision we ever made. This stuff just. doesn't. matter.

And why would you waste money on waiting for me to come up to speed when there are literally thousands of people who know react and can hit the ground running?

And at this point in my career I’m looking for lead positions. Would you hire me to lead your front end efforts?

(my area of expertise is enterprise app architecture/dev + AWS. As a developer I spent most of the modern era of my career working with Node, C# and Python).

I would not be wasting my money, I would be hiring you for all the other skills and experiences you have, which I would find far more compelling than whether or not you already know something you can learn in a few months. If I thought it was a waste to hire anybody who would take non-zero time to learn the stuff they need to know to be an effective employee at a specific company, it would be impossible to hire anybody (except people who already worked there and only left quite recently). Hiring full-time employees is an investment in their ability to contribute net positively to the company over their whole tenure, not in the first few months.

You are right though that I wouldn't hire you to lead a dedicated front-end team. But I'd prefer not to have such a team to begin with. But I'd be happy to hire you[0] to lead a product team working on a product that requires a front-end to succeed. Either other members of your team will know how to make that part work well, and I would expect you to learn quickly from them, or I would expect you to figure it out and then teach the rest of the team.

[0]: I'm using "you" as a stand-in for someone with your experience, who is otherwise a good fit for the organization. I may well not hire you in particular and suspect you would not take a job from me in particular, since we clearly have very different philosophies on specialization vs. generalization and investment in employee training, such that we may not enjoy working together :)

I've interviewed a lot of candidates over my years and technology specific information isn't something I ever look for, unless money is tight.

> unless money is tight

The software dev job market is cooling down. Making good choices on what to build experience in is more important than it has been in recent years.

I think many companies, including mine, are thinking they have only a few spots to fill and a lot of candidates to consider. I know we consistently say things like “who will be productive quickly?”

I honestly think that if you have a short enough runway that "who will be productive quickly" is a prime concern, it may be time to consider hiring nobody and figuring out other ways to save money and extend runway. And if you aren't that desperate, then you should stop asking this question and instead ask "who will be a good investment longer term?".

Alas, that's not how the market works, unless you can pay top of market. So for FAANG, that works, but for startup #293928293 that won't work. They need to ship more features asap (an orthogonal discussion about building the right features is a different matter), and for that they don't have time to bring someone up to speed, only for them to jump to a better paying role once they've upskilled.

I've worked at all different kinds of companies, and I don't think this is the way it works at well managed startups.

The model I've seen at startups is an approximately two-year cycle of 1. raise money against a couple year plan of milestones, 2. hire quickly on the back of that raise, 3. use that personnel growth to hit those milestones, 4. go back to 1.

Importantly, the large bulk of the hiring happens around those post-raise points, when there is a couple years of runway. And the idea of startups is to be ambitious and forward-looking, not myopically churning on short term features.

I would submit that it's even more important for startups to be focused on investing in the right team during those scale-up periods, because many of those people are going to be the leaders during the next round. You want people who are going to be strong stewards of your business as it grows, not just people who see themselves as "react devs" or whatever.

> Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

All this stuff is the same as learning the details of the language. Once you know the pattern it’s not hard to use it in a context with incidental differences in details. It’s usually more than days, but can easily be weeks or months — it depends on how well you really know the patterns. If you really know them it is just days.

But being hired is a completely different thing. Hiring managers (1) don’t understand any of this, generally; and (2) in any case, have no way to directly determine whether a candidate really knows all the relevant patterns. They use past direct experience with the technology as an approximation (a pretty poor one, but it’s easy).

Personally, I’ve done many jobs successfully on stacks I didn’t have previous experience with, almost always as lead or sole. But of course, I got these jobs through people who know me, not a random hiring manager.

(BTW, the skills most important for a lead/architect type have nothing to do with specific technologies. You’re making sure the project/team/product/business doesn’t run into dead ends and progresses efficiently, daily, in the short term, the medium term, and the long term, and balancing their conflicting needs. Probably less than half of this is tech at all.)

My job as a lead was three fold and from my recent interviewing based on the jobs I’m currently looking at it’s the same (cloud+app dev)

1. Working with external/internal stakeholders to define business outcomes and deal with ambiguity and doing project management - from my experience at AWS (ProServe) you can be really good at this with hardly any technical proficiency

2. Determining what is the right service or combination of services to use and the overall architectural design. I could do this without any specific platform knowledge - I know what type of database I need. I know I need a messaging bus. I know the trade offs of different types of technologies.

I was able to go from never opening the AWS console to working at AWS in the cloud consulting department within 2 years. But I sucked during those two years while I was learning the ropes.

3. Using the “right” one of the literally 100+ services and being able to mentor junior consultants and help them troubleshoot complex issues.

The 3rd bullet point is where you need someone who has the specific skillset.

My experience at the second bullet point is the downside of hiring someone based on “potential”. The CTO who hired me threw me at the cloud initiatives without experience and let me figure it out. But paid me $30K less than he would have had to pay someone with experience. He would have never been able to push through the 20%+ raise I would have been looking for when I left 2 years later if I had stayed on that side of enterprise dev/BigTech compensation side.

He definitely couldn’t push through the 50% raise I ended up getting at BigTech.

Now that I did my bid and the pay/bullshit ratio is going too much in the wrong direction, I can go back to my former company (since been acquired) and ask for about the same I would have been asking for three years ago (a lot less than I was making at BigTech)

I’m a senior dev, having coded commercially for 20 years now, and I think you are correct.

In my time, I have been an embedded C developer, a kernel developer, MFC C++, then J2EE, then Mobile C# .NET, then Python we dev, Python DS, Python Scientific, DevOps, WebDev

These aren’t trivial projects, but entire systems, E.g. I solo built https://atomictessellator.com just to scratch my own itch learning quantum chemistry simulators.

I think you are 100% right, at about the 10-15 year mark learning new languages and tooling really is a matter of days, maybe a week if the tooling is very different. That’s 1 week from no experience in a language to “employable, productive member of a team”

At some point it all just clicks, I suspect the people above who are disagreeing and likely devs with maybe only 5-6 years experience who this hasn’t happened for yet.

Were you able to mentor juniors in best practices and see the foot guns that could happen based on your experience?

BTW, I’m using the definition of senior developer as defined by large tech companies - the whole “scope”, “impact”, “dealing with ambiguity”, “leading initiatives” metrics not “I code really well”.

My experience on the enterprise dev side (1996-2020 and going back on that side now), is that titles mean very little outside of tech companies with leveling guidelines.

BTW, the last time I had only six years of professional experience was 2002.

The last time I only had six years of programming experience was 1992. By then I had done assembly language programming as hobby on four architectures (65C02, 68K, PPC and x86)

> Are you going to hire me to lead a team working on a 10 year old complicated Java app when all of my “enterprise” experience is in the .Net ecosystem?

Yes. The skills are fungible.

While that might be the 'right' answer, it's also in the minority for many job openings/postings.

Yep, this is true. But that just means that it's something of a super power for organizations that don't make this myopic mistake.

You're not wrong, but thankfully job openings are more fungible than ever too, with remote positions open at plenty of companies that won't make that particular (not-)hiring mistake.

Remote positions make it easier not harder to find someone with the skills fit that a company needs and makes any position more competitive.

When companies were looking for “a C# developer who knew the latest front end framework who was willing to commute to the office in midtown Atlanta” the pool was a lot smaller than “someone legally allowed to work in the US”

Actually it is more like legally to work anywhere, for some kind of positions.

And I would be a horrible hire to lead a team where I’m expected to mentor junior developers on best practices, which packages to use, how best to work with technical debt, etc.

In the real world, I’m interviewing for positions where they are looking for leads at cloud consulting companies who can mentor juniors and that they can put in front of customers for recommendations, estimating statements of work for implementations on AWS and it’s specializing in application development where you are integrating with AWS services. I have lots of experience with most things AWS.

No one should hire me to do the same for either Azure or GCP. Sure I could do the initial discovery, pre-sales, needs analysis, business outcomes, etc. But I wouldn’t have a clue about what services to use and i definitely couldn’t mentor and help troubleshoot implementations on Azure or GCP.

How hard is it to find a few mainstream opensource projects and emulate what they're doing in a given language when it comes to packaging and best practices?

Other than awful, unsuitable for production languages like ruby.

Most open source solutions are meant to be building blocks for larger projects. It’s up to you to know what’s best for your organization based on prior experience. If you’re not in the C# ecosystem would you know how badly you are shooting yourself in the foot using Entity Framework when you should be using Dapper (a micro ORM invented and used by Stack Exchange)?

On the other hand, would you know the limitations of Dapper until your system grew and you found out that you really needed EF but because you didn’t know the tradeoffs you didn’t know what to look out for?

I don't write crud apps, but if I did, I'm sure I could sort out which ORM is the right one for my usecase.

“I don’t have any experience that is relevant to most of the 2.7 million developers. But I’m sure about my opinions”

Right. You have experience doing what everyone else does, aka, replaceable.

Everyone is replaceable. If you get hit by a bus tomorrow your company will have an open req for your position before your body gets cold.

They will send your next of kin “thoughts and prayers” and you will soon only be remembered when someone sees your name while doing a “git blame”

A less morbid example, what I call the “are you replaceable test”. Can you can hit on your boss’s spouse repeatedly at the Christmas party and have a job the next year?

> Other than awful, unsuitable for production languages like ruby.

GitHub, Discourse, and Basecamp would like to have a few words with you.

Your hyperbolic comment is not far from reality when applied correctly.

I've long said, and would stand by: Programming/Development is logic; learn logic. Languages are just syntax; if you understand logic, you _can_ learn the syntax.

Taking concepts from one language to another shouldn't be an onerous task.

Of course, none of that means you'll get that _senior_ language -focused position, or any particular position at all.

But let's not act like picking up a new language, for a developer, is the equivalent of switching from development to medical practices, or even networking/system administration/etc.

The first language I used professionally was C and I programmed console apps on DEC VAX and Stratus VOS mainframes. All I really needed to know was standard C.

Guess how long the learning curve was at my next job where I had the learn the intricacies of Win32/MFC, COM and DCOM, when to use which of the 8 different methods that Microsoft had of defining a string and how to safely convert between them, why my C++/ATL COM object kept crashing the other developers VB apps because I wasn’t doing reference counters correctly…

I think GPs approach works for junior roles where learning on the job is acceptable. You're right that it would create pain for everyone if the lead/senior guy is having daily struggle sessions as opposed to taking the work to the next level.

>Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

No, but you probably can in 6 months. Whereas if you hadn't even touched any language and UI framework before, it would have taken you a few years.

Does it have to happen "in a few days" to matter? Or the hyperbole is to argue that past experience with different languages and their concepts, and SDKs and their architecture doesn't help going forward, because each of them is some kind of unique snowflake?

How much similarity do you think there is between modern Android and C# Compact framework in 2008? The last time I did any “mobile development”?

Note how the parent said: "As software developers we learn technologies for breakfast. We learn them, and then we forget them. We recollect the wisdom gained and apply it in our next gig using a different technology".

If you havent' done that with any technology for a full 15 years in some domain, and so can't adapt to the current framework used quickly, it's not like this refutes the parent's comment.

The parent described a situation where you serially learn new technologies and move on, which means there's a lot of concepts that transfer fine, and things that gradually change that you can more easily pick up in much smaller time. If you had done Android development in 2018, it wouldn't be that different to 2023.

> I can become an efficient Android developer “in a few days”.

I'll wager that you can't. Android development is Kotlin nowadays with Jetpack Compose.

Efficient, hardly. Not "in a few days"

>>Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

You can become whatever you want to become. Hiring is a totally different thing altogether.

Did A for B years is how you get hired. Not what you can do.

It's one thing knowing the language, it's another being productive with the ecosystem.

One takes between a few days and a few months. The other is a few years, unless you get pro training.

I guarantee most people starting with Python from another language will be productive quickly. But they will curse the packaging ecosystem because they will follow a lot of tutorials that don't follow this:

https://bitecode.substack.com/p/why-not-tell-people-to-simpl...

And they'll get screwed.

They will have a hard time learning this:

https://www.bitecode.dev/p/relieving-your-python-packaging-p...

It will take a long time of trials and errors, suffering all the way.

And this is true for many other aspects: good editor config, good web deployment story, good app sharing system, good tooling setup, etc

A runtime or a stlib is quite small and stable. But an ecosystem is gigantic and moving.

Yeah I learned Ruby on Rails very quickly a long time ago, it's probably one of the most accessible frameworks to learn, but it took me years to master all the weird quirks, dev environment stuff, debugging, production deployment etc. Plus from all the years doing it I'm familiar with all the old libraries so when you join a company with a large legacy code base, which at this point is very common for rails, I don't have to spend forever learning the details of some 7yr old implentation no one uses anymore.

Working with senior devs who have only been doing it for 1-2yrs is where you see the small productivity differences that aren't simply being a newbie programmer.

You're seriously arguing that someone with general knowledge of programming is going to get hard-stuck not knowing specifics of a language you and thousands of others have blogposted about for years, while linking your own posts?

Let's be real here. What percentage of companies are in dire need of 'experienced [language] programmers' who know these specifics that haven't already been set by previous devs or have another developer present to make the decisions? That's a tiny, tiny percentage of the entire job market, with much of the demand coming from companies with incredibly shaky foundations.

Almost the entirety of this is a luxury problem put on the individual. The moment the job market says they can't demand it anymore, they won't.

Yes.

Last week I talked with a guy who was pitching to rewrite their entire product in another language because he never heard of python GIS ecoshst and was doing spatial calculations by hand. Would cost hundred of thousand euros.

The HN bubble strikes again.

I don’t agree at all. I was productive within a month in a completely new language and stack at my current job for example. Once you know a few inside out, it’s just pattern matching with some Googling of “what’s X in Y language”.

Extremely deep knowledge of a language is very rarely needed, even when it is as long as you can somewhat vocalize the problem it’s just debugging

Indeed, I talk about lots of stuff, as an old dev that has been through lot of stuff.

However if I need to do quiz, or coding exercise, closed book style, only Java and C#, to a lesser extent C++, would be a viable option for me.

I agree, but unfortunately hiring managers, recruiter etc. don't think like this. If you happen to find a person that is tech-savy, they can asses your true skillsets and capabilitiy of solving problems. Hiring managers and recruiter match buzzwords in your CV.

I recently got rejected for a project from an agency (am a contractor) because I did not have provable skills or knowledge in "CI/CD". Stupid me, made the mistake of putting extensive details about creating build and deployment pipelines with Travis, GitLab, GitHub Actions, Azure Pipelines for each past project going back to 2012, but did not specify the right buzzword "CI/CD" for the recruiter...

> Hiring managers and recruiter match buzzwords in your CV

So? You put those buzzwords in your CV. What’s difficult about that? You feel like being dishonest? If so, again, just explain in the next stage of the interview (with real engineers) that you do have real world experience in similar but not exactly the same technologies listed in your CV. You just did so to pass through HR. Not a big deal (as long as you’re confident and believe you can learn technologies easily)

Blatantly lying on the CV is an instant rejection at the places I've worked. It's one thing to stretch your contributions on past projects, but to outright lie about the technologies used is a huge red flag. It's easy to teach a person the company tech stack, but I'm not sure it's possible (or worthwhile) to try and teach some one to be honest.

You don't need to make up projects you worked on with the technology, you can just add it to your list of skills.

I would assume the problem comes up the next time his CV gets rejected for not having "Continuous Integration" on it.

I have made some "SEO" optimizations as some agencies use text-based CV matching. Some are upfront with it, with others I observe it because I get a lot of Java project requests (I never coded Java, but as a FE dev, have lots of JavaScript in my CV text).

I'm gladly looking forward 3-5 years, when AI will handle this CV analysis and match a project description from a company to a proper candidate. Basic GPT can tell right now if CI/CD matches "Azure Pipelines". Then we can fire the lower 50-80% of unskilled recruiters that do not provide any value to the market right now.

Absolutely, I feel I could be employed tomorrow in a language or stack that I haven’t even heard of and start being productive by the end of the week!

I seriously think you owe it to yourself to practice learning something new every week. It often takes one afternoon to get a “taste” and small side project to get beyond that.

Every programming language. Is literally just a template for instructions, and every technology just an abstraction over some crud somewhere.

So could you be a productive iOS/Android developer in a week with no previous experience?

My experience is that learning a new language -at a basic level- can be done quickly (like a couple of weeks, not days).

But learning it at an advanced level, is a whole different matter.

I've been writing Swift since, literally, a few hours after it was announced, in 2014. I write Swift every day (like, seven days a week), and have been, since that first day.

I feel as if I have only had "mastery" of the language for the last couple of years. There's still plenty for me to learn, and they keep adding more stuff.

But the language isn't the big deal. The deal for me, is the fundamental SDK/API/Framework. That has been an ongoing project since 1986. As soon as I learn one API, they change it up (and sometimes, the entire OS).

During that time, I've written in 68K ASM, Pascal, Object Pascal, C, C+- (the weird THINK C variant), C++. ObjC, and Swift. I've worked with MacApp, OpenDoc(!), Think Libraries (Pascal and C), PowerPlant, and Cocoa (and its expression in iOS, WatchOS, AppKit, and TVOS).

I've always considered hiring folks to be an investment. As a manager, I always looked for folks that had the fundamentals down, and assumed that I could train them into what we need. Most of the work we did, was way beyond anything you'd find in textbooks. I was under no illusion that I could hire folks that would be able to start on it right away.

That was why my team was always one that I wanted to keep whole and cohesive, over many years. I can't even imagine today's 18-month engineer lifetime. I kept my engineers for many years, and that wasn't easy.

I just said something similar in another reply

https://news.ycombinator.com/item?id=37099395

But as far as employees being an “investment” let’s look at things from the employee side.

For context: these numbers I’m about to cite are correct to within a first approximation on the “enterprise dev” side where most of the 2.7 million developers work and in most major cities in the US that are not on the west coast or in NYC

Let’s say you hire a Junior/mid level developer and offer them $100K which is fair knowing they are going to do “negative work” for the first few months as an investment. Two years later, they have experience and now can apply for companies that are looking for experienced iOS developers. Their market rate shot up to $135k.

Because of salary compression and inversion, you’re not going to be able to pay them 35% more in two years because of HR policies. Yet you can bring in new experienced iOS developers at market rate. If he’s smart your employee is going to jump ship, wasting a lot of your “investment”.

As a hiring manager, knowing that statistically I’m only going to get two years out of an employee, why wouldn’t I just poach the person you just trained and pay them the $135K you couldn’t?

Another scenario is that now that developer has been reading r/cscareerquestions and decided to “grind leetcode and work for a FAANG”. Now he’s looking at $200K+ as a mid level developer adding yet more bloat to the Facebook app.

You couldn’t compete with that if you wanted to.

> You couldn’t compete with that if you wanted to.

Unfortunately, I was forced to.

My company was one that paid “competitive” salaries.

That’s code for “below average.”

This filtered out 90% of applicants, right there.

So the ones that applied, did so, out of genuine interest in the company and the technology (we were a “marquee” company).

I was forced to look for “diamonds in the rough,” and became fairly good at evaluating whether or not someone could handle the tech and the learning.

I kept them, by being a really good manager. I treated them with respect, didn’t burn them out, and shielded them from a lot of the corporate BS. They appreciated that, and stayed.

When our team was finally rolled up, after just short of 27 years, the employee with the least tenure had ten years. These were seasoned C++ image processing professionals.

Most of those 2.7 million developers I spoke about will never make low end FAANG money and that’s perfectly fine.

I had my first house built in the burbs of Atlanta in 2002 making $60k (2500 square feet) and my second house built in the northern burbs (3200 square feet) making $135K in 2016 [1].

I only fell into a remote role at BigTech in 2020 at 46 years old after declining a chance to interview for a software development position and being offered a chance to interview for a position in the Professional Services division doing cloud consulting [2].

I was perfectly happy living the upper middle class lifestyle in 2020 making only $150k with my wife making $20K working part time.

In fact, I’m excited to get back to working at small companies on the high end of enterprise dev comp because my department became too “Amazonian” this year and my shit tolerance level is extremely low.

[1] 2002-2012 was a decade of bad life and career decisions that I didn’t recover from completely until 2018.

[2] I did my bid, saved money and paid off debt and our bills are actually $1000+ lower per month now than they were when I started.

> you’re not going to be able to pay them 35% more in two years because of HR policies

Seems like you just identified the issue. You're right, of course, that the "invest in employees" approach doesn't work at companies that have a corporate policy to not invest in employees.

Investing in employees is a top-down strategy, not a bottom-up one. If there isn't support for it at the top, then you're right, it won't work.

And it’s not just smaller companies - my experience of n=1 at BigTech companies is that to get ahead, it’s best to “boomerang”.

Besides even at BigTech, it’s much easier to get a higher level position at another comparable company than go through the promotion process.

I think all the "a few days" and "a week" stuff that generates these kinds of debate is a total red herring. Yes, it's hyperbole. But it's also true that people with experience successfully applying a bunch of different technologies are great hires onto a team using a technology they don't yet know. It's just a process measured in months rather than days. But if you need to hire someone because you have something that needs to get done this week, then you've already screwed up.

And then it gets back to my other argument. Are you going to pay someone the same that doesn’t fit your technical needs as you would someone who does? If you pay them less, are your raise policies going to allow you to get them to market value once they do have the skillset or are they going to end up job hopping?

Personally, I would not take this into consideration when deciding how much to pay people.

I recognize that there are a lot of different niches in our industry, and presumably in some of those niches this narrow focus on what technology is being used makes sense, but that hasn't been my experience.

In my experience, you want people who are both pragmatic and flexible about learning, evaluating, choosing, and teaching others new tools.

I do recognize this may be a somewhat privileged view. I think I've been fortunate to spend my career in organizations where software is the profit center rather than a cost center supporting the rest of the business. My experience is that these companies have focused their hiring, compensation, and performance expectations on fundamentals and figure-it-out-itude rather than any specific technology stack.

Not iOS, but I'm fairly confident I could be productive in an Android codebase in a week.

The only reason I don't think I could do iOS is because I'd need to use a OSX, and I think it would take me longer to become productive in OSX.

It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure.

I did a trial week before joining my current gig full-time. I had pretty much no typescript experience, came into a large TS react/nodejs app and had a pull request on the 2nd day for a new feature.

I wouldn't try to work on a Haskell or OCaml codebase, they are different enough that I'm not confident I could pick them up quickly. But most mainstream languages are similar enough that it really shouldn't be that hard to pick them up and be productive.

As someone that has done on and off Android programming as hobby since NDK was introduced in Android 2.2, and regularly follows ADB Podcast, I doubt it.

Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.

I think it really depends on what your definition of "productive" is.

Let me try and quantify it. I looked through my apps that I installed from F-Droid, then looked at their GitHub issues and picked one [0]. I bet I could implement that in less than a week with 0 Android development experience.

> Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.

Does any of that really matter if you're hiring someone into an existing org? Doesn't Android have amazing backwards compatibility? I'm sure I have some dice app from 2012 that still runs. The company is probably targeting some version of Android and isn't changing to the latest one every time a new version is released.

[0] https://github.com/tasks/tasks/issues/2435

Are you trying to find a job as a journeyman developer (nothing wrong with that) or are you trying to lead a team or be a senior where you are expected to be productive from day one and maybe mentor developers and be more strategic?

Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?

If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android.

I mean, in this hypothetical scenario, I've decided that I want a job as an Android developer. So I would take my own time to learn Android whilst interviewing. By the time I got a job, I'm confident I'd hit the ground running.

I wouldn't try to apply for a job to lead an Android team without at least working in one first. I'm sure some people do, but I'm not that confident ;).

> Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?

I wouldn't hire you because you don't sound like you think you could do it.

If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.

> If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android

I can say I’m a little teapot. But without demonstrated experience, why would you hire me over one of the million developers with experience and have at least shipped an app?

> If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.

Yes because “positive thoughts” without experience means you can be effective

Already with that response you have proved not to understand the Android ecosystem.

No it doesn't have an amazing backwards compatibility, specially depending on what is cool in one Google IO, and already legacy in the new one, without replacement, like e.g. Tango, Sceneform, Fragments.

There are policy rules how old an Android app is allowed to be in Play Store.

I don't care what platform you are targeting: unless the entire purpose of your product is to take advantage of the feature (which is sometimes fair), you never ever ever EVER integrate whatever is "cool" from the latest keynote.

Regardless, while Android requires you to compile new apps with the latest toolchains to release, and you might have to update some stuff in your manifest, they do not force you to use new APIs, they do not require you to stop supporting old versions of Android, and I've seldom run into a backwards compatibility issue that wasn't some corner case involving the weird intents we have to use (as our app relies on being a VPN).

Time to acquaint yourself with Play Store policies and what should be the minimum API version for uploading new app versions, which do force to use new APIs, that is the whole point behind it.

Here have a go at it, https://support.google.com/googleplay/android-developer/answ...

Besides the whole Android example, was just that, I can give several examples of technology stacks where having a passable knowledgeable of a programming language, without the associated frameworks that are being used in the company, makes the candidates a no hire, unless they really excel themselves at the interview, assuming HR even cares to call them in.

sigh, look again: you have mixed up "target" with "min" :/. This is a critical distinction that you can't just gloss over: you simply are NOT forced to use new APIs just because you bumped the target... at build time it might activate the ability to choose to use some new APIs if you want to, but the biggest effect it has is at runtime to affect the various subtle--and extremely limited--backwards compatibility behaviors I mentioned (similar to how iOS uses the version of UIKit you linked your app against) which tend to mostly limit specific scenarios where security issues or bugs were found in older designs.

FWIW, I am seriously the build engineer for an Android app distributed in the Play Store (and have maintained apps for Android since the platform launched and it was still called the Android Market), and I'm telling you: you are not just wrong, you are being loudly wrong... not just about this (where the wrongness frankly feels egregious at this point), but your entire point: I have taught classes at the university level on how to rapidly pick up programming environments, and the lead UI developer I hired for our company had almost no experience in the toolkit we are using before we hired him and he's doing fine with it.

I might stand corrected on the Android example.

As of the rest, in most companies I worked on, unless the higher ups are bypassing the hiring process, due to networking and acquaintances, such CVs never get through HR first round of filters.

>There are policy rules how old an Android app is allowed to be in Play Store.

yup, but we're not talking about new feature to removed in 2 years level of radical changes. It's still something coporate uses and coporate doesn't latch on every cool feature.

You can probably expect your newest API app to work in 5 years if you don't touch it. You probably can NOT expect it to work in 10 years. That just means you need to make sure you're never 3+ years behind on using deprecated features.

> It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure.

As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?

And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.

> As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?

I dislike the whole Agile stories/points/sprints thing, so probably not those jobs. But if you're asking if I'm applying to jobs where I write code, then yep! I love writing code and building things.

> And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.

I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.

I setup the base of the application and sorted out the routing, state management and abstractions for dealing with our data. But they were writing views and features after a week pretty well. I had to point out some performance issues in code reviews but that was mainly it.

> I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.

It depends on your definition of “production”. I got a couple of developers who had spent a decade+ supporting a PowerBuilder app and writing stored procedures.

Their C# code was a horrible mess.

My former CTO (55 years old and his idea of research was coding POCs - smart guy), said he wouldn’t hire “old people” any more to do front end work because their front end designs weren’t as good as people who started out doing front end work and have been doing it for years.

All of his back end developers/architects were older.

If your resume shows you job hop regularly, then I’m going to want you to be productive very quickly.

If your resume gives me the impression that you are likely to still be working here for enough years, then I’ll give you time to get up to speed. If you were a really great front end developer in 2015, I suspect you can figure out Typescript/React.

I sucked back then too at front end development :).

I knew enough to copy/paste/pattern match an existing page and make the necessary change. But you start me with a blank slate and give me a mock-up, I would end up using tables and frames like it’s 1999.

You could be productive in a not-so complicated Android codebase in a week.

During Covid I had a colleague, mainly web/js/angular dev, join the Android team. It was a new project to him, so he had 0 idea of the business problems, flows, etc.

In a timeframe of 1-2 weeks he was making PRs. It needed quite some reviews from me, usually because he didn't know about "how it should behave" on Android, or what the best practices were in terms of using Kotlin or following our architecture. After 2-3 months he was as proficient coding as I basically (but we all know, coding is 50%).

i did this with php and python in two different jobs. i had very little php experience and never worked with any php framework before, but the team i was in consisted mostly of junior developers, so i ended up writing better code than any of them except the team lead. laravel was also very easy to understand.

at another job i started with only some rudimentary python experience. they had an inhouse framework, so being deeply familiar with python frameworks and libraries would not have even helped me. they knew i had experience in other languages and it worked out pretty well.

most recently i had an interview where it was very clear that i haven't done any work on go before. at least during the interview that was not an issue. after the interview they wanted me to send them code examples of previous work. i didn't get the job, but i don't think lack of go experience was the problem.

Clearly you read my response and felt some doubt

>don’t buy it. As software developers we learn technologies for breakfast.

This is such a funny mantra. Okay learn how nuclear fission works. Or EUV lithography. Or power transmission across superconductors. All of these are extant, commercial, technologies (yes even the last one). Too much? How about something more pedestrian like overhead cams and electric fuel injection? Too far afield? Okay learn how DMA works on a GPU - not how to call `copy(host, device)` but what actually happens and more importantly why.

The truth is software developers learn APIs, not technologies (and not over breakfast either). Point being, it's not good to be haughty because if tomorrow you were out of a job and the only place hiring was the Ford motor plant I think you'd be just as fucked as the author of the post.

As software developers we learn software technologies for breakfast, not entire industrial processes...

You're just arguing semantics. And the example given can go the other way: if your Ford motor plant closes and the only places hiring are software shops, you'd also be "fucked".

> You're just arguing semantics

I never have any clue what this retort means: when exactly are semantics (the meanings of things) not important?

> Ford motor plant closes and the only places hiring are software shops, you'd also be "fucked".

That's one hundred percent true but the difference is I don't see assembly plant workers going around claiming they learn technologies for breakfast (or lunch or dinner).

>when exactly are semantics (the meanings of things) not important?

arguing over meanings when we should understand the meanings tends to mean you're nitpicking instead of clarifying. There's clarification and then there's bike shedding.

> As software developers we learn technologies for breakfast. ... > I have worked for years with PHP, Apache, Ansible and MySQL.

As much as I agree with your general sentiment that adaptation is one of our primary skills in this industry, these two statements combine to sound like parody. You “eat new technologies for breakfast” but PHP and Apache are in your short list of technologies you’ve used for years?

> And in 7 years I’ll be using something else.

And 7 years for your prediction of when you’ll be using a different technology is both oddly specific and oddly long.

Apologies if this comment actually is parody and it’s just flown over my head.

Everyone goes through this once. A lot of your knowledge suddenly aren't needed anymore because of external factors. For me it was Flash. I've seen colleges being afraid of learning new technology after being burned once. Now my skills are learning new skills.

I also did Flash for a long time. 10 years later it’s not like that experience is mostly lost. When I write typescript I get a dejavú to AS3. Plus knowledge of VMs, garbage collection and all the other programming concepts translates to most languages

"you won’t have difficulty in learning X, just take a few days in learning X"

It isn't 2020 anymore. No. No, one is going to hire someone that is going to learn "react on the fly".

I don't agree.

My really-learned language is C#

The biggest money I've made technology on is C, which I don't really know, just basics.

I've wrote some js, ts, c++, lua, used some postgres+mssql+mongo, yada yada and stuff

but when writing CV I'm not saying that I know those, just that I have experience with those. It is probably bad strategy cuz people inflate their skills, but who knows.

There's giant difference between person who "can use tech" and person who "understands to the point that he/she feels particular tech".

"Feeling" technology takes years because you need to understand its ecosystem, why some approaches to some problems are more common within this tech, historical context, internals, etc, etc.

I feel C#, but I only can use C.

Sure, but say you focused as a iOS developer you definitely cannot tell the recruiter doing Android are the same. They wont hire you if you say you have no Android experience, same thing

The probability of success is largely is based on the available supply of developers vs the demand for them. Canada’s market is ok, but not great which is probably why so many Canadian programmers immigrated south.

Oh come on. Language specific knowledge is a game changer in programming speed & efficiency. Likewise the level of effort to understand modern React concepts has gone way up.

Deep React specialization is a great way to get most tech jobs. Some interviewers literally just want to see if you can use hooks in a solution. Applying a learners mindset in the middle of an interview comes off as amateur.

Learn the tech stack you’ll use on the job. It’ll get you tons of mid grade offers.

Reply on news.ycombinator.com