There are questions you should ask during an interview to avoid unpleasant surprises.
Picture this. You celebrate your own personal achievement on the first day you start on your new job. Then after a week you regret you didn’t research your employer more thoroughly. The machines are unusable for development purposes, their concept of Agile development is a joke, the managers never read the Mythical Man-Month.
I’ve been had myself a few times. Before the end of the month you hate yourself for having accepted the gig and start looking for a better position. No one wants to experience this situation: it wastes both your time and the employer’s time.
So there are a few questions the interviewee should ask during the interview to avoid a mutual misunderstanding of expectations. In this post I’ll raise a few topics worth inquiring about, but feel free to propose your own in the comments below.
TL;DR
- What machine will you be working with? Does it have a good CPU, enough memory and an SSD?
- Are you admin of your machine?
- Which IDE will you be using?
- How Agile is the company?
- What’s the team size?
- What’s your role inside the team?
- Can you / must you take decisions within the team?
- Is the hierarchy open to feedback and discuss core issues on the project?
- What difference do they see between a long-term employee and a freelance?
- Can you work remotely when you cannot make it to the office for some reason?
- Will you be asked to stay extra hours in order to meet a deadline?
Questions you should ask during an interview: the work environment
We want to try and get an idea of the work environment at our disposal and the kind of work we will be asked to perform. We also may want to try and identify the corporate culture and its impact on our everyday efforts.
The working environment
Let’s start with the obvious: what are the specifications of the machine will you be working on? Will you receive one or do you have to bring your own device?
The question is essential IMHO, and provides some good insight about the kind of employer you’ll be working for. Providing a decent computer is not a lot to ask in this day and age. You can buy a very powerful machine for a cost equivalent to the budget needed to hire a freelance for one or two weeks. And it pays immediately. The time not wasted on a slow machine is the time the employee will spend developing features or fixing bugs! So ask about the CPU, the amount of memory, the processor, whether you get an SSD (some are still on HDD, believe it or not!) or the amount of monitors on your desk. That will help you establish how stingy your employer is.
Who’s your admin?
A pro-efficient developer installs everything he needs to improve his work and execution speed. That’s if he has the rights! Sometimes System Admins prevent us from doing so, locking down the machine and invoking security principles. I can relate to that, but here’s my two cents.
First, if a client doesn’t trust I’m going to take care of his computer, then why would he trust me with his servers and code base? He might as well not hire me then…
Second, preventing the installation of an application may force the resourceful developer into downloading and running portable apps from the dark corners of the web. Those might be way riskier than installing the well-known alternative, if only because the latter is regularly maintained. So much for security principles, eh!
So all in all I’m sure it’s better to know what you’re getting into before signing that contract, and ask the employer if you can admin your machine.
Which IDE?
I certainly don’t want to start another “my IDE is better than yours” battle here. However I did notice that Eclipse suits me less than IntelliJ IDEA. Maybe it’s a matter of habit, it’s nothing personal. However this is something I believe one should take into account. I want to spend my hours designing and developing my application, not fighting a software editor!
So make sure you ask what IDE (and what other software) you will be asked to work with.
Do you Agile, do you Scrum?
How is the company organizing your work? Do they practice Scrum or do they use Kanban? You may encounter teams that have just started applying Scrum, in which case you should make sure you both have the same understanding of the framework. I stopped counting the teams practicing “decorative Scrum”…
The mission’s scope
This may sound obvious, but you may want to be as sure as possible of what kind of work you will be asked to do. Maybe you are looking for a project to be started from scratch. Maybe you don’t mind spending a lot of time performing maintenance work on a legacy application. In any case, make sure you know what you’ll get.
The size of the team
This one sounds pretty obvious, but you wouldn’t believe how many times I forgot to ask. You may like joining a large team because it brings plenty of opportunities to learn and share. But maybe you’d rather go for a smaller team where you voice weights more?
Your role in the team
Make sure you know exactly what your role within the team will be: medior, senior, lead engineer, team leader, etc. More importantly, remember to ask whether the team is aware of the role or position you’re asked to take. I once got sold for a position as a lead and “single point of contact” for an AngularJS mission. I only then discovered that no one in the team was aware of it, and in fact they decided not to play along. Trust me when I say I had a few difficult months there…
Decisions, decisions…
How much decision power can you exercise within the team? Do you get to have the last word when having to take design or architectural decisions, or is that the role attributed to someone else? Maybe you want to be able to make decisions. Or maybe not?
In any case you should check how much of a leader the interviewer needs. Must you comply with the software design currently in use, or must you rethink the application’s structure and give precise directions about implementation choices? You can always bring suggestions, of course. But there is a significant difference between suggesting and taking the lead.
Providing feedback to the persons above
How much influence can you have towards the hierarchy? Can you raise fundamental issues and contribute to shifting priorities?
Experienced developers like you can gather valuable insights on the architectural or organisational deficiencies within a project: the lack of a decent testing framework that slows down development, problematic sections or modules that generate bugs at regular intervals. Maybe you noticed ways to improve their adoption of Scrum?
Ideally you will be able to bring those issues (and your solutions!) to the hierarchy, raising awareness on the impact they have on the project.
The employer
The working environment and the mission’s scope are both green. That’s reassuring! However, what kind of employer / client will you have to deal with? Time to probe the humans behind your paycheck…
The difference between an employee and a freelance
If you decided to apply as an employee, you expect to be treated as such: coaching, benefits, team building and end-of-year parties… If you enjoy those things, you’ve made the right decision! Or maybe you took the freelancer path: independence, a certain level of detachment and the freedom to easily call it a quit if things to go well.
Whatever the option make sure the client or employer understands the difference between an employee and a freelance. That’s for the good of both parties! For example, I wouldn’t expect to get a freelance so that he becomes the most knowledgeable developer on a given project. That’s very dangerous, because freelancers move from mission to mission more often than not! I would avoid relying on that person’s presence in the long term!
As such, try and ask this question to your interviewers: “In your opinion, what is the difference between hiring a freelance and getting a long-term employee?”. The answer will surely provide you with some interesting insights…
Homeworking
A client or employer can solve the occasional logistics problem if he allows homeworking. The highways are congested, your train is cancelled, or maybe you’re waiting home for the plumber to fix your hot-water problem? Your employer will certainly appreciate avoiding any delay on the project, no matter the circumstances. You will probably enjoy the level of focus obtained when working far from the dreaded, attention-grabbing open spaces at the office!
Therefore it may be interesting to ask the question and make sure both you and your employer are both on the same level about the cases when you can request working at home.
Deadlines
Yes, we all love deadlines don’t we! Thankfully we’ve learned a few ways to deal with those… that is, if we can secure some level of support from the persons calling the shots! When time runs out, I know I want to prioritize and make sure the most important features will be completed. However your client or employee may be used to the “whip’em” approach, sometimes also called the “death march“… for some reason?
So here’s the question to ask: if there is not enough time to finish everything, what approach will the employer ask his team to adopt? Will l he require 24/7 availability, with increased work speed to rush out all features, or will he focus on priorities and make sure developers implement the essential bits in a calm and quality-driven fashion?
Conclusions
Whether as a freelance or as a long-term employee, you will probably spend a significant amount of time with the company that wants you on-board. They took the time and effort to test your skills and personality to make sure you will fit. You should therefore also make sure they will provide you with the best environment possible for you to perform your best work.
I have recently started asking the questions listed above at interviews, to try and predict whether my mission will be enjoyable or dreadful. I never done that in an aggressive or inquisitive way, but rather as part of a friendly discussion.
Employers usually end the interview with “Do you have any further questions?”.
Well now I do!
Feel free to post your own questions in the comments below. And until next time,
Cheers!