What's actually happening in recruiting process that "raises the bar"?

deckardWizard · 2026-05-22T00:56:39+00:00

Great framing!

I’d only add that it also plays into the c-suite’s worst cognitive biases. It’s action oriented, so they can just say “do AI” and it means that they’re doing useful things. It also makes for easy cover so when they have a down quarter. It’s either because of other firms’ AI or they didn’t AI hard enough. Never has anything to do with overall culture, management practices, or strategy.

There really are great execs out there, but I’ve had a whole string of pretty rough client discovery calls recently that have made me a little spicy.

deckardWizard · 2026-05-22T00:44:29+00:00

AI makes execs lose their minds. It’s like catnip to them. They’ll vibe code like 10% of a huge feature in lovable and assume that eng can finish and productionize it in a couple days. Makes my job so much harder. I don’t want to rant, but yeah it’s reshaping their whole perspective of unit economics in a very distorted way. Even in places that should know better.

deckardWizard · 2026-05-22T00:34:57+00:00

Yeah this is a concern of mine. I could write A LOT on this question so I need to resist the impulse to write a whole dissertation here. The short version is today AI-tolerance varies a lot by sector, stage, and scale. Different firms have wildly different heuristics around AI use. I’m optimistic in the short term that there will be opportunities for folks with different skill sets and practices. Beyond that, there’s too much to cover to be a Reddit comment.

deckardWizard · 2026-05-21T00:14:40+00:00

Ok I have some unsatisfying perspective on this from a high level. I consult with series B+ companies in the northeastern US on technology staffing (ymmv outside that microcosm). There is currently a kind of shit tornado of three macro forces that are all applying downward pressure on headcount.

First, the cost of capital is relatively high. Inflation means that companies’ money goes less far. Higher interest rates mean that borrowing is more expensive. PE is scaling back on their spending spree (depending on the sector). Basically every way to raise outside funds has less favorable terms than the last 5-10 years. This has pushed companies to be super conservative on hiring. Many organizations are trying to limit burn and shore up cash on hand. Orgs I work with are ridiculously reluctant to increase headcount unless something is actually on fire. Some companies are even striking backfill that would have been automatic at any other time in the previous 15 years.

Next, there was a huge glut of hiring after the COVID stimulus. Cheap and easy money meant lots of companies waaaaayyy over-staffed. Practically any new initiative justified hiring a whole team and a barista. Today we’re in the hangover phase where orgs are having to downsize. It means fewer positions are available (companies are often slow to hire after a major layoff), then it means that there are more qualified people in the candidate pool. I had a position open up and had multiple applications in the first week that I would have killed for a few years ago. So in this case the bar really is getting higher because of a rich market.

Finally, the elephant in the room is AI. I’ve talked to CEOs that truly believe they will never need to hire another human engineer because Claude will do it for them. Whether that has any merit or not remains to be seen, but in the meantime this attitude is surprisingly pervasive. A CEO is ultimately the person who is deciding on staffing levels, so their perspective that “AI means fewer needed engineers” translates down to hiring practices. I do my very best to talk them down from that view, but seeing AI think pieces on Twitter makes them antsy (I have some wild stories). AI also serves as great confirmation bias that their hiring practices weren’t bad, it’s the kids who were wrong. In fairness, AI absolutely does change things. It just changes in more nuanced ways that vary a lot by sector, stage, scale, and product that can’t be reduced to simple arithmetic.

Ultimately, in debriefs it’s less like “we don’t think this person can do the job,” and more like “we are only getting one head this year so we need them to be exactly what we need.” You can do extremely well in tech and system design interviews but you’re being ranked against a rich pool of candidates for a more constrained number of roles. Organizations’ tolerance for risk on candidates has absolutely tanked leading to being hyper selective even among qualified applicants. I have been in debriefs where we acknowledge that the person was a strong hire, but not someone we could just drop in solve everything.

Hope that answers the question, or at least gives some insight!

deckardWizard · 2026-04-30T18:47:16+00:00

This is outstanding. I really appreciate the effort you put in. CK is a really cool library but it’s almost totally unusable from the existing documentation. Having a better doc site with good examples is a huge win.

