Questions to Ask During a Software Developer Interview

During an interview you should not only try to sell yourself as the best candidate for the job. You should also make sure that the company is somewhere you want to work. Listed below are some questions to ask during your job interview so that you can make sure working at the company is going to be an enjoyable experience that allows you to grow.

What project methodology does the company use?

Does the team you’d be in use waterfall, scrum, kanban, or some other methodology? Knowing what methodology the team uses will let you know what you can expect from a planning side. You should also have follow up questions that are aimed at finding out how well they follow the methodology. The interviewer may say they follow scrum, but additional questions can help you figure out if they actually follow scrum, or just say they do. Some follow up questions could be:

  • How successful have you found the methodology to be?
  • What are problems you’ve faced or are currently facing with the methodology?
  • If they follow scrum, the do they have a scrum master?
  • How long is each sprint?
  • Do they track metrics, like velocity, capacity, or burndown? How do they use those metrics for planning for the future?

Does the company use Devops?

Having a CICD/devops pipeline set up allows for teams to work faster and produce higher quality code. The company’s use of devops can give you an idea of what the company values the most (speed, quality, long-term planning, automation).

You should ask for details to get an idea of how far along they are with devops. The company may have a build server who’s only function is to build the code, or the company may have an pipeline set up that takes the code a developer commits, runs tests against it, pushes it out to multiple environments, versions it, and/or makes the package ready for end-user consumption. If the interview says they have devops set up and they only have the former but you are expecting the latter, then you’ll be very disappointed when you start the job. Here are some more detailed questions you can ask.

  • What kind of build server do you use? Jenkins, TeamCity, Bamboo, Azure Devops?
  • Have the interviewer walk you through the pipeline. How does a commit from a developer make it to the end-user?
  • What can still be automated?
  • How has the pipeline helped your team?
  • Do developers maintain the pipeline or do you have a separate Devops team?
  • Do you use an artifact repository?

How is the code kept clean?

If the code isn’t clean, it’s hard to work with. No developer wants to work with spaghetti code. To that end, you should find out how they keep their code clean.

  • Are unit tests required? What about integration tests?
  • Is code coverage tracked?
  • Do they follow good coding principles, like SRP and DRY?
  • Do they use design patterns?
  • Do they have code reviews? What stops low-quality code from making it into the main branch?

How is developer input used for planning?

As a developer, you want to know how much influence you have on the planning process. Ask how deadlines are set. For example, if a client wants some feature, will your boss ask you and the other developers how long you think it will take? Or will he just set an arbitrary deadline? You should find out what factors are used to plan a feature’s deadline and priority.

How are efforts that don’t directly benefit the customer planned? If you and your team really want to start setting up a CICD pipeline, or refactor a part of the code, or write more automated tests, how is time for those efforts planned?

Questions like these don’t only let you know how your input influences planning. They can also give you some insight into how much your opinion in general matters. Will your boss listen to you if you explain the benefits of automation and testing? Will he listen when you explain how a feature is more complicated than he thinks? Your boss should not only listen to you, but also take action.

How do developers stay up-to-date?

The company you work for should help you continue to grow and learn as a developer. Not only you, but your coworkers should be open to continually learning. A coworker who is set in his ways and refuses to learn new technologies can be very difficult to deal with. You should ask how the company facilitates growth as a developer.

  • Will the company send you to conferences and/or workshops if you ask?
  • What websites or books does the interviewer and/or coworkers already working there recommend? They should be able to name a few.
  • How are new technologies and processes viewed in the company? Ask for specific examples.

What’s the career path for a developer?

Ask the interviewer what a developer’s advancement opportunities are. If you want to code for your whole career, but the company only offers advancement into management, then you may want to look elsewhere.

  • Do they have senior developer or architecture roles? What are the specific requirements for these roles?
  • If you want to advance into management, what are your options. If you want to stay technical, what are your options?

What’s the company’s view on work-life balance?

You should ask how many hours someone in the position you’re applying for works a week. Some companies expect their developers to work way more than 40 hours a week on average. Even if you’ll normally be working only 40 hours a week, crunch times happen. How often do they happen and how many hours does someone in your position work when they happen?

Are you free to work on hobby projects?

