Interview questions for your new employer

Hacking

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?

  1. 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.
  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, GitHub or Gitlab, why not?
  5. 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?
  6. 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.
  7. 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?
  8. 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?
  9. 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?
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. What system monitoring do you have? What is your average time to fix?
  15. 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?
  16. 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.

How to win at phone interviews

Phone Interview
Steve Carell, (AP Photo/NBC, Justin Lubin)

As a contractor, phone interviews are a fact of life. We have to do them to let people know how awesome we are, plus it saves a trip into their office until we’re sure they want us and we want them. After consulting with my posse on LinkedIn and looking at lists on the internet, this is the list of phone interview tips I came up with:

The tips

  1. Be prepared! Put the date and time into your computer/phone calendar and set the alert.
  2. Try to avoid speakerphones. I had one last week and I reckon I got 75% of the conversation. I mentioned it to him and he said that was the only phone in a quiet place he had access to. So do your best. I am going to the next stage so it couldn’t have been that bad.
  3. Stand up. This might not seem obvious but in terms of posture and sounding good, it makes sense. On the same note, smile. It makes you sound better.
  4. Dress up. A proportion of interviews will take place over Skype but even if they don’t, a shirt and a pair of trousers make a difference.
  5. Have your resume to hand. This is good advice. I have done so many gigs, they start blurring into one and it help tell the story.
  6. Have a notepad to hand. It’s good to keep notes, what questions to ask and what to go back to.
  7. Be yourself. I’d rather be Chris Hemsworth, but beggars can’t be choosers. Equally, if your personality is a bit rubbish, best gloss over it. Sound enthusiastic and avoid a monotone.
  8. Block out time and a place to have the interview. Make sure the place is quiet and you’ll be undisturbed.
  9. A bit underhand, but suggest you’re already a long way down the line with someone else. I’m not sure this one is entirely ethical.
  10. Prefer landline over mobile. My mobile tethers over wifi and isn’t 100% reliable. Be in a quiet place where you won’t be disturbed. Turn off your mobile.
  11. This is a general interview tip, but do your research on the company. I always try to find out what their real problem is, not the bland list of requirements in the job ad. Try to form relevant questions. Prepare some questions and answers.
  12. Try to get an email address so you can follow up afterwards, with the notes you made. You made notes, right?
  13. Salary expectations. This one is hard. On my hippy side of the fence, they should pay you what you’re worth. Some of my most productive contracts have been when the interviewer has winced slightly at my price. Equally, I think talking money at this stage is a bit presumptuous.
  14. This one is for Americans: don’t chew gum. And don’t smoke. You can smell it down the phone line.
  15. Have a glass of water handy. A dry throat is no help.
  16. Don’t interrupt and take your time. Pauses are shorter than you think.

And there you have it. The wisdom of crowds!

Please employ the bear to do something interesting!

So yet again, I spent time battling a legacy perl code base with no tests, no Jenkins/Bamboo, no deployment pipeline and half an agile process.

Now I get to do battle with recruiters again, something that fills my life with joy and purpose.

I thought I’d put my thoughts down as to what I’m looking for in a job.

First up, contract or permanent? That’s easy. I’ve been contracting for 18 years and I don’t see that changing UNLESS you have a really juicy CTO role on offer. More of that later. I think it’s just largely temperament. I like to have an independent, outside view, trying not to get absorbed in the local cargo cult. So there are two things I do.

Senior Perl developer.

My career can be best described as “careering from one thing to another”. If I’d had any sense, or career direction, or a mentor, I’d have stayed much more firmly in the CTO field. I’ve flirted with many startups over the years, but none have actually stuck. So what am I looking for in a perl gig? Here goes:

  • A modern framework. Give me Catalyst preferably, a framework standing on the shoulders of giants. Dancer or Mojolicious would work as well. Template Toolkit is the ideal templater.
  • Tests. It should be obvious, but often isn’t. If you write code without tests your code is immediately legacy.
  • A sane database schema. One that MySQL Workbench can reverse engineer into a pretty diagram. An ORM. There’s little point these days hard-coding SQL. That’s so passé. Give me DBIx::Class.
  • A well-run Agile process. I got my Scrum master certification and now “doing agile” as opposed to “being agile” brings me out in a rash. One purpose of agile is to get better and unless you do that, you’re not agile. Just standups and sprint planning don’t cut it.
  • Javascript I can take or leave, but it’s a given these days. I can do it but I’ll hate myself afterwards.
  • Don’t talk to me about web servers. Not my problem any more.
  • I want support infrastructure that’ been there since the beginning. That means Perl::Critic and perltidy. Pretty, clean code please.
  • Please let me please talk to REST APIs, none of that SOAP rubbish.

CTO

I’ve been a CTO. And interim a few times. Obviously I’d do it all completely differently this time, knowing what I know now.

  • Let me grow the team. I’ve had amazing luck in the past picking great teams. Indeed, a team that largely didn’t know perl and then became experts. I’ve also been involved in a firing. We’re still friends.
  • Let’s have all the tools we need: Atlassian (or equivalent) stack or integrated equivalent.
  • I want to buy in a good Agile coach for a few months to get us on the right track.
  • I want to manage upwards well. Demo the important stuff to the other directors and management at the end of every sprint. Respond to the business.
  • If you’re good, you can work from home. This is the 21st Century. Being forced to turn up to an office is one of my bugbears. You don’t need my physical presence. Skype and Slack will do the job.
  • Give me something exciting to lead. Not sure I could cope with another publisher web site.
  • Let me speak at conferences. Yes, I know I’m a straight, white male. It’s a burden. But I AM left handed! I’m a minority! It’s good for the company visibility.

And probably stacks more.

As an aside, any good personal projects worth chipping in to right now?