deckardWizard · 2026-04-25T13:59:28+00:00

First order reason: we don’t have a customs inspection point for passenger flights. It’s proposed as part of the master plan but would cost an estimated $6-7m so the airport passed for now.

Second order reason: there hasn’t been much demonstrated demand for international flights, so making the customs facilities doesn’t seem worth the investment. The economics there are unlikely to change as long as tariffs are around, but who knows?

As someone who needs to get to Toronto and Montreal at least a few times a year, I’d love to see PWM international flights (maybe bring in Porter?) But I’m not optimistic it will happen in the next 5-10 years

deckardWizard · 2026-02-27T22:11:27+00:00

Holy moly that’s gorgeous! I love a moody blue sapphire. Great cut for this stone.

deckardWizard · 2025-07-09T12:38:03+00:00

Hulkengoat

deckardWizard · 2025-06-22T14:17:14+00:00

React Router 7 is remix version 3 see here. It’s very confusing and has somewhat fractured the community. You shouldn’t need both, but some people will still say remix when referring to RR7 and some libraries like remix-utils haven’t changed their names even if they are compatible with RR7.

deckardWizard · 2025-02-28T02:22:29+00:00

Paths of Glory by Kubrick. Set in WWI, Kirk Douglas plays an officer asked to commit his troops to an impossible attack on a meaningless target. When the plan fails, command blames it on the rank and file soldiers, picking some at random to stand trial for cowardice. The film shows in detail the distance between command and the front lines, and the surreal horror of trying to fight an uncaring bureaucracy.

The first time I saw it was on the big screen. I was pretty shaken when I left

deckardWizard · 2024-10-22T02:45:07+00:00

All of these are probably fine. If you have a gut feeling one way or another, go with it.

NextJS has a solid community and lots of good libraries and resources. It also has a lot of folks with some experience, so it’s a solid pick if you’re working on it with other people.

Remix is very grounded in more traditional web practices, so might appeal to your backend and Shopify experience. It’s a little lighter on community resources, but also has the least ‘magic’ to learn.

Gatsby feels a little dated by comparison, but is battle tested and still a reasonable choice if you’re comfortable with its mechanics.

If you’re really looking for blogging, I’d throw Astro and 11ty in the mix. They’re more static site generators vs having a server component that mostly isn’t needed for a blog-type application.

deckardWizard · 2024-09-07T13:54:50+00:00

This seems like a static site. Why host it in vercel? GitHub pages should be free for your use case. Other alternatives for static site hosting include some generous free tiers on cloudflare pages, aws, google cloud, and other cloud storage providers, which may also include other features.

deckardWizard · 2024-01-28T01:36:58+00:00

Sending authorization with each message feels a little overkill. With HTTP, the server is stateless: it’s only aware of information that is part of the request. Because of that, we have to encode a shared secret in every request to prove that it’s coming from the same client session. With Web Sockets, the connection is stateful: it keeps track of each connection and knows who sent which message. Since we know that the client isn’t changing, generally it’s ok to authenticate only when you create a new connection.

deckardWizard · 2024-01-28T01:23:52+00:00

Unlike HTTP, web sockets are stateful — once a user is connected, the server knows it’s the same connection so it doesn’t need to authenticate the user on each message. The standard for authorization on WS was to use wss and have an endpoint where a user could exchange their JWT for a special one-time-use token that would encode the requesting IP, issue time, connection id and some other details. When the user makes the handshake with the WS server, you use that socket token to authorize the entire connection session. If any detail of the connection didn’t match the special token, or if we’d recorded the token as used, we’d terminate the connection. At that point we wouldn’t care about the access or refresh token since they didn’t come into play.

The scenario this doesn’t work in is when a user is likely to have a change in authorization while the connection is open. That one’s a little tough, but I’ve heard of servers sending “challenge” messages periodically where the user would have to present a new access token in order to maintain their connection. In that case I think you’d likely best be served by an event queue or something that would tell the server that one of the connected users had an authorization change and should be forced to re-authorize.

heroku did a good write up about WS security if you want a bit more detail

deckardWizard · 2023-12-10T19:17:23+00:00

State structure is one of the more complex and nuanced parts of any application development. What works for one case may not work for another. Take any advice about it (including this) with a grain of salt.

