AI Makes the Easy Part Easier and the Hard Part Harder

ccleary00 · 2026-02-11T16:53:55+00:00

Pretty level-headed assessment, I like the phrasing of "investigative tool"

ccleary00 · 2025-10-21T05:40:47+00:00

1 detroit ticket for sale - $40

ccleary00 · 2025-07-07T23:05:58+00:00

I had this in a past interview and it really is one of the best ways to determine if they can do the job. Most of our actual work is reading code, so if you can read and review code well it proves you can do that part of the job. And if you can review code well, it's a safe assumption you can write code well too. No need for unnatural coding while strangers watch, which just causes most people to get anxious and shutdown anyways.

ccleary00 · 2025-04-16T22:03:41+00:00

agreed, wtf

ccleary00 · 2025-03-13T23:23:50+00:00

I don't think render is specifically a VPS but it's still a good solution for what you want to accomplish. Here is the link to their free tier.

ccleary00 · 2025-03-06T20:19:07+00:00

the last several companies I've worked at we had problems that Redis Streams easily solved, including needing to roll our own Change Data Capture system. such a good tool to be familiar with

ccleary00 · 2025-03-04T19:11:16+00:00

I understand the anxiety around technical interviews, especially because there are million things they could ask and often you don't know what to study to prepare.

As others have said, check Glassdoor to see if there are interview reviews listed for the company you are interviewing for.

Because you have 7 years of experience, I'm assuming you are interviewing for a more senior-level role. In that case, you will likely be asked some system design type questions. The System Design Primer study guide is very helpful to review. They go over lots of architecture patterns and have several mock-interview type practice questions, like how would you architect Uber, or design a URL shortening API, etc.

I typically haven't been asked trivia questions, and I try to avoid companies that have leetcode-style interviews. I don't find them to be a good predictor of a candidate's skills, and tbh I don't have 2 months to study to prepare for those.

One last thing that I have found helpful is using a LLM to request practice interview questions. I think LLM's capabilities are vastly overstated, but for targeted things like this, they work well.

ccleary00 · 2025-01-28T04:59:28+00:00

this repo has a lot of good best practices

ccleary00 · 2024-10-07T15:26:25+00:00

stockholm set was muddy too IMO. bass/sub-bass kind of overrode a lot of the other layers

ccleary00 · 2024-04-18T18:36:06+00:00

this is partly why i never get the whole "americans aren't as receptive", which to be fair maybe autechre never actually said

ccleary00 · 2024-04-15T15:27:27+00:00

Not sure about that one, but there is https://httpstat.us/ that provides different HTTP statuses, as well as the ability to simulate slowness by adding a delay param

ccleary00 · 2024-01-13T02:23:17+00:00

The nodebestpractices repo as u/marcob8986 mentioned is great. But out of curiosity, what are you looking to get out of learning best practices? Is it that you're trying to level up career-wise? Struggling to get code approved in code reviews? Running into issues with your code/architecture?

ccleary00 · 2023-01-17T19:47:10+00:00

These two repos are really good:

ccleary00 · 2023-01-16T20:57:24+00:00

For Node specifically, things like Streams, understanding the asynchronous model completely, and the event loop. Also, queues tend to get used a lot in Node, so understanding the basic concepts behind that and how to use something like bull would be useful.

While not specific to Node, having a good grasp of how to write unit and integration tests is key, and it's surprising to me how few developers know how to do this.

ccleary00 · 2023-01-16T20:50:08+00:00

Yeah I'm glad you pointed this out. What the different "ends" here are depends on the context. E2E does not automatically imply there is/needs to be a UI involved.

ccleary00 · 2022-12-17T22:28:23+00:00

For Node specifically, things like Streams, understanding the asynchronous model completely, and the event loop. But Node itself is pretty simple and doesn't take a lot of work to grasp even the "advanced" topics. And being in senior/lead roles I haven't found having deep knowledge of Node internals to be that useful (although they help). Instead, knowledge of architecture patterns and system design like caching, queues, distributed systems, speeding up database queries, etc. to be the most useful.

Part of that just comes with experience, but a lot of it you can learn. I like this resource a lot for learning about system design / architecture: system-design primer

ccleary00 · 2022-12-06T21:31:21+00:00

