I'd say get into the nitty-gritty of their tech if you can.
For example:
- What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
- If they do automated testing find out if it's the whole code base or just on an isolated part.
- If they have QA, are they writing automated tests or just performing manual QA?
- How long does it take to get code deployed?
- What do they think their biggest technical issue is and how do they plan to address it? In your experience, do those things line up?
- Are you personally impressed by the knowledge level of the engineers interviewing you? That's not one you can ask directly, but you can get an idea by seeing how they answer.
Understanding what their processes look like in practice and in detail, as well as why and how they make decisions, can tell you an enormous amount about the effectiveness of the organization.
I agree with most of these, except the last point here:
> What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
Certainly knowing what frameworks are used is useful, but in some fields it's ignorant to assume that an organisation doesn't know what they're doing because they use older versions of software. And asking "when are you going to update", might be the wrong question.
That said, it's a good conversation prompt from both sides. It lets the interviewee gauge if the reason is valid e.g. you build mission critical software and LTS is sensible. It also lets the interviewer gauge how strong the candidate is. Can they have a pointed discussion about software reliability or are they just looking for a cool outfit that runs the latest whizzbang libraries?
Yeah, that's a great clarification. The way I've phrased it implies that they're somehow incompetent for not immediately jumping to the newest version, which is not my intent.
I more so meant it as a way to figure out what their plans are for software lifecycle. All common languages (as far as I'm aware) deprecate old versions at some point, after which there are security implications for not updating. Asking what the long term plan is for changing versions and keeping up to date (however big of a priority that is) can provide some insights into how aware they are of technical chores that may be important but aren't feature related. I'm personally more interested in how a company thinks about their answer than what the actual answer is.
For example, I once spoke with a company that used PHP 5.5 with substantial tech debt. Their long term plan was to rewrite the whole platform as Go microservices. They didn't seem to realize that this would be a multi-year effort if it ever happened and that PHP 5.5 was already past its end of life date. The solution didn't fit the circumstances. That told me quite a bit about their engineering organization.
- What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
- If they do automated testing find out if it's the whole code base or just on an isolated part.
- If they have QA, are they writing automated tests or just performing manual QA?
- How long does it take to get code deployed?
- What do they think their biggest technical issue is and how do they plan to address it? In your experience, do those things line up?
- Are you personally impressed by the knowledge level of the engineers interviewing you? That's not one you can ask directly, but you can get an idea by seeing how they answer.
Understanding what their processes look like in practice and in detail, as well as why and how they make decisions, can tell you an enormous amount about the effectiveness of the organization.