If you have hobby projects, such as an app, library, blog, or invention, then you’ll want to make sure that while you work at that company you maintain ownership over them. Some companies will have you sign an agreement that says anything you produce the company owns, even if it’s outside of working hours and doesn’t use any company resources.


The point of all these questions is to find out what your day-to-day experience will be like working at the company. You want to make sure you’ll be happy and respected while working there. Asking these questions can also demonstrate that you’ll be a valuable asset to the company.

Software Tools/Concepts I Wished I Learned About In College

College prepared me to enter any kind of software job I would want to enter after graduating. I had the tools I needed to get a job in web design, embedded systems, or anywhere in between. I mostly wrote code in object-oriented programming languages, but I had a occasions where I wrote code in F# (a functional programming language), assembly, and got to try aspect-oriented programming in Java. I had many hundreds of hours of debugging code under my belt by the time I graduated, which made me confident that I could find and fix any bug in any program.

There is an enormous range of topics that professors need to teach students in the 4-5 years that the students are there. They can’t go over everything that you may encounter in any software job. Plus, technology is changing so quickly it’s hard to keep up. However, after working in the industry for 4 years now, I have some suggestions for new graduates and people who are just starting their first software job. These are topics or tools that where either not covered at all, or in my opinion not covered thoroughly enough when I was in college. I believe these topics and tools are incredibly valuable in most software jobs.


Back in school, programming assignments would usually consist of getting the specifications for the program to be written (the sample output being the most important part), writing the program, submitting it, then forgetting about it. Doing this for 4-5 years may make you think that when you’re working at your job, you just need to worry about coding. You’ll need to add new code for new features, or modify existing code to change features or fix bugs. But there are so many other activities you’ll be involved in, or at least need to be aware of, as a developer. These activities include, but are not limited to the following.

  • Updating a test machine with the latest build.
  • Deploy the latest build to a customer, including any configuration updates.
  • Versioning and storing all the builds in the correct spot. All versions should be easily accessible. It should be easy to see if a build is a snapshot or release. It should be easy to figure out which build introduced a new feature (or bug).
  • Creating new virtual machines for various people.
  • Regression testing. When you check in new code you probably tested the new feature, but you probably didn’t test all of the existing features to make sure you didn’t break them. Or what if code that another developer checks in breaks your new feature?

The above activities are also prone to error. A developer may accidentally update the wrong machine, or not update it correctly. Configurations are easy to get wrong. It’s easy to forget to test something. This is where devops comes in.

Devops is a set of practices with the goal of delivering software that is high in quality, as fast as possible. In devops, we want to automate as many processes as possible. All of the above activities I mentioned should be automated as much as possible. For example, when a developer checks in new code, a build server should automatically make sure the code compiles, and then run a regression testing suite. If any of the tests fail, an email can be sent to the developer telling them that their new code broke something. If all the tests pass, the new build can be automatically versioned and uploaded to an artifact repository. Then the build could be deployed to a test box automatically.

In devops, we use build servers and scripts to automate as much of the development process as we can. Ideally, developers can just focus on coding and have everything else be automated. Other processes that could be automated include the following.

  • Run integration tests nightly (because integration tests can take a long time)
  • Run static code analysis, using SonarQube for example.
  • Spinning up a new virtual machine.
  • Generating release notes.
  • Only allowing commits to your main branch (master) if all tests are passing.

Devops was a word that I don’t remember ever being brought up in college. Neither was continuous integration, continuous delivery (CICD). The words “build system” may have been mentioned once or twice, but I never understood what it meant. Now that I’ve had a couple real software jobs, I understand how important it is. I wish that in school we had the opportunity to set up a simple build server. For example, for one of our projects we could have set up a Jenkins server and created a simple job that compiles a simple program and runs a few simple tests whenever there is a new commit.

Design Patterns

Design patterns are solutions to common problems in software design. Observer, dependency injection, visitor, and factory are all examples of design patterns.

Design patterns were covered briefly in my schooling. I can remember two occasions. On the first occasion my professor just had a slide show where he showed the class diagrams for a bunch of different design patterns, which didn’t help me understand at all how to apply them. They just seemed like vague, abstract concepts when looking at the class diagrams. On the other occasion we were creating a program that required an undo/redo feature. My professor recommended we look into the command pattern for implementing it. I did, and it made implementing undo/redo very easy. I got a taste of the power they can provide, but it wasn’t clear to me how to apply other patterns.

