Reader,

This is a Senior Full Stack Engineer req I pulled from LPL Financial's careers page.

REQ: https://career.lpl.com/job/R-047752/Engineer-II-Net-Full-Stack-Engineer

​

So how do you vet candidates for this?

For an Engineer II (senior), you are looking for the transition from "following instructions" to "owning outcomes."

Years of experience are irrelevant if the candidate can prove they’re achieving at the appropriate level. You're going to want to grade candidates on what they've done.

What does that look like in practice for this req? Let's see 👇

​

Assumed Hiring Manager Priorities

If the HM is looking for an Engineer II, they aren't looking for “a veteran with 10+ years experience”.
"Years of experience" on its own doesn't do anything for your client.

They want someone who brings:

• Velocity - has the competence to get shit done fast
• Autonomy - proactively gathers what they need for a task

To measure that, you need to suss out what the HM cares about. For the sake of this example, we don't know the HM, so we'll guess based on the bullet points in the req.

Let's assume they value:

1. Technical Autonomy: Can they take a vague requirement from a Business Analyst and turn it into a working .NET/Angular feature without hand-holding?
2. CI/CD Ownership: Do they treat "DevOps" as part of their job (owning the CI/CD pipeline) rather than "someone else's problem"?
3. AI Experience: Can they articulate a specific achievement where AI was used to solve a user problem? Or are they still just tinkering with ChatGPT?

​

Achievement-Based Vetting Questions

To find the "5s," your questions must force the candidate to describe complexity and results, not just their daily tasks.

1. The "Ownership" Test

• The Question: "Walk me through a full-stack feature you owned from the 'requirements' stage through to 'production.' What was the most difficult trade-off you had to make between the Angular frontend and the .NET backend?"
• What to look for:
  • "3" describes the code
  • “4” only talks about the solution and trade-offs made
  • "5" ALSO describes the user’s problem to help frame the solution within the context of the business

2. The "Influence" Test (Communication)

• The Question: "The JD mentions persuading senior levels. Tell me about a technical decision you disagreed with. What data or prototypes did you use to advocate for a different path?"
• What to look for: The candidate should talk about logic and evidence used in their discussion with the senior engineer rather than just complaining about the other approach. There should be an articulation of the pros and cons of each approach to prove an understanding of tradeoffs.

3. The "AI & Modern Stack" Test

• The Question: "Instead of just mentioning AI patterns, tell me about a time you implemented an 'intelligent' (AI-powered) feature. How did you measure its success or accuracy once it was live?"
• What to look for: A candidate who understands that AI is only useful if it solves a business metric (e.g., "It reduced manual data entry by 40%").

How to Get These Insights from Your Hiring Manager

To stop assuming, you need to ask the HM to define "Success Milestones" rather than a tech stack checklist. During your intake, ask these three "Outcome" questions:

1. The "Six Month" Mark: "If we hire the perfect person, what will they have successfully delivered or fixed six months from now that makes you feel like this was a great hire?"
2. The "Complexity" Bar: "What is a specific technical problem the team is currently stuck on? I want to ask candidates how they would approach this specific hurdle."
3. The "Years" Alternative: "You mentioned 2+ years of experience. If I find someone with only 1 year of experience who has already built a microservices-based AI tool from scratch, are they a 'Yes'?" (This forces the HM to admit they value skill over tenure).

Internal networking gave me advocates and access to project and environment details I could not get from the hiring manager alone.

But none of that would have mattered if I had not been able to lock the manager into a clear definition of what “good” actually looked like. And for this scenario, I would not have been able to do that without a trusted engineer helping translate the work into real, testable requirements.

​

-Steven
​