←back to thread

There is a huge pool of exceptional junior engineers

(workweave.dev)
263 points mooreds | 1 comments | 30 Sep 25 03:17 UTC | HN request time: 0s | source
Show context
Cornbilly ◴[30 Sep 25 04:08 UTC] No.45421796[source]▶
When I hire juniors, I try to give them problems that I know they likely won't be able to solve in the interview because I want to see how they think about things. The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).

Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board. For us, it usually takes about year to get them to the point that they can contribute without some form of handholding. However, that also mostly holds true for seniors coming to us from other industries.

replies(28): >>45421860 #>>45421875 #>>45421907 #>>45421943 #>>45421994 #>>45422037 #>>45422071 #>>45422091 #>>45422103 #>>45422129 #>>45422144 #>>45422160 #>>45422277 #>>45422301 #>>45422324 #>>45422415 #>>45422442 #>>45422501 #>>45424757 #>>45427099 #>>45430210 #>>45431214 #>>45433919 #>>45434598 #>>45434938 #>>45435782 #>>45439610 #>>45447908 #
rich_sasha ◴[30 Sep 25 04:39 UTC] No.45421943[source]▶
Interesting - I see the appeal of this approach. Equally, I do the opposite - I give easy problems which can be solved quickly. I find people either can do them pretty quickly, or not at all.

I used to ask harder problems, like you, but found two failure modes: either smart people who panic and can't think straight in an interview, or people who can do high level thinking but then can't swap two variables in actual code.

That said, thinking back on my recent hires, I'm not sure this method has yielded any improvements.

replies(4): >>45422043 #>>45422048 #>>45422194 #>>45425276 #
1. jemmyw ◴[30 Sep 25 05:23 UTC] No.45422194[source]▶
The technical question I have start easy and get progressively harder as we go deeper. I think thats a good strategy - everyone I interview should be able to get started, even if they're feeling anxious, and if they cannot then we can both save time.

Then as it gets harder the interviewee is familiar with it, and I find that often people with less CS experience are still able to work through it even though they don't know the terminology. And we have a grading based on how much hinting we needed to give, which is very helpful guidance to me as an interviewer.

The problem I usually pose is a slimmed down version of one I actually tackled, so it doesn't feel like an arbitrary test that has no real application. Which again, very helpful for when I need to write a rejection email, as I can say where the candidate didn't meet expectations, which often seems appreciated. We're encouraged to reject during the interview if it's obviously not going well, which I've done but I do find very hard.