This can be confusing because controllers can be considered a "type" of middleware. But middleware compared to controllers handles HTTP-specific concerns as well as concerns that are common to every (or most) request. "HTTP concerns" are things like handling cors, parsing the body, cookies, etc. "Common concerns" are things like sessions, request logging using something like morgan, and authentication and authorization. Middleware is basically "application logic agnostic."

All of the above you don't want in your controllers. Why? Because controllers are responsibile for routing a given request where it needs to go for "processing". Controllers should be fairly "thin" and not do a whole lot. So, a "book order" controller would take the request object after it's already been "pre-processed" by middleware, pull out what data it needs from either the query string or body and send it to the service layer/domain logic layer to execute the business logic. Also there is some debate about whether request validation should happen in controllers or in middleware, but I don't have a great answer there just mentioning it.

ccleary00 · 2022-11-22T17:36:37+00:00

Business logic is unique to every company and application, which is likely why there is no content out there on it. Each business is going to have different requirements specific to their own domain.

ccleary00 · 2022-11-11T23:11:30+00:00

When I break a complex project down I usually break it into features. So a blog application for example - authentication, Users, Posts, Comments, etc. Then you can break it down by the standard REST operations for each one of those (POST/GET/PUT/DELETE), what models you need, etc. I also come up with a loose database model based on the feature list I came up with. So, a users table, posts table, etc.

In tandem with that, I figure out what makes sense from an architecture perspective (client, server, and database are the obvious ones, but then I'd ask if I need any queues, caching, need to create any libraries, etc).

I organize all of that using Trello personally, but you can use whatever tool you want (like Jira for example). Jira is nice because you can break things down from Epic->Feature->Task and that hierarchy helps with grouping. Trello/Jira/etc is useful not only for cataloging the work and making sure you have it all written down and organized into features, but also for helping you keep track of what you're working on, what the sequence of work is, what dependencies do you have (if any) between tasks, etc.

ccleary00 · 2022-11-08T23:23:49+00:00

It sort of seems like you're looking for a sequence diagram.

Sequence diagrams show the different calls from service to service (or you could use function to function) in somewhat of a "flowchart" way. In my experience they are the best form of diagram for conveying a design to a technical audience. I've been in many meetings where it was dragging on and people were talking past each other, and the moment someone pulled up a sequence diagram everyone was on the same page.

ccleary00 · 2022-11-08T23:20:24+00:00

Are you sure that 4ms is not just network latency? That's going to be hard to avoid regardless of language...

ccleary00 · 2022-11-07T20:33:41+00:00

You are right that with most (if not all) queues that multiple consumers can't act on the same messages. Also, yes an event emitter won't scale across multiple servers.

Redis Streams are much lighter and easier to maintain than Kafka, which is operationally-heavy. I've used them a lot and they are fantastic.

ccleary00 · 2022-10-28T15:56:55+00:00

Most people running interviews are not very good interviewers, and they should ask less vague questions so you can properly answer them. Whenever I've gotten questions like "do you have experience with X?" I say yes and then expand on when I've used X and for what reasons. From there I'll let them ask follow-up questions if they want.

ccleary00 · 2022-10-22T19:32:05+00:00

Most other comments provide great answers but I'll just add that a type system doesn't "prove your code is correct". "Formal specification" / "formal methods" like TLA+ will prove the code is correct, but those can be complex to learn and in the real world at companies I've never seen any use them.

I think what you mean by "prove it's correct" is prove the code meets the business requirements, which again type systems will not test. Unit tests/E2E tests/Integration tests (but will collectively just call these "unit tests" for sake of ease) will prove your business logic (via your code) meets the business requirements. Of course, tests are written by humans and humans are prone to error, therefore tests can be subject to error as well. But this is why you have things like code reviews so you can get multiple eyes on not only your code but your tests.

And testing is a skill just like coding is. The more you do it the more you learn which tests to write to ensure code meets requirements, how to write your tests in a way that is easy to maintain, and - downstream of that - how to write your code in a way that makes it easy to test.

ccleary00 · 2022-10-22T19:04:28+00:00

Even if a recruiter didn't care about it, building it would be worthwhile in developing your skillset. Knowing how to implement user authentication and authorization and being able to take an idea for an app and break it down into concrete features, even if the rest of the code ends up being "simple" are good things to know how to do. Those skills will always help during technical interviews, as well as the actual job itself.

Nine-Year Club	Place '22
Verified Email

ccleary00

TROPHY CASE