C# Corner

Tips for Snagging That Senior Developer Job

You're vying for a senior developer position. Here's what you need to know to win over your interviewer.

• By Patrick Steele
• 06/10/2015

There comes a time when you decide to leave your current position. Perhaps it’s not as challenging technically or maybe the environment has changed. Maybe your employer is moving to a new technology stack and it’s not something that interests you. Whatever the reason, leaving one company and joining another is a big step. You want to make sure you find a company you’ll enjoy working at for a long time.

I’ve spent many, many hours interviewing developer candidates. In this article, I’m going to look at some of the practices my employer has put in place to help us find developers who will work best for our company.

Phone Screen
Everything starts with a general phone call with our HR department. I won’t cover the details of that. I get to talk with the candidate once the HR team has decided to move the candidate forward in our process. For my part, I take about 30 minutes to do a simple phone screen. I’ll ask some technical questions about C#, the Microsoft .NET Framework, programming patterns and so on. I’ll also ask some opinion questions (example: LINQ method syntax vs. query syntax -- pros and cons?). I don’t just want someone who can rehash the MSDN documentation. I want to know you think about things and have opinions.

I’ll also spend a little bit of time talking about our software: the general architecture, other systems we integrate with, the code base and so on. Nothing too deep here (remember, it’s just a 30-minute phone screen), but it can help the candidate learn a little more about the environment into which they’re getting. At the end, I leave some time for the candidate to ask me some questions. It’s imperative that this process is a two-way flow of information and communication. Both the candidate and the company are looking to make a big change here.

Meeting the Team
Most developer positions will be on a team. That team has to have cohesiveness if it is to produce good-quality code. Ideally, any type of on-site interviewing will be done with a majority of the team. There may be some scheduling conflicts, but a time should be found that’s convenient and works for everyone so they can spend some time getting to know you -- and you, them.

Take this time to learn some of the dynamics of the team. If there’s not a lot of conversation going on and no one is really engaged in the interview process, that could be a red flag. These should be people who want to be there. They enjoy their job. They should want to be engaged and active in the process of hiring their next teammate. If something doesn’t feel right, it probably isn’t. Feel free to ask questions: A good company knows you’re interviewing them as much as they’re interviewing you.

Whiteboard Some Code
At some point in the interviewing process, you should be writing code. Maybe they sit a laptop in front of you and ask you to code something, or maybe it’s just scribbling on a whiteboard. Either way, you need to be comfortable writing code in front of other people.

Don’t worry about missing a semicolon here or there on a whiteboard. A good interviewer is looking for the intent of your code, not syntactical correctness: I leave that to the compiler and the IDE. I want to see how you form the structure of a solution. Then I’ll throw some curveballs and see how you react; see how your code changes; how it adapts to new requirements.

This goes without saying but I’ll say it anyway: Know your .NET! If you use an ArrayList to hold on to a collection of integers instead of a List, I’m going to ask you about boxing and memory management. Be prepared! I will ask you about subclassing and virtual methods. I will have you writing overloaded constructors. You will not only be writing code, you may have to execute it in your head. If I see a problem with something you’ve coded on the whiteboard, I may write a few lines of code myself that consumes your code. I will point out that my code will throw an exception based on the way your code is currently written. I don’t want that exception to happen. Find the problem, identify it and fix it.

Consequently, I will not be asking you about .NET remoting. I won’t ask how fluent you are in writing Silverlight apps. “Client Server” will not come up in the interview. All of these things (and others) were relevant many, many years ago, but not today. If a company is asking about dated technologies, it could be that they’re looking for someone to maintain them. If this is the case, they should be up front about it (see “Transparency” later in this article) and should be willing to answer any questions you have about it.

Be ready for multiple languages. Remember in the phone screen when I said we integrate with SQL Server? Yeah, be ready to write some SQL. And I mean real SQL, not nHibernate or Entity Framework wrapper code. I’ll be asking you to write SQL that needs outer joins, inner joins, aggregation and so on. You may be able to do what I ask with an inner query and that’s fine. But I may ask you to rewrite it without an inner query. Be prepared.

Anyone can get nervous in an interview. Don’t let it get to you. Again, a good interviewer will put you at ease and let you take your time. If I can see a candidate is struggling with something, I usually don’t help them out. I want to see how they attack the problem. They’re free to ask me any questions they want. In fact, I’m going to be a little nervous if there aren’t any questions -- I’m usually vague on purpose. You’ll need clarification on some things and I want to make sure you’re paying attention enough to ask for it.

Transparency
Finding a company that has a pristine code base with 100 percent unit test coverage, one-click deployment to any environment across all platforms, 100 percent compatibility across all browsers and a Keurig at every desk is going to be really, really hard to find. While we would all like to find a company with no legacy code, very few exist.

There’s no doubt you’ve heard the term “technical debt.” Much has been written about it in the past five years. It slows you down, it costs the company money and it’s hard to maintain -- and that’s just scratching the surface. But let’s be honest: The reason so much has been written about it is because it does exist in a lot of companies. The last thing you want to do is hear all about unicorns and rainbows in the interview process and then find out you’ll be spending time maintaining some VB6 code that occasionally calls a .NET DLL that’s sprinkled with enough attributes to make it mildly usable in a COM environment. Yuck!

Almost every company has some technical debt and a good company should have no problem admitting to it. At Billhighway, we’re all C# developers. We’re not elitists or Visual Basic .NET-haters, we just prefer C# as a development language. However, one of the projects we have to maintain is a large Web site that has a sizable chunk of its code in Visual Basic .NET. All of the services and a lot of supporting libraries are written in C#, but there’s still Visual Basic .NET lying around. A good company should have no problem letting you know there’s technical debt and how they handle it.

Ask Questions
While this might seem obvious, I’ve been in a lot of interviews where I’ve left time at the end for the candidate to ask me questions and they have nothing to ask. While I like to think I’m a good interviewer, there’s bound to be something I missed -- something I meant to cover but didn’t. I want you to know what you’re getting into. If you’re not going to ask any questions, it makes me wonder if you’re just looking for a paycheck.

Questions about travel? Ask. Questions about holidays? Ask. Insurance questions? Definitely ask. If I can’t answer the question, I’ll find someone who can. If a company doesn’t want to take the time to answer your questions now, when they’re trying to attract you, how likely are they to answer them after they’ve already got you? Remember, an interview is a two-way flow of information.

This Will Take Time
Team interviews. Whiteboarding code. C#. T-SQL. Q&A. Yeah, this isn’t going to be a one-hour interview. At Billhighway, when we get to this stage of the interview, we try and reserve a four-hour block to get through all of this stuff. We don’t want to rush it and we want you to get a feel for what your day-to-day life as a developer will be like.

I still find it amazing that some companies will do a quick phone screen, a 1 to 1.5 hour interview and a few days later make an offer to someone. How much can you really learn in that time? I know I’ve done it that way in the past and it seemed “normal.” But after being part of an extensive interview at Billhighway, I can’t picture doing it any other way. Again, a big commitment like this should be well thought out and researched thoroughly.

Switching jobs is a big decision that shouldn’t be taken lightly. Make sure you know what you’re getting into. Take the time to know the company you’re interviewing with -- and make sure they’ve taken the time to get to know you. Don’t jump simply because you’ve got an offer. Investing some time now saves everyone a lot of time down the road.