Important questions for your prospective employer

You're in an interview, getting asked dozens of questions. At the end of the interview, the interviewer asks if you have any questions about the company. Heck yeah! This is your time to learn about the company. Getting hired is a commitment from you AND the company.


While I haven't had a lot of jobs, I have certainly enjoyed some more than others. Sure, at the end of the day it's just a job, but you'll be averaging about 40 hours out of each week there, so it better not be that bad. That's a significant part of your life. If my math isn't too bad, it works out to be about 10 years of your life working for someone else.

Obviously, it's incredibly important that you enjoy your 10 years as much as possible. So what do you ask a prospective employer about their company? I've come up with a list, semi-inspired by The Joel Test. These questions are more open-ended, so that it's more difficult to cheat. I recommend asking them, and writing down the answers for reference.

What type of source control do you use?

This question will confirm that they do actually use source control, and it will tell you if it's ridiculously out of date. If they say that they use Source Safe, be worried. If they're using something modern like Subversion or Team Foundation Server, that says something about them.

Do you have an automated build system?

Ideally, they would be running a continuous integration, but any kind of push-button automated build system is great. If the parts of their software are unorganized, and the developers frantically try to piece it together on the day of a release, run away!

How do you track bugs?

This question first tells us IF they're tracking bugs. It can also give some insight into how bureaucratic they are. If it's a bug tracker that lets every pencil-pushing, bean counter add a field, bugs will never get entered. I don't care how big your company is, it IS possible for you to run something simple with only a few fields. The likelihood of their bug database being up to date is inversely proportional to the number of fields on the bug screen.

Do programmers have quiet working conditions?

I can't really stress this one enough. If you're working in a close-knit group of developers that are all working on the same thing, then the occasional distraction isn't so bad. The conversation will often be related enough that you should know about it anyway. On the other hand, I've worked in a department where everyone had drastically different jobs. The noise was unbearable, and productivity was horrendous.

What development tools do you use?

This should ultimately cover hardware as well as software, so it might require a follow-up question depending on how it's interpreted. You want to make sure that the company understands that every minute you have to wait for your computer to compile, is a waste of your time, and a waste of the company's money. You also want to make sure that they're willing to buy the tools you need to be efficient. Developers are not cheap, both salary-wise, and in overhead costs. If they don't understand that, then look somewhere else.

What is your QA process?

This question tells you if they've thought about QA, and if they have, it tells you if they realize that testers are needed to produce a truly great product. This should also overlap with the type of testing that the developers are involved with. Unit testing has definitely gone mainstream, so look out for companies that are behind the curve, or think testing isn't worth the time and effort.

Do you do usability testing?

This is probably parallel with the QA process. They should have a clear way of determining the usability of the product, and have a way of finding out weak spots.

How long are your development cycles?

This isn't necessary a deal-breaker, it might just give you an idea of how it matches with your own preferences. I've worked for a company that had development cycles measured in years using the Waterfall method. I've also worked for a company where the requirements changed weekly, and we had to continually adapt. Both had their advantages and challenges.

Is the work environment fun and friendly?

This might not be a question that you can ask directly, but it's one that you should try to answer. Is there a strict dress code and set hours? The last time I checked, your computer doesn't care when you're using it. Your prospective employer hopefully understands that while it's useful having everyone in one place at the same time, flexibility is a must for maximum productivity.

How do you plan and schedule new projects?

This should give you insight into how much thought they actually put into what they're doing tomorrow. You might be able to get an idea of whether they're short-term or long-term thinkers. Having a map is a good sign, but being flexible is just as important. Only a fool would think they can plan everything perfectly, but they should also be solving problems before writing code.

What is the ratio of code maintenance to new code being written?

This is another personal preference question. If you don't like maintaining someone else's code, the answer to this one might be very important. You will also find out if you have to live with your own old code. Some people like the stability of a mature code base, and some like a fresh start every once and a while.

How does the company plan to grow and stay competitive?

This is a very broad question, but it does show that you're looking for a career and not just a job. It would be nice to know that there are smart people running the company, and they have a plan to be around tomorrow.


Do you have any software development related questions that you always ask a prospective employer? Please leave a comment and share them.

Like this post? Please share it!

See a mistake? Edit this post!

What do you do with your old hardware?

I've been on a mission to scale down all of the old tech hardware I have laying around in my house. Here is a partial list of what I had/have:

