DEV Community: Brendan Powers

Writing Effective Interview Questions

Brendan Powers — Mon, 03 Feb 2020 16:41:45 +0000

Do you remember preparing for your last interview? You might have bought one of the books on interviewing, or spent time practicing on sites like HackerRank or LeetCode. Perhaps you read one of the many articles on “The 13 most popular React.js interview questions!”. What was your interview experience like? Was it engaging and fun, or frustrating and disheartening? I certainly have memories of interviews on both ends of the spectrum.

What about the last time you were interviewing for a position on your team? How much prep work did you do? If you were anything like me, you’d start reviewing the resume and looking for a question about 15 minutes before the interview started.

Interviews seem like a burden. They’re a distraction from whatever you’re currently working on, but the outcome of the interview is just as important to you as it is to the person you are interviewing. The decisions you make during and after the interview will affect your work life for the next few years. Get it right, and you have a wonderful new team member, someone you love to work with.

With so much at stake, there’s surprisingly little information available for the people who are giving the interviews. I thought I’d share my thoughts on the subject. Hopefully, some people might find it useful.

Know why you are asking the question

Why do we ask technical interview questions? Think about the sorts of things you want to know about a candidate. Can you code? Do you have good debugging skills? Do you have good problem-solving skills? Unfortunately, you won’t get very far by asking these questions directly. Interviewing would be so much simpler if you could!

Instead, you need to go after the answers indirectly. You do this by asking the candidate to perform some task and then observe their behavior. That is the function of the technical interview question. It’s just an excuse to get the candidate to perform a task you can observe.

With this in mind, it’s important to know what qualities you are looking for before picking a question. You can then evaluate any given question based on how it might give you insight into those qualities. For example, let’s say you want to evaluate the candidate’s design skills. You might ask a question like this:

I have a Vehicle base class with these functions: make(), model(), weight(), hasTowHook(), canPlugIn(), hornSound(). Possible types of vehicles might include a sedan (Toyota Camry), a pickup (Ford F150), or an EV (Chevy Bolt). Design me a class hierarchy that represents these different models.

There are a couple of issues with this question, but the biggest one is that it doesn’t meet our requirements. It might be an adequate test of basic polymorphism, but it’s not complicated enough to get a good sense of a candidate’s design skills. A better question might be:

You're building a web UI for commercial property owners to manage their security cameras. Each camera has some properties (make, model, location, orientation, etc…). You'll also need to keep track of other objects, like users, permissions, buildings, recordings, etc. The application needs to be able to export a backup file. This file needs to be readable by newer versions of the application. Design a system to take all the cameras and related data, and write that file.

This is a much better question for evaluating design skills. First, the problem is more realistic. There is a lot of detail to be considered. What data format do you use? How do the objects relate to each other? How do you handle versioning and compatibility? Do you care about making the file easy to read, or making the size of the file small? There are many, many valid solutions to this problem. Exploring the possibilities with a candidate will give you a lot of insight into how they think.

If all you learn from a question is how many hours a candidate has spent on HackeRank, then perhaps it’s time to find another question.

The question should be relevant to the work the candidate will be doing

If the person you are interviewing gets through the interview and accepts the offer, you’ll be working with them five days a week for the next few years. You need to make sure they are comfortable doing the day-to-day work that makes up the bulk of software development.

If that’s the case, why do we so often ask about obscure topics during an interview? We try to asses whether a candidate has a strong background in computer science when in practice, it has very little relation to real software development. If you ask about theoretical topics, you’ll get a sense of the candidate’s background. If you ask practical questions that resemble the work you do every day, you’ll get a sense of what it’s like to actually work with the candidate.

Let’s look at a couple of example questions:

You are updating an existing REST request for your backend API when you notice that sometimes, the requests take a second or two to respond. You check your metrics dashboard and notice that your p90 latency looks good, but p99 is much higher than you expect. Where would you start your investigation?

If you’re a ruby shop looking for a backend engineer, this is a pretty good question. It’s quite likely that you’ve needed to debug a performance issue at some point in the recent past. Someone who is joining your team should be familiar with the process of debugging this kind of issue. On the other hand, not everyone has been exposed to latency percentiles. You would need to be prepared to explain the concept.

Now, let’s look at another question:

You are creating a new dictionary service, exposed to your users via a REST API. There are two requests. A POST request to add a new word to the dictionary and a GET request to get auto-complete suggestions when the user starts typing. Implement these two requests.

This one is a bit trickier. Depending on what you expect the answer to be, it could be a really great, useful question, or an irrelevant frustrating one. If you expect the candidate to take the words from the POST request, and add them to a database, then query that database with the GET request, then this is a great question. Building this sort of autocompleted search is a pretty common task for a Rails developer. There’s enough detail here to determine if the candidate is familiar working with databases, you can discuss the table structure, what indexes to use, and whether using something like ElasticSearch makes sense.

On the other hand, if your expected answer is to have the developer build a trie, and then use that for the auto-complete request, then you’re in trouble. If you were looking for an in-memory solution to the problem, a trie would be a great way to solve this particular problem, but tries are not a commonly used data structure. It’s unlikely that your average rails developer will ever need to use one. If a candidate fails to answer this question, have you really learned anything important?

