Hi there,

I hope you all had a great Halloween weekend. In our house, it was the best one yet. My oldest son is really just now old enough to get into the costumes and trick-or-treating, and so we had a lot to enjoy.

There has been an uptick of people reaching out to me for career advice, which is interesting because I've changed where and how I put my material, which has led to more people than before.

This has me thinking a bit about the hardest part of getting a job in tech, the technical interviews. Specifically when you have to solve technical problems. Sometimes this is called a whiteboarding interview, but there are multiple varieties of it.

Anyway, let's talk about when you have to solve a problem in front of people as a part of your interview.

Now there are a lot of things I teach people about this one particular interview, but in this letter I want to focus on one aspect of it, which is the order of operations to take.

1. Understand the problem
2. Break the problem down
3. Solve in parts

So step one is about hearing the problem and asking questions to ensure you understand it. Asking about I/O or memory constraints, or input data sizes, or things like that. I'd also consider going further and asking point blank what qualities are they looking for in my answer so I know where to focus my effort.

Step two is the heart of what I want to get into. As you understand the problem, write down all the smaller problems that you know you have to solve to complete your solution. Just list them out. Doing this establishes immediately to the interviewer that you have an approach to the problem, and helps convince them that if you have enough time you'll solve it. They know where you're going, and this makes a big difference compared to just getting lost in the code when the time runs out.

The last step is to actually go about solving the problem. Ideally, you do this not in actual code, but in pseudocode, but with the list of problems, you have a unique option. You can solve the problem out of order and in parts. So for example, if one of the problems you identified is to return the final result, you can write that final line. Then bounce to another part and continue weaving in the pseudocode around it until it becomes the final solution. It sounds strange, but if you can handle this approach you're able to optimize the minutes you have by showing progress towards a complete solution without getting stuck.

Anyway, if you have an interview coming up, let me know and I'll happily help you get ready. Also, I'd love to know about your last interview experience and if an approach like this would've helped you.

Here's my weekly update for November 5th, 2021...

🗒️ The One Remote Person

Often consultants bring a fantasy of co-located teams to their clients.

This is a fantasy because companies have been using remote workforces for the entirety of my career, so thinking that will change is silly.

In this particular article, I want to focus on one tiny aspect of a fairly standard setup—a single remote worker with a significant time difference.

Click here to read more

🗒️ Bringing Conversation to a Point Using ORID

We’ve all been in meetings that wandered around topics without ever really landing on a defined point or decision.

This leaves many people frustrated that there isn’t closure, and when the meeting is over, nobody is sure what they should take from that meeting.

A straightforward technique to learn, though difficult to master, is ORID.

Click here to read more

Enjoy,

Ryan Latta