As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain tha

As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain that without too much trouble. Asking them about decisions in the project, issues, pros and cons of tools, etc., normally clarifies whether they understand things or not. And as I replied in the other comment too, unfortunately if there is another candidate with very similar profile & good answers, then I'll give my technical assessment to the manager of the position, and it'll be up to the manager and humans resources to choose based on risk to the company, what they can see from public papers/conferences/repositories/etc. In some cases, even if the work is not public, they can tell us what projects they worked. I work with climate models, so if they mention they don't have anything public, but they were using IFS, FESOM, ICON, SCHISM, or another model that I know/work with, then I'd direct questions on that model, to check what part of the model they worked on or used, who they worked with, etc. For me not having something public is not a blocker for hiring. Just something that simplifies the hiring process -- although, lately I've had a lot of candidates with many personal projects, no branches, no pull requests, not showing experience with Git, etc. (i.e. in some cases it seems some people try to create many repositories just to show that they have something... which can be a red flag too).