Following on from my previous post about how to avoid major development speedbumps, here's a list of things to ask prospective employers when they think they're interviewing you and you're actually interviewing them. You want your employer to help you do your job, right?

1. Are you using GitHub? Within that, how close to GitFlow are you?
 Having experienced an awful version control system, this is key. GitHub is really flexible and gives you enough rope to hang yourself in the foot. A fun thing is commenting commits correctly. Google it.

2. What’s your branching strategy? How long do you expect a branch to live?
 Branch lifetime should be of the order of a day. Any longer than that, have a quiet word with your SCRUM master.

3. How automated are your deployments? Do you create .rpms/.debs?
 Packages make deployments and rollbacks so much easier. Add YYYYMMddhhmmss to the name so you can keep track of them, or a build number so you can identify them.

4. Which CI system do you use? If not Jenkins, why?
 Test automation is great. It builds, runs tests and creates modules. And anything else that makes your life easier.

5. What’s your test automation like? It’s part of CI, right? Do you measure test coverage?
 CI is also a good time to run code hygiene tests even if you have them on your commit hook.

6. How is your test data managed?
 Do you create a temporary database and populate it or do you have one database and run your tests within a transaction?

7. Security? How close to the developers is this managed? Separate security departments are often understaffed. Do you keep an eye on the OWASP top ten? Are you religious about escaping strings when composing SQL queries?


8. How close to continuous delivery are you? How long do rollbacks take? Do you use something like Ansible or puppet to manage your systems? Bonus points for terraform. How fungible are your live servers?


9. How loosely coupled is your architecture or is it a big ball of mud?
 This is another thing that burned me recently. With mod_perl potentially going away in some form, parts of the system could have been moved to a new framework.

10. What other tools do you have and who chose them?
 Are you running popular systems for monitoring or code review or some open-source system that might wither on the vine?

11. Are you agile? Do you do SCRUM or KANBAN? Do you have a SCRUM master and a product owner?
 So many teams think they are agile when they're merely doing some agile type things sandwiched in a blob of waterfall.

12. Who authorises changes? Do the developers do it or do you have a separate approvals board?
 It's so much better to have decisions made at the lowest level by team members than to be farmed out to some remote change approvers.

13. What system monitoring do you have? What is your average time to fix?


14. What is your ticketing system, and why isn’t it JIRA? Does your SCRUM master visualise progress and use all the tools to measure the team performance. Does your SCRUM master measure project velocity?

So there you have it. How to extend an interview beyond the allotted time.

Did I miss anything? Comments, as always, welcome.