There are good reasons for wanting to avoid databases in questions like this. You might be doing a coding phone screen, and adding a database might make the question too complex to implement quickly. In this case, implementing a simple in-memory solution is perfectly fine. When doing this though, stick with data structures that are commonly used in the work you do. For the vast majority of developers, this is limited to lists and hash tables. Depending on the language used, you might have a few different kinds of lists, and perhaps an ordered map. Queues are also a good choice. Other data structures commonly found in interview questions such as heaps, trees, and graphs are rarely encountered in the real world and should be avoided. If you can’t elegantly solve the problem without resorting to obscure data structures, then the problem is a poor choice.

If your candidates need to study for your interview, you are probably asking the wrong questions.

Make the question clear and easy to understand

Interviews are stressful! It can be hard to answer tricky technical questions when under pressure. Have mercy on the person your interviewing and spend some time making sure your question is clear. Not only will they appreciate it, but you’ll have a much better chance of getting a useful answer.

How do you know if your question is clear? Test it! We test our code, why not do the same for our interview questions? Ask a teammate the question and see how they do with it. This is great for two reasons. They’ll usually be honest with you and let you know what they think, and now you have a baseline to use when you ask the question in a real interview. Once you’ve done this a few times, you’ll start to get a feel for the process.

Friends don’t let friends ask buggy interview questions.

Leave room for side conversations

Some of the best interviews I’ve been involved in are ones where the conversation veered off track into an interesting side topic. For example, in a recent interview, I asked a candidate how to make a piece of code he’d just written thread-safe. The obvious answer would have been to add a mutex. Instead of giving the answer I expected, he pointed out that if I cared at all about the performance of the code, it should never be run from more than one thread. We then got into a conversation about how modern multi-core CPUs handle caching, and we discussed various methods of getting data in and out of the thread running the code efficiently.

This wasn’t the answer I expected. Instead, I got a great conversation that gave me a lot more insight into how the candidate thought. It was also a great opportunity to have a conversation outside the formal bounds of an interview question.

If you get an answer you didn’t expect, dig a little deeper.

Conclusion

I hope this post has given you some things to think about the next time you’re giving an interview. If nothing else, don’t pick the first acceptable looking interview question you find 15 minutes before the interview starts. Take a little time to think it through. Test the question with a colleague. The person you are interviewing will appreciate the effort.

Burn Your Backlog

Brendan Powers — Sun, 15 Dec 2019 13:48:45 +0000

Somewhere out there are teams with a meticulously groomed backlog. They spend time each week going through their backlog with the team’s product manager, stories prioritized, tech debt is taken care of, and old or unnecessary stories pruned. Sprint planning is a breeze, and everyone goes out for cupcakes afterward. If this is your team, feel free to stop reading now.

Unfortunately, I’ve never experienced this kind of backlog grooming nirvana. I’ve been on many high functioning teams, some of them with agile processes that worked quite well. Every one of them suffered from an ever-expanding backlog, always creating new work faster than they could complete it.

Why should you care about a messy backlog? Well-groomed backlogs tend to be small, and small backlogs are a real advantage. It’s much easier to manage a small backlog. You can sort the items by their priority, determine where new issues fit and plan for the next sprint in a few minutes. If your backlog is small enough to fit in your head, then you can reason about it as a whole and make decisions quickly. Each new story in your backlog makes it a little harder to manage, so it’s critical that each issue be worth the cost.

If it’s so important to keep your backlog focused, why does it always become an unmanageable mess? Generally, this comes from planning too far ahead. You add a new story or plan a new feature in the anticipation that you’ll need it in a few months. Once created, you quickly forget about it. You might occasionally run across the story and think, “Oh yea, we should get around to that at some point.”. Congratulations, you’ve just created a zombie story, doomed to roam your backlog in search of a brain to distract. If you find yourself doing this, it’s time to take out the proverbial shotgun and put it out of its misery.

So often, we find it hard to dispose of issues that are no longer relevant. We hang on to issues, worrying that we might lose something valuable if we closed them. We create new work faster than we can complete it. After a year or so of doing this, we end up with a backlog worthy of a Hoarders episode.

When I’m worried about something, I like to think through the worst-case scenario. These “worst-cases” usually aren’t as bad as we feared. So let’s try a thought experiment. What if you lost your entire backlog. All of your stories, sprints, and epics deleted with no backups. What would you do?

You’d probably start by re-creating the current sprint. Then you’d work from your roadmap or memory to re-create any near-term projects. You might also re-create any memorable feature requests or cleanup items.

What about all the issues you forgot to re-create? What if you forgot something important? While it’s reasonable to worry, important tasks have a way of making themselves known. If it’s important, it will come back up in a meeting, a user will mention it, or you’ll remember when you run across some troublesome bit of code. If you don’t remember to re-create an issue, and it never comes up again, have you lost anything by forgetting it?

I’m certainly not suggesting you go out and delete your entire backlog. Think of it more as a short-cut for determining whether the issue matters. Consider what would happen if it was gone. If you think you’d end up re-creating, then keep it. Otherwise, close it, and leave room in your head for the issues that have a real impact.

