Go Interview Walkthrough

The code walked through is available here

So turns out it was two years ago—I can’t believe it was that long ago—but I created this repo which was intended to help people prepare for a GoLang interview.

I’ve heard from a few folks and a few companies that they’re using a similar approach to this, so I wanted to do a walkthrough about how to approach exercises like this to hopefully help you prepare for your next interview as a Go engineer.

What we’re gonna do is we’re gonna pull this code base, and I’m gonna show you how I would approach a sort of problem where I’m shown a blank code base and asked to give feedback on it.

This would typically show up in an interview process as a code review of sorts—you know, “review this code, let us know any recommendations,” and then usually an interviewer will probe you as you go, asking questions about specific areas.

As I walk through it, I’ll try and call out where the different levels of answer you might give—so you know what a junior engineer should give, a mid-level, and a more senior engineer. I hope you find this helpful.

Let’s switch into GoLand and start going through it. Okay, so the first thing I would do upon cloning the repo is jump into the README.

This already shows some understanding of how to navigate unseen projects. For a junior engineer, you’re already getting a tick in the box. For mid and senior, this is table stakes—you should be doing this.

The next thing we want to do to get another tick in the box, if possible, is to get the project running—or maybe run the tests, depending on its complexity. In this one, it makes it pretty clear that it’s easy to get started with.

So what we’re going to do is get this started now. The next thing I’m gonna do is go to main.go and just hit this run button.

It looks like we’re in business now. Immediately, there’s some interesting things we should talk about. It says “database migration complete.”

As a mid-level to senior candidate, this might be a good place to pause—without even looking at the code—and talk about the consequences of doing database migrations upon app startup.

There may be times when that’s appropriate, but there’s always trade-offs to be had here. For example, if we make a breaking change—like a column migration or rename it—and we do that within our app, and we’ve got multiple pods running in something like Kubernetes, we might take all of our apps down by doing that migration.

We should discuss that. A more junior candidate may call out that we’re starting an HTTP server and we don’t give the port it’s running on, which might be really useful—so there might be a point of discussion there.

Generally, as you navigate the project, just talk through everything you’re thinking, and if the interviewer is interested, they’ll follow up.

So let’s go back to this now. We’ve got a curl request to make. Let’s make a new terminal and run the curl request.

You can see we’re getting IDs back with “1% back.” We may want to talk a little bit about this—there’s actually tons to talk about in this exact POST request.

Firstly, the username doesn’t seem to have to be unique, which sounds like a huge problem looking at this immediately. I would expect all levels of candidate to probably spot this—maybe more mid-level and senior candidates can dig a bit deeper into why it’s important to have uniqueness.

Really senior candidates might also talk about how we’re doing this over HTTP rather than HTTPS. You may wanna talk about the percent symbol—why is that happening?—and also the fact that it does seem like we are leaking information about our system.

Senior candidates, I would expect to talk a little bit about the consequences of leaking that and what it might mean to tell everyone how many users we have in our system and why we might not want to do that.

So we’ve got it running, we’ve seen how it works, so let’s jump into main.go and look at some of the code. I’ll typically always start in a main function. You probably saw I kind of did it naturally then.

Go is great in that it has a single entry point, which is always going to be main, so make use of that—start here and do all your looking around from here as a starting point. All the logic is going to be stacked here, and so it’s really useful.

The first thing I would call out here is runMigrations doesn’t return an error—that’s kind of unusual to me. I wouldn’t really say anything yet, but I would just make a note of that in my head or maybe even say out loud to the interviewer, “It’s interesting that we are running migrations and not returning errors.”

Now, some companies or coding patterns might be fine with not propagating errors in local main functions and handling all the errors here—again, it’s a point of discussion.

I would expect all candidates to be able to talk about why we probably shouldn’t be hardcoding credentials into a function like this—talking about running it in different environments and why this has made it really challenging.

Mid-level and senior candidates, I’d expect to call out specifically the fact that we are hardcoding a password especially, and why we shouldn’t do that.

For more senior candidates, I’d love for them to zoom in and talk a little bit about how we can do better secret management. You may talk about Vault or something like that and maybe share some of your experience with it.

Generally, when we’re figuring out the more senior candidates, it tends to start with a story about when they ran into this issue in the past and how they’ve solved it in production—so it’s showing evidence that you’ve got battle-tested experience, not just saying things you’ve read.

I’m gonna zoom through this function a little bit just because it’s not that interesting until we get to here, but you can see that we are running a migration here, we’re doing no checks to see if it’s a breaking change or anything like that.

This might be a point of interest to talk about the downsides of potentially doing breaking migrations. Again, senior candidates, I would expect you to have a story, probably of when you’ve done this and it hasn’t worked out.

Junior and mid-level candidates may talk a little bit about this and why we may want to have this passed in as an environment variable as we may change it depending on where we’re deploying it—but not that interesting.

Something else to talk about is what happens if the migration fails at some point. So that’s enough about migrations.

The next thing we’re gonna talk about is the user.NewService. Now, I would expect more junior candidates to be able to jump into this function and talk a little bit about it, which we will do in a second.

