b4ux1t3 Writes

I’m trying to share openly what’s going on in my interview processes as I find a new job.

My thought process is simple: stuff is crazy, and everyone is uncertain what hiring even looks like right now, recruiters thoroughly included (I know a few of you folks are recruiters and I do not envy you.)

It definitely feels like there’s a stronger focus on “durable skills” now than there was a few years ago. They’re testing for things like “can this person use current technology to solve problems”.

Now you may be confused, because this isn’t a new thing. However, whereas before there was lip service paid to “we’re trying to judge real-world skills”, now there exists an environment where determining a candidate’s actual ability, and not just whether they can answer questions that are shaped correctly, is more important than ever. (Yes, because of AI, did I need to say it?)

The interview I just had was a great example. Interviews like this I’ve had before have always been…scattered. “Here’s a thing I want you to build, hey, you didn’t account for security, can you speak to how you’d secure this system?” And this was more or less the same, but the specific questions were very different.

The interviewer wasn’t looking for whether I knew what a load balancer was, he was trying to tease out if I’d just memorized some generic structure or whether I was coming up with the system from scratch. He wanted me to defend my position to use a message queue, and even discuss the relative tradeoffs of existing solutions (versus designing a simple one for ourselves).

The way you approach this process is not to start drawing boxes. It’s to demonstrate that you now how to explore the space around a problem. (You might do this by drawing boxes, and that’s fine, but don’t just start putting boxes down and call it a system.)

So what I did was build out a set of “features” with associated “stories”, making sure to be extra clear that I’m using them as a tool to explore the system. From there, I broke out the stories into how that will translate to the physical experience of doing things; a wireframe.

Then I sketched out how that would break out into various systems; what handles the user click (the front end system), what handles querying a vendor’s api, things like that.

That naturally leads you, if you follow this path, to a set of discrete user stories that can be tied directly to things like api calls, database queries, and really the rest of the system.

Note to self: Give an example here, eventually. ;)

Note the important thing here is not “make a wireframe”. It’s to use the wireframe to help you think about the system. Each high level user story can be broken down into a bunch of smaller user stories, and some of those will be atomic.

This acts as a sort of “depth first search” into a graph of user actions that is “your user stories”. If you recursively decompose high level stories into atomic actions, you’ve suddenly also designed your API.

This is a short hand. It is not the only tool in your belt, but it’s one I’ve leaned on for a long time and have seen lots of success. You could practice this today in your job, so you're ready for when you need to jump ship.

My interviewer seemed to appreciate it. The process is both mechanical and deterministic while also leaving plenty of room for creative problem solving. Essentially, I like it because it’s a lot like writing code. And we don’t really…get to do that all that much anymore in this industry.

I hope this helps folks. I’ve been building systems my whole life and I still get extremely nervous when these interviews come around.