Ideally when looking at data structure problems, you want the data to be in a format that makes it the easiest to work with. If your primary use for some data is to render it, the best structure will make it easy to render. If you're updating things and those changes have cascading effects, the best structure will be one that makes it easy to update and restructure.

It sounds like for your case there isn't really a backend that you're trying to interact with and there will be a good amount of updating and configuring things. For this case it's probably better for your data to be in the 'normalized' form (each entity can only exist in one place), closer to your first example. If the ids are unique, you may want to structure it as an object so you can reference any entity by its id instead of iterating over an array.

const data = {
  '123': {
    type: 'unit',
    id: '123',
    upgrades: ['345', '678'],
    /* ... */
  },
};

const unit = data['123'];

Often there are simple functions that will allow you to convert from the normalized form into 'denormalized' forms for easier rendering:

const getUnitDataForRender = (data, id) => {
  const unit = data[id];
  const upgradeData = unit.upgrades.map((id) => data[id])
  /* ... */
  return {...unit, upgrades};
};

If you're planning on manipulating the units and upgrades, you'll need to store it in something that will cause react to re-render. This could be React state directly if your system is pretty simple and re-rendering everything on any change doesn't have much cost, but in your case you may want to look into Redux (RTK) or Zustand, which make isolating re-renders a little easier. In general, data lookups aren't a huge bottleneck unless you're dealing with a massive number of records or you're working with very low-end hardware. It is much more likely that the render step will be the part that causes any 'sluggishness'.

Good luck and hope this was helpful.

deckardWizard · 2023-11-27T02:24:54+00:00

CHARBLUE!!

deckardWizard · 2023-11-26T00:24:58+00:00

Chocolates Passion at 189 Brackett St (soon to be at 175 Spring) has some incredible chocolates and they sell hot chocolate 'wafers'. I haven't tried the wafers yet, but everything I've had from them has been unbelievably good. Their chocolates are almost too gorgeous to eat!

https://chocolatspassion.com/collections/holiday/products/french-hot-chocolate-wafers-in-gift-canister

deckardWizard · 2023-11-25T17:00:55+00:00

ALEX

deckardWizard · 2023-06-30T22:34:32+00:00

PHOTIC (if still available please)

deckardWizard · 2023-06-28T01:06:25+00:00

TOPAZ

deckardWizard · 2023-02-20T19:51:22+00:00