The more astute people reviewing this will notice that we’re passing in a username and password here, and we’re using a different one here, and from that we can probably assume we’re making two different database connections. It’s also not clear that this function is going to be creating a database connection, so there’s something to discuss here.

There may even be a small and quick refactor we can do together to make it so we make a connection or a connection pool and pass it through into our application layer.

So again, more senior candidates, I would expect to dig into the separation of concerns, the difference between a connection and a connection pool, and the benefits.

Whereas more junior candidates, I would expect just to jump into the function here and talk a little bit about the problems in this. One thing I’ve noticed is we’re validating dbUser, but we’re not validating dbPassword, so we’re not being consistent here.

There’s a small refactor we could make together to make sure that we’re validating both parameters being passed into this function, which I think is valuable.

I mentioned it briefly before, but we probably don’t need to pass a dbUser and a password—we can probably just pass in the connection, which I think is a better separation of concerns and would allow us to mock and test better in the future.

I’d expect junior engineers to think a little bit more about passing the database in. I’d expect more advanced candidates to talk about testing and testability of doing that dependency injection.

Next thing which I would expect at least mid-level candidates and up to spot is the inconsistency in code styles here. Here we’re making a NewService function, here we’re not making a NewHandler function—so I think that’s interesting to discuss.

I think consistency is really important, and I always love candidates who call out coding consistency and can talk a little bit about how it can help you scale as an organization if you have standards here.

Let’s jump into the AddUser function. We can see here we’re defending against different HTTP verbs. All levels of candidates might want to discuss a little bit about the HTTP verbs and when to use them and why we might want to do this—but this is generally interesting.

Decoding here—I don’t have too much to say here, I think this is mostly fine. Then we’ve got this AddUser function.

For people with a little bit more Go experience, they may call out the fact that we’re not handling the error here, and we’re actually getting lint warnings because of it. You’ll see people underscore the error here, so it might be interesting to discuss nuance around that.

You’ll also notice that we’re missing returns at the end of these functions, at least, which means we might fall through into here—so this can lead to a bad situation occurring. We should talk about that.

It’s kind of hard to spot, so don’t begrudge anyone for not necessarily spotting it. One final thing we might talk about here before moving on is that we’re taking a message from here and writing it directly to the user—we’re doing no transformation or anything.

Again, this might leak information—and in fact, we know it is—so this is worth discussing as well. It’s like separation of concerns between layers.

Let’s jump into the AddUser function, and it looks like we’re opening another database connection. So we’re loving making database connections here.

We could talk about some of the other issues we’ve seen here. We’re also panicking here even though we could return an error. Some people might argue that if we are committing to this pattern, we probably should panic here because this is unrecoverable—but this should be some nuanced discussion to be had about panic here.

Junior engineers, you may just call it out for its inconsistency. Mid-level engineers, I would expect you to maybe talk about how to propagate errors up, and senior engineers maybe can have a more nuanced conversation about when panicking might be okay.

Next one is—I would expect all candidates, hopefully, to spot, and it’s probably one of the really important ones—is this is not a safe SQL query. It’s susceptible to SQL injection, and so we should talk about that, the risks, and how to defend against them.

Junior-level candidates, I’d expect you to be suspicious of this query. Mid-level, I’d expect you to be able to identify it. Senior candidates, I would expect you to maybe come up with some ideas about how to prevent anyone making this mistake.

You may talk about checks in CI or automated code scanners—things like SonarQube or Snyk—that can detect these issues and block your MR or pull request.

After that, not too much to discuss. You might want to call out some good things you see too—it’s not all about calling out bad things. We’ve had some good separation of concerns between layers here, and we’re wrapping errors here to pass more context up, so you may want to talk about that a little bit too.

Jumping back into here, the last two lines to look at are starting the server and the ListenAndServe. So again, you may talk a little bit about how to pass in a port—‘cause we may need to change it in different environments.

You may also talk a little bit about frameworks here—we haven’t really used one. I’m always open to talking to candidates about why they don’t want to use the standard library and what advantages they might get from using other things.

One thing that we are using here is PQ. Various astute people will know that PQ is end-of-life—it’s not currently supported anymore—and using PGX and making a pool is probably a better idea.

So don’t be afraid to even look at things like the imports to talk about things that might be able to be improved here.

But I think if you can catch, you know, nine or ten of these—and if you’re in a 30-minute-long interview—I think you’ve got a pretty good shot of passing this interview.

I would expect the interviewer to probe you on everything you suggest and kind of dig to a depth where you get to a place where you’re willing to say, “I’m not really sure about that,” and that’s totally okay for all levels.

For senior levels, you should probably know the answer to pretty much everything here, and if you don’t, it’s definitely worth spending some time reviewing and discussing some of the things I discussed here.

For mid-level candidates, it’s totally okay to say, “I’m not sure,” or “I don’t have experience with that” at various points. And for more junior candidates, I’d just be really happy that you’ve got awareness to call out some of these things, even if you don’t know what the correct solution is.

So I hope this was helpful, and you absolutely kill your next interview!