In your experience, what’s the best way to increase signal? I feel as though a lot of devs struggle with the initial process of getting past screening, drawing attention to projects, etc.
Not the parent commenter but I've performed a lot of resume reviews for people and also done a lot of hiring.
Most resumes are not very good. Beyond the obvious problems like typos, there is a lot of bad advice on the internet that turns resumes into useless noise. Screen a lot of resumes and you'll get tired of seeing "Boosted revenue by 23% by decreasing deploy times by 64%." This communicates nothing useful and we all know that revenue going up 23% YoY was not attributable to this single programmer doing anything at all.
Often I'll get candidates into interviews and they light up telling me about impressive things they did at a past job with enough detail to convince me they know the subject, but their resumes are garbage because they've followed too many influencers.
So try to work on your resume first. Try different resumes. Rewrite it and see what makes interviewers take notice and what they ignore. The most common mistake is to write a resume once and then spam it to 100 jobs. I know it's not fun to change the resume or invest time into applying for a job that may not respond, but you know what else isn't fun? Applying to 100 jobs and not getting any responses because every hiring manager has 20 tailored resumes in their inbox ahead of yours.
Having a simple but clear LinkedIn profile helps. Many scoff at this, but it works. You don't have to read LinkedIn's social media feed or do anything with the site. Just set it up and leave it for them to find.
GitHub portfolios and other things have low relative value at most companies. There are some exceptions where someone will look at it and it might tip the balance in your favor, but it's a small optimization. You need to be perfect the resume first, get a LinkedIn that looks decent second, and only then think about the ancillary things.
> Screen a lot of resumes and you'll get tired of seeing "Boosted revenue by 23% by decreasing deploy times by 64%." This communicates nothing useful and we all know that revenue going up 23% YoY was not attributable to this single programmer doing anything at all.
This is the "quantify everything" mantra career coaches have been repeating for decades. As the story goes, no company is going to care that you refactored the FooBar library in order to make bugs in the DingDang module easier to fix. You have to only write down things that moved some quantifiable business needle like revenue or signups, even if the link to that needle is tenuous. Obviously, this ends up penalizing hard working, talented devs who don't happen to be working in areas where wins are easily quantifiable.
Some quantification is very helpful. We're going to have a very different conversation if the architecture you built was serving 1 million users as opposed to 1000 customers.
It's the useless quantification that turns resumes into noise, combined with making claims that you changed revenue by yourself.
> You have to only write down things that moved some quantifiable business needle like revenue or signups, even if the link to that needle is tenuous. Obviously, this ends up penalizing hard working, talented devs who don't happen to be working in areas where wins are easily quantifiable.
Every hiring manager knows this game and sees right through it. You can't read 1000 resumes with claims of "Increased revenue by 13% by" followed by something that clearly was not the reason revenue increased 13% to become numb to it.
Nobody believes these.
The somewhat useful quantifications are things like "Reduced cloud spend by 50% by implementing caching". This can spark a conversation about how they diagnosed they issue, made a transition plan, ensured it was working, and all of the other things we want to hear about.
At least in my experience, applying at jobs online has been entirely useless for the last 5 years. No company ever contacts you after using the online application forms. And the only way I’ve got interviews is from recruiters contacting me.
As someone applying right now I agree. I think I've had one company out of dozens get back to me on a cold application this year. Every contact that has led to an interview was from being referred in by a current employee, or a LinkedIn recruiter reaching out to me about a job. I assume the application forms get spammed with hundreds if not thousands of applicants. It's hard to blame someone for not wanting to sift through all that muck when there's already a stream of vetted candidates coming in from their recruiter. Sucks for the job seekers, though.
I'm putting more time into cleaning up my LinkedIn profile since that's been my most reliable route into hiring pipelines (other than referrals and networking).
I assume online forms are spammed with thousands of AI generated resumes now. The only reason I apply is it seems to flag your account as active which triggers recruiters to contact me.
My experience recently was something like 2/3 from referrals (the third I think will eventually get back to me but way too slow), and something like 3/10 from cold applications. Obviously big differences depending on location and experience but I was pleasantly surprised that some of the cold applications went somewhere.
> Most resumes are not very good. Beyond the obvious problems like typos ...
This is a person who you're going to be reviewing their code or reading the documentation that they write.
If there are typos and poor formatting in the resume (that they've had the leisure of reviewing themselves and correcting), what does this say about the quality of the code the code or documentation that they're going to write when under a time constraint?
Are you going to be faced with the decision of having code with variables that have spelling errors and documentation that is grammatically or factually incorrect go through because of the time pressure?
The resume itself is a demonstration of the applicant's ability to pay attention to the details that matter in software development without showing a single line of NDAed code.
Woah, I had this exact idea, down to the tunneling and local machine! I basically just coded up a Tailscale + caffeinate harness for my agents and it's been working super well. Your UI looks great though, glad to see more players in this space!
I’m new to CRDTs, but could we clean up tombstones if all replicas acknowledge? Not too sure, but could we persist snapshots of state at certain “compaction” points?
You can do this by (1) extending your CRDT into a CTM (see https://braid.org/time-machines) and then (2) use the antimatter algorithm (braid.org/antimatter), or something similar, for acknowledgements.
The antimatter algorithm allows peers to learn where the rest of the network has caught up to, without a central actor, or relying on consensus, across arbitrary P2P connection & disconnection events in the network. It even allows subnetworks, after a partition, to prune the history that they generate while partitioned, while still holding onto the necessary older history to reconnect with the other half of the partition.
Yep. As well as what Toomim said, eg-walker (another text crdt algorithm) doesn’t need or use tombstones. With eg-walker we just store the history of all changes (kinda like git). Some changes are deletes. The changes are only used for merging old stuff, so if you’re happy to set a cutoff (or have some coordination like antimatter) you can delete the operation history and all the overhead that goes along with it.
Huh, the checkpoint primitive is something that I've been thinking about for a while, excited to see how it's implemented in the CLI. Git-compatible structures seem to be a pretty big pull whenever they're talking about context management.
This is hilarious lol, it’ll be any day now before we get a full JS kernel. Garbage collection could be an obstacle, but I know there have been some kernels written in Go/Java before
I don't have real context here, but I can imagine that a platform where the hardware costs millions of dollars, will be booted up in "Production" exactly once, and is guaranteed to be physically destroyed before it hits 1 day of uptime, just "Give it 128GB of RAM and YOLO (literally)" is great advice!
Note: 128GB of DRAM may add another million dollars to the build cost by 2027 at the current derivative of the $/GB curve
Makes sense, it feels like this just codifies a lot of implicit standards wrt OSS contribution which is great to see. I do wonder if we'll ever see a tangible "reputation" metric used for contribs, or if it'd even be useful at all. Seems like the core tension now is just the ease of pumping out slop vs the responsibility of ownership of code/consideration for project maintainers.
reply