Ask questions during interviews

Standard

I’ve been conducting interviews at the Canadian Digital Service for software and site reliability engineers these last few months. My most important advice to candidates would be to ask questions during interviews when offered the opportunity to do so. Not just 2 random things popping up on your mind when you’re given the opportunity. I believe that asking questions will help you a long way towards being hired.


Asking questions will help you in the following ways:

  • stand out as a candidate: if you’ve got more questions and if those are well thought, you will stand up compared to others
  • confirm if you want to work here: if you ask questions, answers will comfort you (or not) when you’ll need to decide if you want to work here or not. I’m sure you heard that interviews should be “two-way” and questions play an important part in that.
  • get a better position/offer/benefits: if you show interest in the mission, communication skills, transparency, management or leadership on top of your core skills, you’ll likely get better grades which may help you land a better position, a better offer or more benefits. Salary negotiation is not the last step in the journey, it starts at the beginning.

Preparing questions

You should prepare a list of questions before your interview. Start a new document (or pick a piece of paper if that’s your style), read everything you can find online about where you applied (website, social media, Wikipedia, newspapers) and Google around. Tailored questions will grant you bonus points. You’ve done the research, time to show it.

Examples of questions

Here are some examples of questions I asked or I wrote down before interviews in the past. Feel free to reuse those!

  • What are your current challenges?
  • What’s your latest success?
  • What do you want to do better?
  • I’ve noticed you often emphasize on accessibility/diversity/inclusion. Can you share examples of this?
  • Do you inspire others? How so? Who inspires you?
  • Do you speak at/host technical events (meetups, conferences etc.)?
  • Can you explain what this team is doing? What’s the difference with <other team>?
  • I notice you don’t have a lot of people working on <this team>. Can you explain why?
  • How am I graded during interviews? How are you evaluated as an employee?
  • How do you know that your product meets user needs?
  • Can you share some data about a recent employee survey you conducted?
  • What are your company values? Do you think those are met?
  • What was your latest production incident?
  • What are some of your recurring meetings?

You will find an endless list of questions online. You can look at those to get some inspirations but a few tailored questions will go a long way. If you feel like you didn’t get enough time to ask questions, follow up by email afterwards or ask to schedule another chat to go through those.

Good luck!

Time to production

Standard

If I’m a user of your product and I’m reporting a simple bug by contacting you, how much time does it take to deploy a fix to production?

As the current Tech Lead of notification.canada.ca, a government platform, I can reasonably say that it should take us less than a business day. This number is “business as usual”, we can go to as low as 15-20 minutes for urgent fixes. And I’m pretty proud of this number. Being able to deploy a quick fix (say less than 20 minutes of work for a developer) to production in a matter of hours speaks a lot about your organisation, your infrastructure, tools and your processes.

To be able to achieve this in a matter of hours, you should:

  • have a team working full time on your product. If your product is in maintenance mode and you have to fill in documents, fax it to another department and have lunch with another director to get your budget approved, your timeframe is in weeks (months, anyone?), not hours.
  • be user-centric. The non-bullshit version of it. Writing that you care about your clients on your corporate website isn’t going to be enough this time. You have to have product people looking at support requests coming in, or a close feedback loop between your support team and your product managers/developers.
  • have reliable automated tests. Are you ready to risk shipping stuff without tests you can trust to please someone? You’re a fool. Are you still doing it but have no fears? Great, you have an automated test suite you can trust. You rely on it every day to deliver value to your users quickly while minimizing tedious work to make sure features work as intended and there are no regressions.
  • leverage continuous integration and continuous deployment. Turns out DevOps are not just costly developers who don’t like CSS after all! Seems like they took the time to put in place tools and processes enabling you to do changes in a staging environment and then to production, without downtime, without fears and without humans plugging in USB sticks in a server room. And if it doesn’t work as intended, you can roll back in minutes without any fuss, right?
  • Have a streamlined approval process. Everybody agrees that this change makes sense but yeah, sorry add it to the list of things we’ll get our board to review and approve for the next trimester. Why? Another developer approved a pull request, this change had tests and a product manager could even take a quick look at a review application that was created automatically to check that it works. Why should it be more complicated?

So I’m asking you this question: how much time does it take to release a straightforward fix to your production environment? Are you proud of it?