At almost every interview that I've personally attended, I've been asked the same question. A question that appears usually at the very end of the interview once you're covered in nervous sweat wondering if you're either amazing or terrible.
"Do you have any questions for us?"
It's been a 50/50 split as to whether I've personally asked questions or not, much of that having to do with how badly I want to get up and leave. Often times I end things with a "Not at all, you've answered all of my questions", when truthfully, of course I have questions since I've never heard of your company.
Whether asking questions to your future employers actually affects you getting the job though isn't certain. But, I think it's important for a variety of reasons.
After 15 years of working as a professional software engineer, I can safely say that you don't want to work for just any software company. Even if you're just starting out, because working at a high stress company with little order and excessive hours can make you want to change fields completely. I've seen it happen many a time and I've lost many a friend to some other less anxiety indusing work.
And in order to get some insight into a company before you are hired, you'll need to ask questions. But just what questions, is what I will cover today. Because you don't want to come off as rude and you don't really want to intrude too much into the interviewers personal space.
So asking a person if they themselves like their work might not help you out too much.
3. How many developers would I be working with?
If the answer is "None, zero, zilch", then you might be in for stressful time at this job. And this happens more often than you think. Non-technical people at a company don't typically know how their web applications function. They don't know what a repository is and they don't want to know.
That's why they want to hire you. So you can figure it out for them. And that means that you are in for a challenge if you get hired.
I've interviewed at companies that have answered that they either have 1 other developer, that manages a dozen projects, or that it's a "new" position and that there's no one else you will be working with.
For me personally, that's a giant red flag. And I say that having come from working with team after team of skilled developers at past companies. Having that direct onboarding experience from other developers who know exactly where everything is and how everything functions sets the tone for your future work.
But going into a company that lacks that essential element, just means that you will be coding much less and researching alot more.
If a company has a single developer that manages multiple projects, then there's an underlying problem that they need to solve before they bring on just one more developer to the team.
2. What would I be working on?
You might not get an exact direct answer to this question, because truthfully the person interviewing you might not know. But you will at least get some context into what your day to day work life will be like.
You might, for example, get a response similar to the following:
- You will report to the CTO directly...
- You will be on the 'x' team working on 'y' app
- A little bit of everything
- We're not sure yet
It's up to you how you take these answers, because personal preference is always a thing when looking for work. Some people might not be comfortable working directly with the CTO or CEO of a company, particularly if they are more junior.
And often times, if you are working directly with leadership at a company, it's because they lack the resources to have project managers and lead developers, which could also be considered a red flag.
And if you're working on a little bit of everything, that typically means that there is little organization in the company and that it might take a while before your role is solidified in any real way.
I've personally worked for companies that were on both sides of the coin. And I can say that companies that had no direct answers as to what I would be doing were much harder to work with and overall less fun.
And on the other side, companies that hired me for a specific purpose, to work on website 'A', had much more organization, direction and actual tasks for me to work on starting on day 1.
1. Is there opportunity for growth?
Some companies have systems built in for internal career growth, such as yearly evaluations and pay raises and title changes. But not every company does, and if you're looking to stay at a company long term, then this will become very important.
Most of the jobs that I've worked as a developer have been very upfront about yearly raises and promotions. And these jobs have been good on their word, mostly.
But I've worked for companies with no such policies or systems in place, and eventually things get expensive in the world as my salary remains unchanged for a few years.
More often than not, interviewers will answer this question with no issue whatsoever, because it's a valid question and because, if there is a system, this is an easy question to answer. But on occassion you might get a "I'm not sure" or a "it depends", in which case, they are probably telling you that there is no system to their knowledge.
But this depends on your personal career goals mainly. If you are looking for a job for maybe 1-2 years, just to get some experience and to grow your work portfolio, then you can ignore this question altogether as it is irrelevant.
But if you are looking for an employer in the 2-5 year range, then you will want to make sure that they are a company that can afford you for that period of time.
Interviews are always a two way street. Sure, you probably really really want to get hired and get paid within the next 30 days, fair enough. But some companies really really want to hire anyone that walks through the door, because they are low on resources and can't make ends meet.
And if a company just doesn't sound like it would be a place for you to grow as a developer, then it is perfectly normal to say goodbye.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
New articles published each week. Sign up for my newsletter and stay up to date.