Comment by css_apologist
2 days ago
> Are Java developers just not as competent as Ruby programmers?
years ago a senior developer close to me said "when screening interviews, if i see rails i throw the resume in the trash"
so ironic how trivial/stupid these language-based judgements are
I would go so far as to say the rise of Rails and the downfall of J2EE being concurrent was not entirely accidental. I have/had no particular affiliation for Rails, but it demonstrated how to write simple, opinionated backend code, and that inspired a flurry of Java/JVM web frameworks that tried to follow a similar pattern and eventually gave us libraries like DropWizard, Javalin, SparkJava, even Spring Boot to some extent.
> years ago a senior developer close to me said
What was the senior's stack?
I’m going to assume Google Docs.
I couple of years ago I would ask to collect your coworker’s garbage bin :)
Not as easy to find in my vicinity, at least good ones, which is of course true for any language and profession in general.
I have RoR on my resume and very fond of it.
If one is looking for Java developers, it only makes sense to throw rails resumes in the trash. It will save time for both parties.
One side of my brain agrees that's a dumb way to judge anyone but then when I think about the accepted filtering mechanism they really aren't any better or any worse. You cannot interview everyone and ultimately you're looking for some combination of competence, alignment, drive and social fit. Filtering on where you worked previously or where you went to school or whether you can pass some coding challenge only partially fills in the matrix. And the size and shape of the organization can drive how much people in the hiring loop look at each data point. This senior engineer's ideal for alignment and social fit probably favored people who think like them or their department's head.
To be fair, years ago Rails was what all the "bootcamp" programmer mills were pushing. Only you have the full context, but absent of that it is likely that Rails was truly found to be associated with poor applicants. Not because of anything about Rails itself, but because of those "bootcamps" not developing quality people. The culling has to occur at some point. If you throw some great developers out with the bathwater, so be it. There isn't enough time in the day to worry about them.
Admittedly, Ruby on Rails makes me think "bootcamp" like you said, and I barely even know what it is.
But shouldn't the check just be that the candidate has used more than one different stack? It's pretty hard for anyone with real experience to stick to one, and even if they do, that's not a good sign either. Or are you saying those bootcamp people end up learning another stack but still not being very good?
> But shouldn't the check just be that the candidate has used more than one different stack?
If you had another filtering mechanism, perhaps you could do that. But what other arbitrary, legally acceptable, filter are you going to use to further narrow the search? Can't realistically throw out all the resumes with female-sounding names, for example. What is going to keep you out of trouble is quite limited.
Why not throw out all the "Rails" resumes? If you had all the time in the world you would interview every last person, of course, but in the real world, with real world constraints, you have to pick a few to interview and live with your choice.
To use the internet's favourite analogy: It's like buying a car. Most people would never find it reasonable to test-drive every single one of them. It is just too time consuming to do that. So, instead, one normally looks at signals to try and distill the choice down to a few cars to test drive. You very well might miss out on what is actually your perfect car by doing that, but if you find one that is good enough, who cares?
On the one hand, that obviously filters out many qualified candidates.
On the other, you only have so much time in the day. It'd take me 3-6 months to give phone screens to every resume that comes in the door for any one engineering role, 8x that for a full 4-hour interview. I have to filter through them somehow if it's my job to hire several people in a month.
You'll obviously start with things that are less controversial: Half of resumes are bot-spam in obvious ways [0]. Half of the remainder can easily be tossed in the circular filing bin by not having anything at all in their resume even remotely related to the core job functions [1].
You're still left with a lot of resumes, more than you're able to phone screen. What do you choose to screen on?
- "Good" schools? I personally see far too much variance in performance to want to use this as a filter, not to mention that you'd be competing even more than normal on salary with FAANG.
- Good grades? This is a better indicator IME for early-career roles, but it's still a fairly weak signal, and you also punish people who had to take time off as a caretaker or who started before they were mature enough or whatever.
- Highest degree attained? I don't know what selection bias causes this since I know a ton of extremely capable PhDs, but if anything I'd just use this to filter out PhDs at the resume screening stage given how many perform poorly in the interviews and then at work if we choose to hire them.
- Gender? Age? ... I know this happens, but please stop.
If there's a strong GitHub profile or something then you can easily pass a person forward to a screen, but it's not fair to just toss the rest of the resumes. They have a list of jobs, skills, and accomplishments, and it's your job to use those as best as possible to figure out if they're likely to come out on top after a round of interviews.
I don't have any comment on rails in particular, but for a low-level ML role there are absolutely skills I don't want to see emphasized too heavily -- not because they're bad, but because there exists some large class of people who have learned those skills and nothing else, and they dominate the candidate pool. I used to give those resumes a chance, and I can't accept 100:1 odds anymore on the phone screen turning into a full interview and hopefully an offer. It's not fair to the candidates, and I don't have time for it either.
And that's ... bad, right? I have some things I do to make it better in some ways (worse in others, but on average trying to save people time and not reject too many qualified candidates) -- pass resumes on to a (brief) written screen instead of outright rejecting them if I think they might have a chance, always give people a phone screen if they write back that I've made a mistake, revisit those filtering rules I've built up from time to time and offer phone screens anwyay, etc -- hiring still sucks on both sides of the fence though.
[0] One of my favorites is when their "experience" includes things like how they've apparently done some hyper-specific task they copy-pasted from the job description (which exists not as a skills requirement but as a description of what their future day-to-day looks like), they did it before we pioneered whatever the tech in question was, they did it at several FAANG companies, and using languages and tools those companies don't use and which didn't exist during their FAANG tenure. Maybe they just used an LLM incorrectly to touch up their resume, but when the only evidence I should interview you is a pack of bold-faced lies I'm not going to give the benefit of the doubt.
[1] And I'm not even talking about requiring specific languages or frameworks, or even having interacted with a database for a database-adjacent role. Those sorts of restrictions can often be too overbearing. Just the basics of "I need you to do complicated math and program some things that won't wake me up at night" and resumes that come in without anything suggesting they've ever done either at any level of proficiency (or even a forward or a cover letter stating why their resume appears bare-bones and they deserve a shot anyway).
Probably the other person's boss was hiring for some generalist role and not a specific thing like low-level ML.