I'm a consulting software engineer. Life's good, the pay is nice, I get to try a lot of different places which is awesome as a fairly new developer. I get to go to a lot of fun places with the company I work for. I'm somewhere between a junior and senior developer.
When I started as a consultant about two years ago I just saw the new assignment as a place to which I should sell myself. I prided myself in making an interview which left the client wanting me. Which seems fairly natural, right? But what I've neglected to do was to ask relevant questions for me to figure out wether I wanted to work there or not.
Where you end up matters.
What I've come to realise is that there are a few factors that are important, at least for me, in deciding if I want to end up working at a place, no matter whether it's just half a year or so.
So during the next interview I end up in there are a few questions I'll ask. Most of these questions are obviously good to ask to give the interviewers a good impression of you as well which of course is a bonus.
If you'd end up hiring me, what would you do to make me a productive member of your team as soon as possible?
I've come to feel that this is a really important question, because it tells you how they will work with spreading of knowledge within the team. And how mature they are as an organisation.
Whether they know what they expect from a new team member or if they have only realised that they need more people grinding code.
What's the history behind the product?
If you ask the correct follow questions you can hopefully figure out if it is the brain-child of a single developer working on it for a few years. This is not necessarily a bad thing. But If someone works on something by him/her-self for a few years they risk falling in love with their application and may want to control the changes, and that is bad.
Can you describe the architecture?
Obviously you want to know what it is you'll be working on. But also having someone describe the architecture can give an inkling on the quality of the architecture and also the code.
Can you describe your test and release procedure?
Again an indicator for the maturity of the organisation/team. The release procedure is important for us developers to work efficiently and to know about the turn around time.
For example I've seen places where they tested the code built in one jenkins machine, but released the binary built from another jenkins. All of this with very manual steps. This is just plain bad.
How do you manage technical debt and do you track it?
This should be a given, technical debt is a reality and if uncontrolled grows until it becomes unmanageable.
What kind of tools do you use?
Do they use git, jenkins, sonar, artifactory or whatever equivalent tools. If they don't how so? There's a reason why they are given in our industry, and it's not because they are cool.
How do you handle innovation
I realise this might be an presumptions question to ask during an interview. But I believe that the answer to this question hints about the culture in the company.