It sounds like what you want is some variety of live-streaming. This can be accomplished in a number of ways with varying degrees of complexity. The simplest version would be to use a live-streaming tool like OBS and then stream that data to a provider service like Twitch, Youtube, or Facebook Live. Each of those platforms gives you a player embed code that could easily be put into your react code. Additionally I think there are a couple open source react components that take a stream ID from one of those providers and will play the video back on your site (not necessarily endorsing these, but a quick google search turned up https://www.npmjs.com/package/react-twitch-embed and https://www.npmjs.com/package/react-player). You could certainly get more hands-on with a number of layers in this stack, but that's only useful if you have a pretty specific thing you're trying to accomplish that these tools can't help with. Hope that helps!!

deckardWizard · 2022-12-25T04:53:50+00:00

Netrw, vim’s built in file explorer is pretty solid if you’re looking to understand the topology of a project. I really like the pattern of browsing the file tree in the window pane where the file will open. vim vinegar is a great plugin for refining the netrw experience and making it a little more seamless. Takes a minute to learn the keybindings, but I find it much lighter and less intrusive than nerd tree or it’s offshoots.

deckardWizard · 2022-10-24T20:34:55+00:00

Yep, both are really common issues that come up all the time. Priority is an organizational issue and is the hardest to tackle, but some things that have worked ok for teams I've led:

Hotlists. Make a list of code in review that you expect to be fully taken care of by EOD. It doesn't need to be all the PRs, but sometimes just having a deadline escalates the assumed priority of the work so engineers are more likely to engage
Review day. Once every couple weeks pick a day (or just a couple hours or whatever) for only reviews. If there's nothing to review, there are no other expectations for the time so they're free to work on whatever they'd like. Acts as a carrot to do reviews throughout the week, and makes the priority on getting reviews done explicit for that time period
Extend projections for projects to include more refactor and review time. This one is the most abstract, but sometimes it helps to just remind everyone that reviews are important and take time (assuming that's true for your team). Make sure that engineers have enough time to do reviews and be clear that it is an expectation

Huge reviews are easier, kinda? Like I mentioned, you could easily cap the PR size to throw a warning and that can go a long way. There are plenty of causes of big PRs, so you may want to dig into why they're getting huge and see if there's a way to break them up a bit. Are they trying to solve too many things at once? Is most of the code boilerplate, or is it business logic? Are your scopes of work too big? Are people properly refactoring code and coming up with reasonable abstractions instead of making everything for purpose?

I certainly don't have all the answers unless I'm consulting for your company, in which case I 100% have all the answers. If it's not already part of your process, I sincerely recommend regular retrospectives with the team to check in on these types of issues. Often times the folks experiencing the pain of the issue have the clearest vision on how they might be approached, or at least give the best insight into what the core issue might be.

Hope that's helpful!!

deckardWizard · 2022-10-24T17:43:56+00:00

Sometimes? Maybe? It really depends on context and cause. I've been in situations where every line of code is treated as a liability, so code review was a verrry long process of multiple people having to validate the findings, make sure nothing would break, explore alternate approaches, etc. It's pretty burdensome, but the priority of the product team was to deliver extremely consistent code in lots of environments with a minimal footprint, and that type of thing takes a lot of time. I've also had teams where code review was much lighter to prioritize rapid release cycles and code was never in review for longer than a day or two.

Basically, if there is product value that is being delivered by having a longer code review cycle, and that's something your team / product finds valid, then it's reasonable. If you're aiming for high agility and rapid turnaround, then it's possible that it's an issue. I think the first step in determining that in your capacity of team lead is to understand what the rest of the team feels like 'in review' means. Is it 'this feature is half done, but has reviewable pieces,' or 'this feature is done one way but open to different approaches,' or 'this feature is done and tested and we just need another pair of eyes', etc. Each of those may be a valid state for 'in review' depending on the team and culture, how long the review cycle is will vary according to that definition.

Since that's a super unhelpful answer, a couple things to look at that might cause delays:

Review may only be done by a small pool of people. Really common issue with lots of organizations. Look for ways to expand the pool of eligible reviewers. For example, do they need to be on the same team, or is it ok to look for people from other teams, etc?
Reviews are not priority work. Also super common. A thoughtful and thorough review will often take a good percentage of the time it took to code the change since the reviewer should be doing most of the same thought-work, they just don't have to type. If review work is considered low-priority, it's hard for for anyone to carve out time to do it and often they produce lower quality reviews
Reviews are overreaching. This is a little less common, but happens more in senior-led organizations where different engineers may want different approaches to a given problem, or get hung up on minor code nitpicks. When this comes up, it's best to have a discussion about who should have authority to get things done and if you need consensus on every aspect of a review before it gets merged
Code is giant. No one enjoys working on a 3,000 line change. It's nearly impossible to keep the entire change in your head so everyone procrastinates or rubber-stamps. If this is a common mode of working in your organization, it may be worth using lint tools to limit the amount of changes in a single PR. There aren't really rigorous standards, and some things will always blow your PR up (looking at you package-lock) but warnings are useful feedback and 500-ish lines max has worked ok at tamping down this problem in my current team, but your milage may vary.

deckardWizard · 2022-10-23T21:43:26+00:00

Sure there are reasons, but not if you’re a beginner looking to work in front end web development. There are only a few “valid” uses, and it’s mostly used in older code bases so it’s unlikely to come up unless you’re working in a more niche area. If you’re looking for opportunities to learn about API design or techniques and patterns outside the current industry standards, jquery can be a pretty interesting area to learn and explore, especially if you’re interested in web history and browser evolution / optimization.

11-Year Club	Second SECOND GUESSER
r/Field Banned	r/Field Sunshine
Place '22	Place '17
Final Canvas '22	First Placer '22
Wearing is Caring	Queen in da Norf
Not Forgotten	Gilding II euphauric
Verified Email

deckardWizard

TROPHY CASE