Internal interviews as a consultant

Updated: July 19, 2024 @ 0930

When I worked for FinTech and the Team Leader role came up, I had to interview for the position. It was expected, so I didn’t give it much thought, and a mentor helped me prepare, so it was all good.

As a consultant, there are times I have to do interviews, both internally for other teams, and externally with clients. It frustrates me a bit because I already have a job - it’s not like it’s a fundamentally different role from what I do day-to-day, but I get it; they want to know if someone will be a good fit on the team and need to check tech skills and personality.

Since I’ve been at my current job, I’ve had to do this a few times. Some have been good, some not so good. Some have been conversations staying at a higher level, and some have been deep in the weeds.

In the weeds

One client I interviewed with is notorious for really difficult interviews. Of course, I didn’t find this out until after the first interview, only to find out they wanted round 2 the following day. The questions were interesting, including this gem:

How would you rebuild reddit?

I had to laugh at that one, but I struggled through as we really focused on database design. I remember one day was focused on databases and the second day was more focused on .net. Both days were tough, and I do remember feeling pretty down on myself for what I considered a pretty poor performance. I mean, I didn’t land the gig, but when the account rep told me of their reputation and that very few made it through, I felt a bit better. It was a learning experience for sure.

Can you walk the walk and talk the talk

Today I went through another one, but with an internal team looking to staff up for a client engagement. I honestly didn’t realize it was an interview until it started since the meeting request said something like, “A get to know you meeting.”

After some preliminary discussion about the project, with them frequently checking with me to make sure if sounded like something I wanted to pursue, they started asking lots of great questions about how I approach projects, how I work with more junior developers, my thoughts on quality and testing, and more. I feel like some of the questions would make good blog posts, so stay tuned!

At one point, they sent me a link for a shared coding editor that had a problem statement written out in the comments. It revolved around parsing a string for substrings that met certain conditions. The instructions gave two examples, one really simple and one more complex.

Talk, Talk, Talk

They asked how I’d approach the problem, and of course, wanted to hear me talk it out. I only wrote a little code, but talked my approach all the way through. The problem itself was interesting and I think I did really well. In fact, at one point (when I took a breath), they said that in the first few minutes I answered almost all of the questions that other candidates normally miss, or that takes them a long time to get to.

Obviously I felt good about that, but I also felt disappointed that other developers would miss such simple concepts.

TDD and more

From the start, I let them know that my background is with TDD; yes, the whole red-green-refactor workflow, but I said in the big picture I didn’t care if developers wrote tests before, after, or during, as long as they wrote tests. Obviously, TDD offers benefits I find valuable, but I’m also not a zealot about it.

I talked about how I’d start with a test, then write a naive implementation that immediately checked for invalid conditions (input being null or empty, input not having any of the characters included in the requirements, etc.) which led to a discussion about whether I’d throw exceptions or just return an error code since the method returned an int. I mentioned how I’d use the XUnit [Theory] to allow me to test variations of the input, and then we talked about how I’d integrate those tests into a pipeline. That led to a discussion of code coverage, and the use of tools like Sonar.

Naming things

They asked me about naming, so I talked about that, explaining (and showing) my normal style. I did make it clear that I would match a codebase’s naming convention unless it was absolute garbage in which case I’d do my thing and then discuss it during code review, trying to bring the team up a level in the process.

Performance

They asked about performance considerations, and I answered that with a big “it depends” because it does! I said I’d ask if the “thing” I was writing was going to run once a week in some batch job at 2am or if it was going to be run every minute on the minute because it matters. We talked about the happy path, the bad path, and edge cases.

At some point, I’ll tackle this problem on my own and post it somewhere because it is an interesting problem, and I think it’d be fun to work on.

Imposter time

Oh, at one point, they asked me about Big-O notation and I was honest - I am a self-taught developer and that’s not something I can recite at the drop of a hat. I always end up referring to Rob Conery’s The Imposter’s Handbook. They seemed cool with that answer.

Final Thoughts

Interviewing for a job within the company you work for can be a strange experience, but it’s also good to have those kinds of checks every now and then. I’m not sure where this one will lead, but I definitely feel good about it, much more than the one I described earlier in this post.

Make sure to check out How to have a better interview for some tips and tricks I’ve learned over many years of conducting interviews and being interviewed.

I hope you enjoyed this post!

---