< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #309 - February 9, 2025

If you are looking for work, check out this month's Who is hiring? and Who wants to be hired? threads.

Here are the top threads of the week, happy reading!

Top comment by fhd2

The last time I've used a leet code style interview was in 2012, and it resulted in a bad hire (who just happened to have trained on the questions we used). I've hired something like 150 developers so far, and what I ended up with after a few years of trial and error:

1. Use recruiters and network: Wading through the sheer volume of applications was even nasty before COVID, I don't even want to imagine what it's like now. A good recruiter or a recommendation can save a lot of time.

2. Do either no take home test, or one that takes at most two hours. I do discuss the solution candidates came up with, so as long as they can demonstrate they know what they did there, I don't care too much how they did it. If I do this part, it's just to establish some base line competency.

3. Put the candidate at ease - nervous people don't interview well, another problem with non-trivial tasks in technical interviews. I rarely do any live coding, if I do, it's pairing and for management roles, to e.g. probe how they manage disagreement and such. But for developers, they mostly shine when not under pressure, I try to see that side of them.

4. Talk through past and current challenges, technical and otherwise. This is by far the most powerful part of the interview IMHO. Had a bad manager? Cool, what did you do about it? I'm not looking for them having resolved whatever issue we talk about, I'm trying to understand who they are and how they'd fit into the team.

I've been using this process for almost a decade now, and currently don't think I need to change anything about it with respect to LLMs.

I kinda wish it was more merit based, but I haven't found a way to do that well yet. Maybe it's me, or maybe it's just not feasible. The work I tend to be involved in seems way too multi faceted to have a single standard test that will seriously predict how well a candidate will do on the job. My workaround is to rely on intuition for the most part.

Top comment by canterburry

Every leader has their "go to" people.

You want to be one of those "go to" people! They are put on the most challenging assignments, the most exciting opportunities, more often promoted, protected from above, last to let go and frequently asked to follow that leader to new assignments at new companies usually with higher titles and better comp.

It seems to me you have been spotted by your Sr. Director and given an opportunity to prove yourself as you did in your prior team. It's a logical move to take a high performer from one team, and try to prop up an underperforming team. It's about what's good for the company.

If this fails, you won't necessarily be blamed, but you'll have lost an opportunity to really stand out amongst any other engineer at your level and earn the status of your Sr. Director's "go to" person.

Your value is in being a versatile, competent "can do anything, anywhere and happy to do it" type of resource who can be thrown into the biggest messes and come out looking good.

Top comment by peterldowns

Craig Mod's "Koya Bound" website has beautiful photos and custom SVG maps.

https://walkkumano.com/koyabound/

I thought this was so compelling that I ended up walking the trail myself. Incredible experience.

Top comment by smarkov

I'd love to, but I don't really have a choice at the moment.

Maybe I'm just at the wrong place at the wrong time, but as a software engineer I don't feel like I'm doing any actual engineering and solving meaningful problems, just spaghetti gluing random frameworks, packages and services together. The only problems I get to solve are those caused by the quirks of all these incompatible things being forced to work together. It's draining.

Top comment by AngryData

Theoretically your onboard sound could be just as good as anything you get off a card. In practice, it comes down to the physical implementation on your motherboard, like are the amplifying components well specced for their use, are they well separated spatially/electromagnetically from other potential sources of electrical noise on your motherboard, what are the power traces potentially shared with or near, is your power supply giving it clean power.

Now those aren't things you can casually observe all that useful information from, so it doesn't really help that much other than to try and buy quality components and hope for the best, often if you want good onboard sound you can find it if you are spending a reasonable amount on the board to start with though and not using and underspecced or dirt cheap PSU. A sound card could alleviate some potential issues though either because you bought a cheap board or just from being lied to by marketing that you were getting better onboard sound than they actually built. But it is still located on your motherboard and near a bunch of other things running at their own frequencies which may or may not be a problem depending on location and shielding and components.

And for all those reasons, a lot of people have skipped the sound card route and got a USB DAC, which gives a lot of physical space between all those other components and eliminates some restrictions in form factor for being inside a computer.

One thing to look at before you do anything else, look at where your analog speaker line is running. Is it now crossing near your PSU or power cords? Is it a different cheaper cord? The lowest hanging fruit for sound quality is the longest and final analog run and it is always good to try moving it around if you suspect a problem.

Top comment by dpcan

Wild West Domains is a subsidiary of GoDaddy. They are basically he same company, and the Whois doesn't usually show the owner of the domain anymore, it shows the company that's keeping the owner's information private. WWD and GoDaddy both offer this service. Lookup other domains, you'll see the same thing all over the place. The whois on just about all of my domains say Wild West Domains, the others are GoDaddy or Namecheap, my personal information never comes up anymore because I opt for the privacy options.

Top comment by dang

> The one that sent me over the edge was this: https://news.ycombinator.com/item?id=42917806

It's a longstanding principle on HN that proposed bills aren't really on topic unless there's something to prove otherwise. The reason is simple: most proposed bills never amount to anything. (And oftentimes they are political stunts.)

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

If attempts to ban DeepSeek in the US actually get anywhere, you can be sure there will be plenty of discussion on HN.

Top comment by stevekemp

Emacs is my editor, and I have it configured to use snippets in two ways:

1. When loading an empty file it inserts boiler-plate based on mode (largely that is based on the filename suffix). So if I open a buffer "t.pl" it will insert "#!/usr/bin/perl", along with "use strict; use warnings;", etc.

2. Completion for LSP-modes via yasnippet. So in golang mode I type "iferr[TAB]" and it expands into "if err != .." and moves my cursor to the proper spot when I type TAB.

Top comment by mtlynch

Assuming you're in the US, System76[0] and Framework[1] both make laptops that support Linux as a first-class OS.

I tried both and ended up preferring Framework. I especially like that they're repairable.

I bought the DIY version of Framework worried I'd hate building it, but it was super easy to put together. You're only putting together a few pieces, not the entire laptop. It ended up being one of the best unboxing experiences of my life.

[0] https://system76.com/

[1] https://frame.work/

Top comment by lostdog

Emphasize the other reasons for the team switch, and don't talk about the promo likelihood difference. Talk about how you've always wanted to try working on that field, and how this opportunity just came up and you've got to try it. Thank the VP for all their work on getting you a path to promo.

For switching, tell the VP you'll ask the new team what's possible. Go to your new VP and tell them that old VP wants this, but make it implicitly clear that you don't want this. Go back to your old VP and tell them that you don't think the long transfer period is going to work with the new team (but you tried!), but that you will still be around to help the team answer any questions.

Once you switch, deprioritize the old team. Deprioritize them slowly enough that you keep a good relationship with old VP, but let it be pretty clear that you're not gonna be doing any coding and only the bare minimum of consulting.

You should only debate promo likelihood while you're still on the team. Once you've decided to leave, drop it from discussion.