Interview Questions Every Developer should ask an Employer

If you're like me and have been in the IT industry for 5+ years (me 10), you start to realize that the grass is not always greener on the other side in a lot of shops out there.  Before I get to the interview questions, I want to start by outlining the general types of shops and types of problems one can encounter in development shops.

Characteristics of when the grass may NOT be greener:

a) Poor Management or difficult culture & people

    micro managers who have to have their hands in every aspect and make every decision for a developer

    bad decision makers

• non-technical oriented business makers making technical decisions
• egoistic/cocky type of attitudes that disrupt a development environment
• Manager plays favoritism, and dish out an unequal workload always where the "trash" always gets dumped on one particular person

b) Code & run environments that suck the life out of a developer both at work and at home in order to meet unrealistic deadlines and fix slop as the result

c) Unrealistic Deadlines based on absolutely no solid business requirements or plan of action (iterations to pad # of requests, etc.)

d) Environment is so hard core & bleeding edge to the point of missing deadlines and ultimately failing the business  (cutting edge is something different and is completely acceptable)

   examples of bleeding edge:

• using ASP.NET MVC Preview for a  huge division-wide company white-box portal for a company with 10,000 employees or more
• Using a lot of beta software for production applications
• Using Silverlight (when it was first beta) to create business applications

  examples of cutting edge (based on the time of this post):

• Using the new VS 2008 4 months after it came out which is perfectly acceptable
• Using .NET 3.5 after it is out of beta
• Using C# 3.0 features
• Using WCF
• using IE 8 non-beta or IE 7

  examples of non-cutting edge:

• Using the .NET 2.0 framework
• Using MS AJAX controls
• Using VS 2005
• Using IE 6 (this is behind the times now, even if the naive view/excuse that "most of our users are still using IE6" when most of them most likely have IE 7 and have had it for a while now)

The list just goes on and on which is typical these days in IT unless you have been lucky enough to find that blended balance of good code and good "normal" people which is very rare.

Before I move on, here are characteristics of the type of shops in IT that you could land in:

1) Shops that believe in purchasing heavy 3rd Party "Can do everything for you with less code"

Result is, you never really learn solid OOP & ORM the right way, because you're not really programming at a high level or expected to and spending more time focused on fixing bugs, figuring out work arounds/hacks to the heavy beats and limitations within.

2) Shops that know using good ORM, design patterns, have good OOP team standards, etc. and have had success coding custom applications

You learn true OOP, ORM, and other fundamentals about development that everyone should learn, and how things "really" work in code, which allows you to be able not only to support and build anything but how to build it effectively for any type of business need in a good timeframe for the business

3) Mom & Pop shops which only have around 1-2 developers and 1-2 Network Administrators and a small # of employees (100 or less). 

          Typically you get to "do everything" but the downside is that you ultimately "learn less" because you're running around "doing everything"

          This means you end up pretty much skimming the surface on a lot which looks nice on your resume for later, but not learning a lot in terms of core skills you need later such as OOP, or high level code as well as work extra hours for in many cases lower pay

4) Pure Code & Run shop:

• Unrealistic & unspoken “magic” deadlines that seem to come up when managers feel like laying them on their developers with no real plan and excuse is because "business needed it yesterday"
• Managers are constantly micro managing you and bugging you to hit those “magic” deadlines
• Total disregard or lack of expectations on developers to use coding best practices, design patterns, and quality in their code. 
  • And lack of baked in time to overall  project timeline for any standards (code or testing) or thinking to take place
• The mentality to "do whatever it takes" to get it done "fast as possible" and that users or the business don't care about design patterns, OOP, or unit testing
• Deadlines are so rigid, that developers are working till 2am to not only get their code done, but hop around the spaghetti code that exists already in the entire application
• No real test environment for developers or continuous integration or even good source control (subversion, or at least TFS)
• Checked-in code to the source control repository never compiles.  This is a HUGE RED FLAG, STAY AWAY

