Have you ever played Battleship? It's a game where 2 players put their ships on a grid and start guessing coordinates. If you guess a coordinate where your opponent's ship is located, that counts as a hit. Each ship takes up 3, 4, or 5 coordinates and once you've guessed all the coordinates of a ship, it's sunk. The commercial when I was kid had the kid on the losing side exclaim, "You sunk my battleship!". Good times, good times.
This is part 2 in a series. If you have no idea why I'm talking about board games from the 1980's, start with Part 1.
Battleship taught me most of what I need for troubleshooting. I have a bounded set of possibilities, I only get a certain number of attempts, and there's an uncomfortable period during each attempt when something bad may happen to me. When playing Battleship, you can simply guess at random, or you can employ a directed strategy. The same is true in troubleshooting. If you're all over the place, sometimes you'll get lucky and sometimes you'll miss for what seems to be an eternity.
As you're implementing your search strategy, it possible to become too focused. In the game, for example, it makes little sense to test a coordinate immediately adjacent to your previous guess since the ships are at least 3 units long. Better to space out the testing and then "walk it in" by focusing in the surrounding area once you get a hit. The same is true in troubleshooting. If each test run is simply a close variation on the previous hypothesis, you're in for a long night. If, however, you take a wider approach and test based on variations that are reasonably separated, you have a much better chance of getting a hit, and then you can hyper-focus on the surrounding areas.
I seem to recall that Battleship was never as much fun as I thought it should be. When you think about it, there isn't all that much excitement and it doesn't have much to do with the Navy. Troubleshooting: same story. It's one of those things that you do that has its ups and downs, but overall you kind of wish you had done something else instead.
The point here is that when you're confronted by a troubleshooting problem, don't just fire at random and hope that you get a hit. Approach it with a plan, execute, and as you get some success then focus on that area for all it's worth.
I've interviewed a few dozen developers in the course of my career and I've finally settled on a few questions that I'm almost certain I'll ask. If I'm going to interview you, consider this a study guide. If you're going to interview someone else, feel free to use the questions as you see fit. If you're going to interview with someone else, you might prep answers to these questions and find a way to slip them in even if the questions aren't asked.
1. Have you ever seen software written well?
I've come to believe that it's difficult to write software well unless you've seen it done well. But be forewarned, this is not a question you can simply answer "yes" to, even though some candidates have tried to do as such. If you tell me "yes", and leave it at that, the follow up will be "What did that look like? What made you feel it was done well?", or any number of variants See, I'm not just looking to find out if you've seen software written well, I'm looking for a sign that you noticed what made it good. People who have noticed good things will also notice the absence of good things. The first time I test drove this question I had a candidate named Khurram whose eyes absolutely lit up as he said, "Oh yes! I was on a project where . . ." and he went on for 5 or 10 minutes about all of the things he'd seen and why they were great and how they helped later. It was an interviewer's dream come true and cemented this as a permanent question on the list.
2. Have you ever been on a bad project?
Once again, you can try to answer "yes", but I'll ask very similar follow up questions: "What were the symptoms? What were the causes? When did you know that things were going South?" and one of my favorites: "What did you do about it?" Chances are you've been on a bad project, but did you pay attention to what was going on around you, or did you mindlessly write code and close tickets? People who have noticed what causes projects to fail are more valuable than those who haven't because they'll recognize the signs of a project that's going in the wrong direction. Even more valuable is having built up a collection of countermeasures, but if you have those then you probably won't be interviewing very often because there'll be a list of people who are trying to hire you.
3. Have you used branches in version control?
I'll admit that I'm a little . . . um . . . hyper-focused on branching and version control. But here's the thing: I can tell so much about where you've worked and how you've worked from this one question. If you say that you have used branches, I'll ask you about your branching strategy and start to learn about how you work by seeing what you protect yourself against. NOTE: Never, ever, try to fake having branched. There are all kinds of problems that are both solved and caused by branching and if you try to fake it, you'll get caught quickly. If you haven't worked in a group that uses branches, then I instantly know that you've never seen a good build process either. I'll know that you either haven't worked on parallel features/fixes or haven't done it safely. Another note: when I get on my branching soap box, it is a prime opportunity to talk about process, but a surprisingly bad time to talk about technology. I'm trying to open the door for you to discuss things being done quickly, safely, and thoughtfully. If you take this opportunity and use it to talk about the latest distributed version control system and how cool it is, you'll hear that door slam closed very quickly.
That's it. Those are the 3 questions I ask in every interview now. Notice that there are no right or wrong answers. There is literally no honest answer that you can give that would cause me to not hire you, although I will use the answers to qualify your experience level. Junior developers can answer "no" to all of the above and still get hired because this may be their first or second gig. Mids need to answer "yes" to at least one, but preferably two of the above. If you call yourself "senior" and can't answer "yes" to all of the above (and preferably have multiple examples) then you're kidding yourself. I don't mind that you're not senior, but I mind a lot that you're kidding yourself. Also note that there are no technical questions on the list. This is for 2 reasons: Technology changes often enough and is specific enough to the project that it doesn't make sense to me to have permanent tech questions. Secondly, and probably most importantly, I tend to work with programmers that are better than me and they usually have the tech portion of the interview covered really well.
As a final thought, keep in mind what an interview is. An interview is a chance to make people want to give you the opportunity to work with them. No one is really going to know what it's like to work with you until you're in the trenches together for a couple of weeks. If you go into an interview with a story to tell and make life easy on the interviewer by answering their questions in long form, with some examples, then they're going to like you. You will give the impression of someone who takes initiative and shares the workload. On the other hand, if information has to be dragged out of you or your answers are unclear then you're going to give the impression of someone who has to be spoon fed tasks and even then not necessarily deliver.
Feel free to add your own favorite interview questions (or the worst ones you've heard) in the comments!
I'm a big fan of analogies. Analogies are the Swiss Army knife of the brain (note: I'm also a fan of recursion). A good analogy gives you a clear mental model of something complicated. This is the first in a series of posts that was inspired by a walk through a toy store where I saw some of my favorite childhood games and for each one thought, "Wow, that game is just like . . . " about some facet of my job.
Jenga
Jenga is a game where you start with a bunch of rectangular blocks stacked in an orderly manner into a tower. The game progresses by each player pulling a block out of the structure and stacking it on top. In this way the tower becomes taller and less stable over time. Sound like any systems you know?
By day I specialize in brownfield development which is like walking into a Jenga game near the end. Actually, it's like walking into a game where most, if not all, of the original players have left because no one wanted to touch the unstable mess in front of them. In Jenga, the one who knocks the tower over loses. There are 2 ways to knock the tower over: by pulling out the wrong piece or by putting the piece in the wrong place. In other words you can lose by removing the wrong thing or adding the wrong thing.
So how do you play well?
To be a good Jenga player you need 2 things: An understanding of the tower's current state and a steady hand. If you ever have the chance to play against a mechanical engineer, civil engineer, or architect (the real kind) then realize that you will most likely be playing on the basis of your steady hand. These folks will look at the structure, see some crazy Beautiful Mind type equations floating around, and pull a piece that you'd never touch. In the same vein, the more you understand about how your current system is built, the better off you'll be when it comes time to remove sections of it.
The steady hand in Jenga is analogous to the work habits of a solid developer. If you're focused, consistent, and just a bit fearful, then you'll probably do better than someone who just adds stuff in willy-nilly.
To take the analogy beyond game play itself, if you do knock the tower over then what you do next is very important. If you quickly reset the game to play again, chances are you get to play again. If you look at the mess, say, "Sucks to be you!", and walk away then it's likely that no one will want to play with you ever again. Also bad: losing a piece.
In short: You can win by taking the time to understand things well, being careful, and cleaning up quickly when things fall apart.
I read a lot about successful people. I also think a lot about people who aren't as successful as they could be. My theory is that if I can determine what makes or breaks success then I can either emulate or eliminate as the case may be. Recently I've become convinced that I've found at least one piece of the puzzle and it has survived back-testing against both the success stories and the group who falls short. The entire concept can be boiled down to 3 words:
Commit and deliver
I originally spent some time thinking that it could be boiled down to 2 words "commit" and "deliver", but it turns out that the "and" is critical. I've worked with lots of people who commit, but then fall short on delivery. These are usually excuse artists who are more adept at explaining away success than they are at pursuing it. The excuse artist won't see non-delivery as failure, they'll just explain how they could never have been expected to deliver . . . despite having committed.
I've also worked with people who deliver, but never commit. I'm sure everyone has worked with folks like this. They're the wafflers, the ones who caveat everything to the point that they cannot be held accountable, they're the ones we often call "slippery". They will, however, sometimes deliver something of value and then never let anyone forget it. These people have entire catalogs of accomplishments in their head, but have never failed and never been wrong. If you think that they have, they'll be quick to point out that in the particular case that you mention they never said they'd deliver, they said they'd try or they'd see what they can do or that it might be possible.
I'm pretty fortunate to have worked with a few people from the final category. The ones who commit and deliver. These folks are great to work with. They say, "I'll do X" and X gets done. Not always as smoothly as originally thought, not always as quickly as originally thought, but it gets done. It gets done without fail. No excuse, no ambiguity about whether or not they're on the hook for delivery, just straightforward "it will be done".
There may be other factors that shape and size your success, but I guarantee that if you simply commit to doing things and then deliver relentlessly that you'll succeed.
which is like walking into a Jenga game near the end. Actually, it's like walking into a game where most, if not all, of the original players have left because no one wanted to touch the unstable mess in front of them. In Jenga, the one who knocks the tower over loses. There are 2 ways to knock the tower over: by pulling out the wrong piece or by putting the piece in the wrong place. In other words you can lose by removing the wrong thing or adding the wrong thing.