3 working mid-grade desktop computers, 3 Netgear routers, 17" CRT Monitor, Vonage VOIP adapter, Sunrocket VOIP SIP adapter, Subwoofer, 10 network cards, Modems, PCI + AGP video cards, 802.11g PCMCIA card, 5 hard drives ranging from 20gb to 160gb, 3 256MB USB flash drives, 3 memory cards, Old computer books, 2 UPS's

So here is my question. What do you do with stuff like this?

In round 1, I threw away anything I knew was completely worthless. Frayed wires, parallel to TI-86 cables, those useless USB to PS/2 mouse adapters.

In round 2, I sold some of the small, valuable items on eBay. This is a great place to sell anything of value. You'll have a large audience, and you'll get what it's worth. You'll also have to deal with packing and shipping it.

In round 3, I gathered up almost all of the rest, and sold it on Craigslist. Which, by the way, is a great way to get rid of a lot of stuff very quickly. I took a picture of a whole pile, described some of the more valuable items, and sold it in a couple of days.

In round 4, I'm not sure what to do! I have lots of small things left like the USB flash drives, case fans, hard drives, etc. Back to Craigslist?

What is the best way to get rid of this stuff without filling up the landfills? I know there is someone out there that is about to drop $20 on a network card, when I have 10 here that he could have for free. I just don't want to spend the time and money to pack it up and ship it somewhere.

Some suggestions I've received:

  • Donate to schools - I'm not sure if or what they're interested in. I'll have to contact them.
  • Donate to Goodwill - I called them and they don't want it!

Any thoughts? This is surely a common problem amongst techies?

Like this post? Please share it!

See a mistake? Edit this post!

Are third party dependencies evil?

I recently posted about a problem I had with the Microsoft CTP DataGrid I was using. I quickly got a response from Odi from Xceed, asking why I wasn't using theirs. Good question, and deserves it's own blog post.

xceed DataGrid

The truth is, I've been burned by third party controls in the past. In general, third party controls work great when used in the sterile lab environment. The problem is, it seems like every project I work on has some requirements that tend to break them.

For example, a recent website I worked on had a requirement that every page had to have an HTML extension, even though every page was an ASPX page. Depending on how it's implemented, many third party controls just couldn't handle it. In fact, it's hard enough to get the core ASP.NET functionality working properly with some features such as postbacks. Adding poorly written third party components would have made things worse.

Ok, so why is it alright to use Microsoft's controls instead of something from a third party? In my experience, the code the Microsoft gives you tends to be lacking in real functionality, but is usually very reliable. Even when they've had an issue, there was enough support to get a work-around, and probably a fix in the next service pack. Microsoft products tend to get better over time, and without any upgrade fees. They are a well established business with a guaranteed audience.

The 500 lb Gorilla

Let's take the .NET TextBox as an example. Ever run into a situation where you've found it to be unreliable? I haven't. I have run into a situation where a third party alternative had all the bells and whistles you could think of, but had some major issues. You push the up arrow and the application bombs. Darn. You could only use it in a certain way, or it wouldn't work at all.

K.I.S.S - Keep it simple, stupid

Is this a rule, or a good practice to follow? Depends what you need. I use third party dependencies all the time. I typically only use them if they're in widespread use, mature, and under current development so I know fixes will be round the corner. For example, here are a couple of great ones that I recommend:

  • Log4net
  • NHibernate
  • RhinoMocks
  • Spring.NET

If you're curious what criteria I use when looking for a third party control, be sure to check out my post about 10 things to look for when evaluating third party controls.

In general, I think Joel has a good guideline:

If it's a core business function -- do it yourself, no matter what.

I've tried desperately to come up with a great example of when his rule doesn't work. At one of my previous jobs, I wrote a lot of reports using complex charting. We had a great third party charting library, but we always had strange ways of working around its interface. It's probably the best example that I might have to counter his rule, but it probably wouldn't have taken any more time if we had written the charting ourselves.


If you need a quick and dirty simple control, and it's already part of your toolbox in Visual Studio, just use it. If you outgrow it, or have some special requirements, see what is out there. In my case, I think the Xceed grid would have been overkill. Microsoft will fix their bugs, and my application will only get better. If you need a grid that does more than display some simple data, take a look at what Xceed or another vendor offers. Their control has certainly been around the block, and looks like it has a lot more features.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG