https://www.anthropic.com/careers/jobs/5025624008 - "Research Engineer – Cybersecurity RL" - "This role blends research and engineering, requiring you to both develop novel approaches and realize them in code. Your work will include designing and implementing RL environments, conducting experiments and evaluations, delivering your work into production training runs, and collaborating with other researchers, engineers, and cybersecurity specialists across and outside Anthropic."
https://www.anthropic.com/careers/jobs/4924308008 - "Research Engineer / Research Scientist, Biology & Life Sciences" - "As a founding member of our team, you'll work at the intersection of cutting-edge AI and the biological sciences, developing rigorous methods to measure and improve model performance on complex scientific tasks."
The key trend in 2025 was a new emphasis on reinforcement learning - models are no longer just trained by dumping in a ton of scraped text, there's now a TON of work involved designing reinforcement learning loops that teach them how to do specific useful things - and designing those loops requires subject-matter expertise.
That's why they got so much better at code over the past six months - code is the perfect target for RL because you can run generated code and see if it works or not.
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?
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.
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.
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).
there’s a deeply elegant language hidden in there with unbelievable support for generic programming, however it is practically impossible to do that in a component system and the current state of CSS editors
i find it hysterical we design component libraries where the only acceptable way to extend the design of a component is add a prop when CSS has a perfectly elegant way to do this without muddying up the component source
not to mention the dark arts of encoding show/hide/position/more logic that is often done in js
it is the saving grace of the web, but never has been realized
LLMs are really showing how different programmers are from one another
i am in your camp, i get 0 satisfaction out of seeing something appear on the screen which i don't deeply understand
i want to feel the computer as i type, i've recently been toying with turning off syntax highlighting and LSPs (not for everyone), and i am surprised at the lack of distractions and feeling of craft and joy it brings me
Not GP, but he's absolutely right, it's been pissing me off for years now. Only thing I can remember off the top of my head is nested selectors still not highlighting properly. They partially fixed this a few months ago but that's it. I guess we're all waiting on GHCP to prioritize and fix it now?
I feel bad about this comment as of today's news. I love tailwind and feel like it has supercharged my ability to be productive with CSS, but recognize that it can be overprescribed.
Not OP but I remember working on a team that just put up with nonhighlighted nonintelligent CSS because it was embedded in a handlebars template. Of course there is an extension that's supposed to fix this but it was flaky and broke often. An easy fix was to move CSS to a separate file for import but that was a big change for these guys.
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.
> This makes a no-brainer "don't run these ever" option in the browser seem appealing.
Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)
to effectively critique a language you must understand the design trade offs made
reply