Live data from Hacker News

The case for language agnostic hiring

alphalist.com

91–100 of 124 posts

Re: The case for language agnostic hiring

#91
post #21

Earlier quoted context omitted.

A working dev should be well beyond the understanding of a third-year CS student. This is not "advanced" from the perspective of someone in practice, it is the requirement to get in to the practice. (I know people get programming jobs without CS degrees, but if you can do that, you can teach yourself how pointers work)

I don't have CS degree but I do have 7 years commercial experience with Python/Django Rest Framework and I have no idea how pointers work.

On top of Python's class semantics, if you understand Python's weakref class, you are about 90% of the way to pointers.

Re: The case for language agnostic hiring

#92

> Languages are ephemeral. They come and go. Is this really true? Maybe over the course of centuries, but in my lifetime I seriously doubt the major languages like C, Java, JavaScript, etc. are going to go away.

I've never seen a job ad that was just about the language. Usually there's a language a domain (i.e. AI, video, telecom), and several frameworks or applications. The language is the easy part. Frameworks and applications can be huge learning curves. Domain knowledge is really the hardest. Taking someone who's been doing database CRUD apps with Rails and React and expecting them to pick up writing video codecs in C++ is really where the reach is.

Re: The case for language agnostic hiring

#93

Elixir, Haskell et al. require concepts that are not required at all in e.g. Java. The functional programming module at my university had the highest failure rate after the math and statistics classes. Even something like C can require new concepts. I was a tutor for a university C programming course and students that had no problems with Java struggled hard with direct memory manipulation, pointer arithmetic etc., b…

I respectfully disagree. I think CS students struggle with this because they have a general lack of experience rather than a specific lack. I've found that I pick up "new" concepts like functional programming easier now than in college. I chalk this up to being able to link like concepts in the brain as you learn and are exposed to more post-college. New concepts aren't usually completely novel or original. Chances are it's going to be based on something to which I've been at least tangentially exposed to in my career.

Re: The case for language agnostic hiring

#94

Earlier quoted context omitted.

Yes.

Without using their free time?

Depends on the company. Where I work, the answer is yes. Work/life balance is heavily stressed, which has been a surprise. However, when I started my career, it was with the expectation that staying up to date with technology would require some personal time. I don't personally know anyone that didn't start a technical career without that expectation.

Re: The case for language agnostic hiring

#95

When a company I'm interviewing for a role at is quoting Uncle Bob, that is a huge red flag for me.

Was wondering where this comment was. Yep yep yep. He's a very good salesperson (which is not a negative!) but definitely not worth listening to as a developer.

Re: The case for language agnostic hiring

#96
If you only know one language you're a technician, not a programmer. If you only know one paradigm of languages you're a technician, not a programmer.

If that sounds harsh to you or you have some sort of negative emotional reaction to that then you're way too personally invested and should probably go have some tea or a little lie down.

There's nothing wrong with being a technician. It's a useful and valuable role.

The confusion between programmers and technicians, though, leads to a lot of wasted time and effort. If you hire a technician when you really need a programmer you're gonna have a bad time. If you hire a programmer when all you really need is a technician they will eventually leave (if you're lucky the technicians you hire to replace them will be able to understand what they wrote.)

Because of all the confusion, it's possible to hire young and inexperienced programmers and pay them and treat them like technicians, but it can be tricky to differentiate them. (The big FAANG outfits just hire everybody and only promote the programmers, but you probably can't afford to do that.)

Re: The case for language agnostic hiring

#97

Elixir, Haskell et al. require concepts that are not required at all in e.g. Java. The functional programming module at my university had the highest failure rate after the math and statistics classes. Even something like C can require new concepts. I was a tutor for a university C programming course and students that had no problems with Java struggled hard with direct memory manipulation, pointer arithmetic etc., b…

If you only know java are you even a real (professional) dev? I'd expect any dev wanting a job using a language he doesn't know to have some understanding all of the concepts you're talking about. It's not language specific, it's just the basics of programming.

I'm inclined to agree with you. A JVM-based developer with no idea of Scala or at least Kotlin raises questions. But in the last year I have worked with at least one smart guy/productive developer who is not into either. So YMMV I guess..

Re: The case for language agnostic hiring

#98
post #64
post #36

Earlier quoted context omitted.

How about "you have some knowledge of stack X and you are committed to learn that particular stack and finding joy in using it"?

That's the happy case, yes. But now hiring is a competitive process, and you need criteria to compare candidates. Once you eliminate leetcode, and also eliminate biases related to candidate's class and background what you're left with? You'll have to compare how close their experiences are to the job they want. Still better than considering lack of experience with technology X a deal breaker of course

at one company I was passed off to another team because although I wrote a correct solution immediately to some nontrivial problem in their preferred language, C++, I wrote it in a C-like style instead of using their preferred subset of C++ features (probably this aligns pretty closely with what most people mean when they say "modern C++", which I admitted prior to the interview that I had basically never used because my C++ experience predated a lot of these features).

Re: The case for language agnostic hiring

#99
post #35

>You might be looking for a specialist but you don’t want to attract people who are only interested in particular languages. Because that person’s narrow focus will hinder their growth. Exactly what I have been witness to was this taken to the test. Result: * You hire devs who do not like (or worse: hate) working in the language of the shop. They scold at the application they have to maintain and run, they do not con…

Announcing some position as "we want software developers with $qualifications to work mainly on our PHP backend" is completely different from "we want software developers with 5 years of experience with PHP".

Also, you don't promote people for non-valuable rewriting of stuff.

Re: The case for language agnostic hiring

#100
post #28

I agree to an extent. A good software engineer should understand the fundamentals and be able to adapt to most environments. Unless... your team is doing something very unusual. I like to think of it as a professional sports team (let's say basketball). If you have a chance to sign a skilled player who is an all-star, 7 feet tall, and can hit 3 pointers you sign him and it will probably work out!

In a football team, if you sign a fantastic player and you place them in a position where they can't thrive, they will leave after a counterproductive year. There are plenty of historical examples of it... Just imagine Neymar playing as a center back ;) The same happens if you hire a C developer for a Node.js gig, game developer for writing a mobile app, or someone who's been building React design systems all their l…

I would probably hire game developers for basically any role. The nature of the industry causes a large portion game devs to be deeply familiar with many more broadly applicable areas of specialization than is normal, able to produce several times more working code per unit time than web companies will expect from anyone without "staff" or "fellow" in their title, dramatically less likely to ship things that make the user wait half a second constantly or have other forms of nightmarish UX, and used to working inhumane hours for vastly below market compensation. Wow.
Post reply on HN