The things you ultimately cannot control no matter how thorough you are in an interview are:

1) Outright lies given to you by the interviewer or managers to try to bait you.  Then you realize after you come aboard that half of it was not true, not even 10%.

example: We use design patterns, we have an n-layer/n-tiered architecture, and we also encourage unit testing and we do this in our applications.  You find out that none of this is true and in fact have not found one unit test or standard on unit tests, there is no business layer, you have not seen one design pattern (other than Enterprise Library) and the code is literally spaghetti (100 line methods, no OOP) etc.

2) The people you work with will be great people to work with and will remain generally team oriented, cooperative, friendly or the same that you interpreted during the time of the interview

    Typically, you really start to see the "real person" behind your interviewer approximately 6 months into your job when pressure gets tough and you are no longer that "new guy"

3) The company's stability will remain in good standing

    Even when an employer tells you the picture is rosy, that can change in the blink of an eye in today's corporate arena

4) Promises up front by the interviewer.  Do not count on them always coming true even when the interview reassures you that they will happen.

    They may not be “baiting” you, but they "could" be...so be careful how much you trust what you are hearing.  Try not to use this as part of your overall decision to take the offer.  You will most often just end up being disappointed when those do not materialize for whatever reasons.

    Example: The promise "that you will have a huge influence in how we drive standards and new ways of doing things".  That may or may not be true.

Now onto what I call my little interview flowchart for the interviewee. 

Before you start to ask the interviewer all of  yours questions first figure out what type of environment this so you can better filter the rest of your questions:

Questions Set #1

Are filling a new opening or an existing opening for this position?  If existing, what happened to the previous employee who was in this position?

• You prefer to hear "new".  But if existing you don't want to hear "he wasn't a very good fit and couldn't get the job done".  It just rubs me the wrong way and personally this is a red flag when an employer says this whether it's true or not

What applications will I mainly be working on and what are the team goals for the year and this position?  What about next year?

• always know what you'll be working on (specifics) before you accept that offer.  You may end up regretting accepting the offer if you do not establish this answer now and know what you are getting yourself into

How do you test your applications outside of unit tests?

• preferably you want a QA department in place

Do you have a flexible work schedule?  Can you wear jeans on Friday?

• funny or unimportant to some as this may sound, it's important that you can work in a comfortable environment...it just makes it all the better.  You're at work every day so this is an important question that affects your schedule at work and outside work as well as shows flexibility in the culture

What is the team make-up.  Do you have a DBA, # of developers and what they are working on (win, web, and what specific apps), # of PMs if any, # of Architect leads if any, and so on

• you want a well balanced team.  You don't want a situation where you're stuck doing it all unless you love slaving night and day

Will I be mainly working on custom win or web forms, web services, etc.?  If it's several, ask them what % on each and does that % change or usually on average typically stay that way

• if it's mainly win forms and you love web forms, make a decision if  you're willing or would be happy with switching to win forms

Do all of your applications use an n-layer/n-tier approach where most of them have a standard Data Layer, Business Layer, Presentation Layer, and if required Service Layer?

• if non of the interviewers have any idea what you are talking about, get through the interview but move on, this place probably not for you

How are you setting up the physical n-tiers in your applications?

• If they ask what do you mean, then they don't know the difference between the concept of n-layer vs. n-tier.  There is a difference.  Most shops don't know but they should.  If not, that's ok but if they do, all the better for you

How do you currently load balance your bigger applications?

What .NET framework are your current applications on.  What percentage in each framework?

• You want to aim at mostly .NET 2.0 + environments

Are you using the latest version of Visual Studio?

• your preference should be a yes

Are you using any C# Generics?

• you want to hear a yes on this one

Are you using LINQ, C# 3.0, or ASP.NET 3.5 code in your layers?

• if yes, all the better.  Tells you they are on top of the latest and willing to use it

