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).

You have some public repos. That's plenty. Even some gists will work

I tell people all the time, if you want to make it easier to get hired, put some work online. This is especially helpful for those without great credentials or history. Take advantage of this, as it's not possible in many other professions.

Even these Linkedin posts are fine, as long as it's not an ad to some tool, or just full of buzzwords.

The kind of "behind the trenches" posts are great too, to explain something that happened in a project, a challenge you had, how you debugged a problem. This saves a lot of time in the interview as I would read it all and use that to discuss with the candidate.

As I said, it doesn't need to be only public repositories. If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries. If the answer is no (happened just a few days ago), then I ask what they used. I expect them to say something like Artifactory, Nexus, a directory on a server or HPC, or just explain why they didn't need a registry. For me there is really no wrong answer here. But if they reply they don't have anything public, and have no idea what's a container registry, then that's probably bad -- this is what I think OP of this thread meant by eliminating candidates that are full of---.

> Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.

My wife also works here, and she's a recruiter in a EU company, in cancer/research. Most applicants won't have things public in that case, but they can still explain things. If there is a candidate with similar profile, that managers liked, and they have a lot of good work, public, then it's up to managers. I just explain what I saw in the repositories, whether I'd work with the candidates, and the managers hiring choose based on risk for companies.

As you are based in EU, you probably have the same problem that the hiring process can be expensive for company, and risky if you eliminate candidates, and have to go back during the experience/trial period of candidates.

Sounds like a contradiction. If it's super competitive shouldn't it be easy to find candidates?

> If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries.

How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?

Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.

So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises

I know, it should be the other way around. I asked some locals, and so far some of the best answers I got for this are that the best brains here are abroad, at the Netherlands, Germany, etc.. There's a lot of applicants for every position we advertise (especially if we need someone from DevOps or Web -- not so much for Fortran, Scientific Programming, but that's normal).

But most don't pass the first filter. We try to select those that fill the basic criteria, even if they don't fill all the boxes (it's alright to learn on the job for us), even select some that do not pass to call for a short interview with HR or even with manager, but it's quite hard to find good candidates.

> How many candidates coming from EU companies have the work they do at their company made public like that? I never worked anywhere where this was the case. So what do I do then?

It's quite common for some companies in my current field, earth sciences. Many companies have public GitLab servers, or host their own containers (e.g. Mercator Ocean International, DKRZ, ECMWF, etc.).

As I mentioned in other comments, I'd interview someone that doesn't have public repositories or containers anyway. But in the end, if there are other candidates with good CVs, and interesting projects public on GitHub, etc., or if they collaborated to good Open Source projects (Dask, Xarray, Singularity, Jenkins, Python, fortran, etc.) changes increase.

> Only if you work in FOSS is your work public, but if you work from some bank or any other private company they don't expose their work on GitHub due to IP and legal concerns.

I worked in banks, insurance, credit bureau, telco, and government. In most of these the work was done in private CVS, Subversion, or Git servers.

But in most of these, we used Open Source projects, and normally we were allowed to send contributions back upstream, when we found bugs in numpy, python, etc.. There were some companies where I couldn't contribute, so I can only explain the systems I worked, and the tech stack we had.

> So to me it sounds like you're only selecting those who worked at FOSS projects/enterprises

We hire people without public repositories too. Having worked at FOSS projects/enterprises definitely helps.

It's the same as the degree you have. In the end it may be an advantage depending on the company. I, particularly, do not care much if someone is coming from physics, mathematics, economics, biology, or even architecture (we just hired an architect that enrolled in a CS degree in Portugal to work with data pipelines/NetCDF/xarray/etc.).

As long as the person has the technical knowledge required for the job, and some experience if needed, that's fine by me. But I worked with manager that only hired those coming from CS.

So even those with good public contributions or coming from enterprise/FOSS, acing a technical test, etc., nothing would help you to be selected when applying for that team.

Out of curiosity how would an architect without pipeline job experience get hired for such a position? Asking for a friend.

Somehow, that person heard about the position, and was already trying to transition from architecture to IT (had enrolled in an open university course of CS -- online, remote).

We really try to interview as many as we can, give a fair chance to all (ignoring background, gender, etc., focusing on what's needed for the position).

Human resources did the first triage (assessing character/personality [one of those simple psychology assessment tests], level of English, visa/work permit/etc.).

Then the managers for the position (department leader + group leader) reviewed CVs and prepared brief interviews, followed by a final technical interview. That's it.

That person did not have a lot of experience, little visible in GitHub, having only studied IT for a few months, but he was really trying hard. The managers liked his attitude, and believed he was the best fit for the position.

He's now learning Git, Docker, Python, NetCDF, etc. In fact, today we will have a quick chat near the waterfountain/coffee machine as he asked me if we could chat as he had questions about pyproject.toml and building Python packages.

I believe if instead he had showed some projects with Python and NetCDF, and said he was looking into enrolling in a CS degree or take some courses, that could have been a replacement for the CS degree.

So tell your friend to try to choose what s/he prefers (data, programming, performance, DevOps, web, algorithms, compilers, etc.), and try to either create a public portfolio, or study hard so that in an interview s/he can answer questions well, showing some knowledge & interest (e.g. in this case, knowing what's NetCDF is, what's GRIB/BUFR, xarray, etc., even without a lot of hands-on experience could have been an advantage).

This mirrors my experience as well.

I tend to do some side projects on the side but, seeing as I do them for fun, I don't take them as seriously. I'd hate to be judged based on work like this over something I'd do in a professional setting.

That said I understand why this is an issue and seeing a (representative) code sample is invaluable.

Yeah, I'd also hate to be in that position where I may be the best candidate for a position but somebody else got it just because they have public projects. But at the end, the managers/HR/technical team/etc. are all trying to minimize risks to the company and projects.