Pretty Printing CRDs with Kubebuilder

Brendan Powers — Sat, 02 Nov 2019 17:53:45 +0000

If you’ve developed a CRD with Kubebuilder, you know how nice the code generation features are. It lets you define your CRD using standard Go object, and then add additional information like documentation. Did you know, that you can also control how kubectl prints your CRD as well?

Let’s look at an example from my Codebook project. Codebook is designed to bring up a set VS Code Server instances for use in training classes. In this project, I have a resource called Group. The Group resource is where I store collective information about a class. For example, what image should be used, how long any instance is allowed to run, resource limits, etc… When I list Groups with kubectl, I get something like this:

$ kubectl get groups
NAME        AGE
default     2d15h
testgroup   61s

This is useful, but not all that informative. I know that I have two groups, and how old they are. To get more information, I’d need to do a kubectl describe for each instance. This will quickly get tedious. Since groups contain sets of VS Code instances, I’d really like to know how many instances there are, and how many are running. Let’s look at the status object for a Group.

// GroupStatus defines the observed state of Group
type GroupStatus struct {
  // +optional
  Instances []GroupInstanceStatus `json:"instances,omitempty"`

  NumInstances        *int64 `json:"numInstances"`
  NumRunningInstances *int64 `json:"numRunningInstances"`
}

We have to properties (NumInstances, and NumRunningInstances) that have what we need.
We can use the +kubebuilder:printcolumn annotation to tell kubebuilder to add the needed information to our CRD. I place them right after the +kubebuilder:object:root=true annotation.
For example, let’s print the number of instances.

// +kubebuilder:object:root=true
// +kubebuilder:printcolumn:name="Instances",type="integer",JSONPath=".status.numInstances",description="Number of instances in group"

// Group is the Schema for the groups API
type Group struct {
...

The printcolumn annotation has a few different options, we only used a few in this example:

name: This is the title of the new column, printed in the header by kubectl.
type: The data type of the value being printed. Valid types are integer, number, string, boolean and date.
JSONPath: This is a dot notated path to the date you want to print. In our case, the numInstances property in the Status object, so we use .status.numInstances. Notice that we use numInstances, not NumInstances. The JSONPath property refers to the generated JSON CRD, not the native Go classes.
Description: A human-readable string describing the column. I don’t actually know if these are printed anywhere, but I leave them in just in case.

Now that we have our annotation created, we can run make install, and try listing our CRD again.

$ kubectl get groups
NAME        INSTANCES
default     2
testgroup   1

Cool! We can now see the number of running instances in each group. Where did the Age column go though? It seems that when you start adding custom columns, any default columns are no longer shown (aside from Name, I guess). So let’s add the Age column back, and we can add the number of running instances while we are at it.

// +kubebuilder:object:root=true
// +kubebuilder:printcolumn:name="Instances",type="integer",JSONPath=".status.numInstances",description="Number of instances in group"
// +kubebuilder:printcolumn:name="Running",type="integer",JSONPath=".status.numRunningInstances",description="Number of running instances in group"
// +kubebuilder:printcolumn:name="Age",type="date",JSONPath=".metadata.creationTimestamp"

// Group is the Schema for the groups API
type Group struct {
...

Run make install, and then list the groups again.

$ kubectl get groups
NAME        INSTANCES   RUNNING   AGE
default     2           2         2d16h
testgroup   1           1         31m

Awesome, we now see the number of running instances, and our age column is back. This is a lot more useful than what we started out with. It could be more useful though. What if we wanted to know more than just the current status of the Group? It would be nice to tell them apart in some way. One of the ways we could do that is to display the image for each Group. The group object is not in the status, it’s in the spec. This is not a problem for column annotations we simply use .spec instead of .status in the JSONPath property. The new annotation looks like this:

// +kubebuilder:printcolumn:name="Image",type="string",JSONPath=".spec.image"

When we list our Groups again, we now see the image!

$ kubectl get groups
NAME        INSTANCES   RUNNING   AGE     IMAGE
default     2           2         2d16h   codercom/code-server:v2
testgroup   1           1         36m     codercom/code-server:v2

This is useful to know, but perhaps it’s a bit much for the default output. What if we’d like to hide the field, and only show it when requested? This is where the priority field comes in. We’ve left it out so far, and each of our columns has the default value of 0. If you set priority to any number above 1, it will only show up when you specify -o wide. Let’s try it:

// +kubebuilder:printcolumn:name="Image",type="string",priority=1,JSONPath=".spec.image"

When we re-run kubectl, we no longer see the image column.

$ kubectl get groups
NAME        INSTANCES   RUNNING   AGE
default     2           2         2d16h
testgroup   1           1         31m

When we add -o wide, the field shows up again:

$ kubectl get group -o wide
NAME        INSTANCES   RUNNING   AGE     IMAGE
default     2           2         3d16h   codercom/code-server:v2
testgroup   1           1         24h     codercom/code-server:v2

That covers most of the features of the printcolumn annotation. If you’d like a little more detail, check out the CRD docs on the additionalPrinterColumns field.