Interviewing your new employer

Dave Hodgkinson — Sat, 27 Mar 2021 17:04:16 +0000

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?

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.
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.
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.
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.
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.
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?
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? 
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? 
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.
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?
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.
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.
What system monitoring do you have? What is your average time to fix? 
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.

Efficient programming

Dave Hodgkinson — Fri, 26 Mar 2021 11:33:44 +0000

Coming out of a job where I was working on a 20-year old Perl codebase, I've got some burns to get off my chest. I'm reading "Accelerate" by Forsgren, Humble and Kim which claims to have scientific backing for what makes for efficient development in a team. In my recent experience:

Use decent version control. To me, that means GitHub. Use a branching strategy to code each branch to a JIRA. Make the branches short-lived, preferably a day. GitHub is stateless. Diffs are resolved at merge-time when pull requests are made. Under NO circumstances use something like Perforce. That is like putting a large speed bump under a low slung car. It's stateful. Mapping a repo into your filesystem is a pain. Rewinding commits is a royal pain. Ugh.
Release often, releases should be easy. A marker of a high performing team is how frequently they release software. A release should not be confined to one person on the team and take half a day.
Great balls of mud are hopeless. We've been writing new software as microservices for a while now, and more recently bundling them up in Docker containers (and if you're really advanced then using Kubernetes). In the Perl world that means using a framework such as Mojolicious, Catalyst or Dancer with excellent modules like the Template Toolkit for the view and DBIx::Class for the model and not v1 of view software that's barely been touched for years and v2 exists. It also highly bound to Apache and hard to use elsewhere.
Ongoing support for mod_perl in Apache 2.x is ongoing. It's already been abandoned in Apache 1.x so I would note that software is doomed at some point.
Be very careful layering software upon software. Or using features that make things opaque. Oh, and having magic variables and not documenting them. For example, you have Puppet. That's great. Why not layer Heira on top and render most of the puppet documentation useless. Or use a templating system that magically calls in a hierarchy of other templates. Oh, and where does that database handle come from? Somewhere in the bowels of that page startup. Not sure which module.

In summary, I'd say be aware of the speedbumps. How can you improve them?

DEV Community: Dave Hodgkinson

Interviewing your new employer

Efficient programming