Protein interface – how to change aproach to building software?

A) Relate to the GP, and

B) Answer the question

For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP.

I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company.

If you were a photographer, that was the case. If you were a programmer, that was definitely not the case.

So I had a challenge.

I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development).

I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote.

I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered.

I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped.

I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year.

In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had.

I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore.

I think I did OK.

[UPDATE] I made it more about me, to try to make the comment a bit less abrasive.

"We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?"

It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail.

And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.

The author may be in a contract outsourcing shop.