What type of objects are returned by your standard CRUD methods?  Are they Generic Collections, Typed DataSets, Custom Object itself, DataSets, Arrays or what?

• If they tell you DataSets, this is a red flag and you don't want to code in an environment like this.  If they tell you DataSets are horrible for enterprise applications and inefficient, that is a good answer

Can you describe to me how you are enforcing separation of concerns in your applications?

• again, if none of the interviewers have any idea what separation of concerns means... be very hesitant and probe more here

How do you feel about DataSets or Typed DataSets?

• good code shops will not use them in their data layer for good reasons

What design patterns do you use and in what layers are they used and how?  Can you give me a real example in one of your applications where you are using x design pattern?

• if they cannot answer this question or understand what design patterns are, most likely this place or team  is not for you

Do you use any Code Generation Tools?  If so, which and what kind of patterns do the templates provide?  Who does the code generation?

• Hopefully there is not just one person doing all the code generation, that's not the best thing...but could be ok also depending on the environment

What source control software are you using?

• if they are using VSS this place probably is not for you.  If using TFS that's better.  If using Subversion, that's also better

Do you have continuous integration/builds?  If yes, what tools are you using for that?

• If they do not understand what  you mean, this may or may not be a good development shop.  But still probe for more and ask a question such as "Do all your solutions checked into source control have an expectation by developers to build, and to also WORK?".  Or ask do all your developers make sure that they get latest and compile before adding new code and then recompile and test again before checking their changes back into source control?

Is the environment a test driven development environment?  Do you use unit tests?  If the answer is yes, what unit test framework are you using?  Do you have a standard that most applications are required to have unit tests in place?  What layers do you unit test on?

• If they do not do unit tests, it doesn't mean they are necessarily bad and not a decent shop where  you might be happy to work in, but you want an environment who knows that they are preferred or use them highly in their daily process
• Do you use code generation or do you manually create your custom classes?  Is there some sort of team standard and patterns you use and expect through each layer overall?

What mark-up standards do you have in your Presentation layer?

• If they don't understand after you hint a few times, such as saying "how is your CSS added and maintained in your .aspx pages or user controls?", then you should really ask more to probe how clean and how much quality and care they put into their Presentation Layer
• You prefer an environment which expects their developers to stay away from inline CSS styles, and use CSS classes and ids

What code-behind standards do you have in your Presentation Layer?

• If they don't know what you mean, or talk about reuse by calling methods from the business layer, or you plain out ask them how their logic is coded and they just say in the code behind and they don't make calls to a business layer, this place is not for you
• If they tell you that methods are expected not to be a ton of lines long, this is a good thing (shows they do not want spaghetti code)

Do you use user controls in your Presentation Layer?  If answer is yes, can you give me an example of where you used one, for what application and what the user control is for?

• tells you if they are advanced in asp.net somewhat and also that they care about organizing/separating code and long .aspx pages to make it more manageable

What is the philosophy around coding standards here and how the team is managed in terms of code expectations, deadlines, and gathering of requirements?

• this will tell you a lot.  If they are a code & run, micro manager, drill sergeant type shop who expects results in 2 days but also with perfect code, etc.
• You don't want to hear "whatever it takes to get it done".  You don't want to hear "we try to get it out there as soon as possible and it doesn't have to be perfect".  These are signs of a do it fast no, fix it later approach to development which leads to great pains and headaches

Do you use Stored Procedures for your CRUD operations?  If answer is yes, what's your philosophy around stored procedures?  Do you have a lot of them and are they really long & full of logic?

• If they don't know what stored procedures are or don't use them, this place is most likely not for you
• If they say the believe in putting most the logic in the stored proc first, that's a huge red flag.  This place is not for you
• If they say that stored procedures for an application should perform discrete functions, basic CRUD operations where the SQL is not overly complex and just serves the basic crud operation, this is a good thing.  This tells you that you will not be spending countless hours trying to debug a mess of SQL inside very long stored procs and that the logic has been moved up to OOP more and maintained at that level

