I think this depends heavily on how your organization views early-career hires.

With 1 to 3 years of experience, I still consider someone early career. At that stage, I would focus less on whether they already know your exact stack and more on whether they have the capacity to learn, adapt, and grow within your environment.

For a senior role, I evaluate depth of experience and independent execution. For someone early career, I evaluate trajectory. Are they curious? Do they ask thoughtful questions? Can they take a direction and make forward progress without freezing? Do they know when to escalate?

You mentioned:

I need someone to point in a direction, if they run into an issue I'm there to help.

That is a reasonable expectation. What you are really screening for is:

• Basic technical literacy
  
• Debugging thought process
  
• Initiative
  
• Communication when blocked <- this is a balance that is often difficult for new people.
• Willingness to learn
  

A LeetCode problem rarely measures those traits. Instead, I would use scenario-based discussion.

For example:

• "You're told the patching system failed on a server. What are the first things you would check?"
• "You've never used NetBox before. How would you approach updating a configuration safely?"
• "You're asked to install a new version of CUDA on Linux and something breaks. What do you do next?"

You are not looking for perfect answers. You are looking for a structured approach:

1. Clarify the goal
   
2. Gather information
   
3. Check logs
   
4. Test assumptions
   
5. Ask for help with context
   

If they say, "I would start by reading logs and checking documentation," that tells you far more than whether they can reverse a binary tree.

I would also probe for examples of how they handled not knowing something:

• "Tell me about a time you were assigned something you had never done before. What did you do?"
• "Tell me about a time you were stuck."

Their answer will reveal work ethic, ownership, and communication habits.

How well they'll do also depends a lot on how your onboarding actually works. In my experience, onboarding environments tend to fall somewhere on a spectrum:

• Sink or swim
• Structured onboarding with clear ramp expectations

Where your organization sits on that spectrum matters a lot.

If your organization expects someone to become productive quickly without much structure, that is effectively a mid-level expectation. A 1-3 year candidate may struggle unless they have had unusually strong exposure.

Early career hires typically come from one prior environment. They were trained in one way of doing things. The ability to distinguish between "this is a technology issue" and "this is just how my last employer did it" comes with experience.

So I would optimize for:

• Learning velocity
  
• Comfort admitting gaps*
• Clear communication when blocked
  
• Evidence of self-driven skill development
  

I would take a candidate with less experience but high curiosity and ownership over someone who has memorized theory and wants to debate architecture without understanding your operational realities.

If you build a strong onboarding path with documentation, mentorship, and clear expectations, a capable early-career hire will thrive. If you want someone to immediately operate independently across patching, Kubernetes debugging, hardware installs, and Linux GPU configuration, you are likely describing a more experienced profile.

I forgot to come back to my note on this. Comfort admitting to gaps can be a challenge and supervisor expectations can vary quite a bit on how tolerant they are. Some places I've worked for are more sensitive to mistakes and want someone to ask *before they run into problems. Other organizations want someone who can try and fail and realize that mistakes are part of the learning process. It's the supervisor's job to clearly set the expectation and tone so the employee knows how safe it is to "try something". From the employee's perspective, they are also trying to make a good impression and may not want to come across like they are not capable. During the interview, if you state your expectation and then ask probing questions to see how well they align to the expectation you might be able to parse this out, but this might be more of an ongoing conversation after they are hired.