Following on from my previous post about how to avoid major development speedbumps, here’s a list of interview questions to ask 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 or similar? I’ve used Gitlab most recently, and I especially like Docker in Docker. 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.
- 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, GitHub or Gitlab, why not?
- Test automation is great. It builds, runs tests and creates modules. And anything else that makes your life easier. It’s also the ultimate in QA. If you have good test coverage and your tests pass, you’re good to go. It’s part of CI, right? Do you measure test coverage?
- CI is also a good time to run code hygiene tests like pylint or perlcritic even if you have them on your commit hook. OWASP recommend some code security scanners and Snyk seems quite plausible.
- 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 or docker. 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 should 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, GitHub or Gitlab? Does your SCRUM master visualise progress and use all the tools to measure the team performance. Does your SCRUM master measure project velocity?
- Has management bought into the k8s kool-aid? Are you using kompose and rancher to help manage it?
So there you have it. How to extend an interview beyond the allotted time.
Did I miss anything? Comments, as always, welcome.
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?
Macksville resident Melanie Williams was also shocked by a swarm of spiders climbing the outer wall of her home as they fled for higher ground. “I occasionally see spiders around the place but never anything like that, it was just insane,” she told the ABC.
The spiders outside her home were “horrific” but her neighbour told her there were twice as many inside his garage, she told Guardian Australia.
I had no idea this was a thing. Apparently, even our daily cup or two (or several) a day of coffee is helping to screw up the planet. Mass-produced coffee is produced in nice, highly productive rows of coffee plants, which sadly gives a habitat for a quarter of the number of species of birds as when coffee is grown in the shade of mature trees. So we need a bird-friendly coffee.
According to the RSPB:
Shade-grown means that the coffee grows more slowly, requires less water and the need to use any invasive fertilizers or pesticides. This in turn supports greater biodiversity and ensures that the forest in which it’s grown sustains a healthy ecosystem.
And according to Cornell University:
“Over recent decades, most of the shade coffee in Latin America has been converted to intensively managed row monocultures devoid of trees or other vegetation,” Amanda Rodewald, a co-author of the study who is the Garvin Professor and senior director of the Center for Avian Population Studies at the Cornell Lab of Ornithology, said in a statement. “As a result, many birds cannot find suitable habitats and are left with poor prospects of surviving migration and successfully breeding.”
Today, most coffee sold is sun-grown under little or no shade because sun makes coffee bushes grow faster and produce more coffee. This loss of tropical forest biodiversity to a row monoculture harms resident rainforest birds along with their migratory cousins so they all are disappearing along with their rainforest homes. This simple connection between habitat loss, pesticides and fertilizer pollution to intensive coffee farming methods was the impetus for Smithsonian conservation scientists to create the strictest agricultural certification criteria for coffee: their Bird-Friendly certification requires that coffee is organic and that it meets strict requirements for both mature canopy cover and the type of forest in which the coffee is grown. Bird-Friendly coffees are guaranteed to support bird habitat, in addition to fair and stable prices for coffee producers, healthy environments for local communities, and equal access to markets for Bird-Friendly coffee producers.
So there you have it. By having that supermarket, mass produced coffee, you’re helping destroy the planet. Good work! I’ve just bought 1.2kg of their coffee. Sorry, Tesco.
Bird and wild coffee: https://birdandwild.co.uk/collections/all-products