It wasn’t until I started programming my game that I started to understand how powerful design patterns were. Games, even ones as simple as the one I made, are complex. At some point it became nearly impossible to add more features to my game, because I’d have to change too much code. Then I found out about the entity component system pattern. Then I read Game Programming Patterns by Robert Nystrom. I learned how several design patterns could be applied to the my game code. I ended up using a mix between the entity component system and observer pattern to make it easy to add new abilities to my game characters. I used the state pattern to make it easy to change an object’s behavior. I used dependency injection to make it easier to test the code.

You can’t teach design patterns by just showing class diagrams. For me, it took many examples to understand how to apply them. It took running into problems with my game before I understood how powerful they are. Back in school, I wish there were assignments where I couldn’t just code the program any way I wanted to, but required a specific design pattern to be used (one that makes sense for the assignment).


I remember one assignment where it was a requirement to write tests (in C#). But we weren’t taught how to write tests, or write testable code, and I didn’t know about any C# testing frameworks at the time, so it was a challenge. There should’ve been a whole class on writing tests, and for each class after that writing unit tests for assignments should have been mandatory.

Writing tests and testable code is, I would say, more important than anything else. When you get a software job, if the system you’re working in doesn’t have tests and testable code, then it will slowly accumulate bugs. Then each time you fix a bug, you introduce 2 more somewhere else in the system. It becomes harder and harder to test, and you’ll become scared of making any changes. Development becomes more and more costly and slows to a snail’s pace.

If the system your working in has automated tests for every line of code and every feature, then maintaining and adding new features to the system becomes monumentally easier. Whenever you add a new feature, or modify an existing one, you can run the tests to make sure you didn’t break anything. You can catch bugs before you commit code (the earlier bugs are caught, the cheaper they are to fix).

Testable code is always better than code that isn’t testable. This is because for code to be testable, it needs to be clean. It needs to be loosely coupled, highly cohesive, follow the single responsibility principle, follow the open-close principle, and probably use dependency injection, among other coding principles. It should be easy to write tests for code that is clean.

Taking the extra time to write testable code and tests for that code will end up saving you much more time and headaches overall. To get started, I recommend reading the following two books.

Package Management Systems

Back in school, I wasn’t aware of how easy it is to install open-source libraries into my project using package management systems. In the previous section, I mentioned that I had to write tests but didn’t know about any C# testing frameworks. It would have been great to use Nuget to easily install Xunit and use it to write my tests.

Package managers allow you to easily install, update, configure, and remove 3rd party libraries for your own projects. For .Net there is Nuget. For Ruby there’s gems. For Java there is Gradle (among others). Most languages have package managers. If you need a testing framework, IoC container, or an ORM, just to name a few, you’ll find many to choose from when using package managers.


Back in school we used Subversion. At my first job I was exposed to Git and can say I’ll never go back. I’ve also used TFS, but Git is by far my preferred source control system. The thing that makes Git stand above all the rest for me is how easy it makes branching and merging. The ease of branching and merging makes many different branching strategies possible. It’s also distributive, meaning you can make commits offline. It’s runs using the command line, but there are many GUIs available for it (I use Git Extensions).

To get started, I recommend this guide.


Like I mentioned before, college prepared me to be able to enter any software job. It gave me the basics I needed to be able to learn whatever else I would need for the job. But if the above concepts and tools were included more in my classes, especially testing, I believe I would’ve been even more prepared.

Clash Weights

Clash Weights is a website I created, but no longer host, to help players of the popular mobile game Clash of Clans. In this game, you join a clan, which consists of up to 50 other players. Your clan can initiate a war with another clan, where you attack the other clan’s players. The way your clan is matched up against another clan is based on your war weight. All of your troops and defensive structures have a weight assigned to them. Using the Clash of Clans API and the player’s player tag (a unique identifier for each player), Clash Weights calculates a player’s war weight.

The website was built using Ruby on Rails (my first time using Rails). The IDE I used was Aptana Studio 3. It was hosted on my Linode (Ubuntu server).

You can view the source files here.