Do you provide any in-house training by either internal developers in development meetings or bring outside companies into train developers on topics?  If no, then what training do you provide such as books, online training packages that we can buy into, or external vendors who may train on ASP.NET or .NET code?

• preferably you want to hear a yes on some sort of training.  If no internal that's fine but it would be preferable that they do bring in speakers which is a good thing
• If they provide no training or materials (purchasing of books, etc.) this job may not be a good one as most environments offer some sort of training

Questions Set #2

Are filling a new opening or an existing opening for this position?  If existing, what happened to the previous employee who was in this position?

• You want to hear "new".  But if existing you don't want to hear "he wasn't a very good fit and couldn't get the job done".  It just rubs me the wrong way and personally this is a red flag when an employer says this whether it's true or not

How do you test your applications outside of unit tests?

• preferably you want a QA department in place

What applications will I mainly be working on and what are the team goals for the year and this position?  What about next year?

• always know what you'll be working on (specifics) before you accept that offer.  You may end up regretting accepting the offer if you do not establish this answer now and know what you are getting yourself into

Do you have a flexible work schedule?  Can you wear jeans on Friday?

• funny or unimportant to some as this may sound, it's important that you can work in a comfortable environment...it just makes it all the better.  You're at work every day so this is an important question that affects your schedule at work and outside work as well as shows flexibility in the culture

What .NET framework are your current applications on.  What percentage in each framework?

• You want to aim at mostly .NET 2.0 + environments

Are you using the latest version of Visual Studio?

• your preference should be a ye

What mark-up standards do you have in your Presentation layer?

• If they don't understand after you hint a few times, such as saying "how is your CSS added and maintained in your .aspx pages or user controls?", then you should really ask more to probe how clean and how much quality and care they put into their Presentation Layer
• You prefer an environment which expects their developers to stay away from inline CSS styles, and use CSS classes and ids

What code-behind standards do you have in your Presentation Layer?

• If they don't know what you mean, or talk about reuse by calling methods from the business layer, or you plain out ask them how their logic is coded and they just say in the code behind and they don't make calls to a business layer, this place is not for you
• If they tell you that methods are expected not to be a ton of lines long, this is a good thing (shows they do not want spaghetti code)

Do you use user controls in your Presentation Layer?  If answer is yes, can you give me an example of where you used one, for what application and what the user control is for?

• tells you if they are advanced in asp.net somewhat and also that they care about organizing/separating code and long .aspx pages to make it more manageable

What is the philosophy around coding standards here and how the team is managed in terms of code expectations, deadlines, and gathering of requirements?

• this will tell you a lot.  If they are a code & run, micro manager, drill sergeant type shop who expects results in 2 days but also with perfect code, etc.

Do you use Stored Procedures for your CRUD operations?  If answer is yes, what's your philosophy around stored procedures?  Do you have a lot of them and are they really long & full of logic?

• If they don't know what stored procedures are or don't use them, this place is most likely not for you
• If they say the believe in putting most the logic in the stored proc first, that's a huge red flag.  This place is not for you
• If they say that stored procedures for an application should perform discrete functions, basic CRUD operations where the SQL is not overly complex and just serves the basic crud operation, this is a good thing.  This tells you that you will not be spending countless hours trying to debug a mess of SQL inside very long stored procs and that the logic has been moved up to OOP more and maintained at that level

What type of training do you provide?

• If they provide no training or materials (purchasing of books, etc.) this job may not be a good one as most environments offer some sort of training

Have you had any struggles with any of your applications?  Why and for what specific applications?  How long have you had these pains?

• this will tell you just how much maintenance or bug fixing or hacks you will have to do in  your job when you have a lot of 3rd party applications as the philosophy in those types of environments

While ultimately you can't predict much about the people & culture, you can try to do something about drilling that employer during the interviews to get as complete of a picture as possible about the technical environment & processes before accepting that final offer as long as that employer is telling you the "real" story.