3 ms·
There's been a lot of threads like this recently that discuss changing the hiring process to more closely resemble day to day work and working with an actual co
by perfect_wave 8y ago
There's been a lot of threads like this recently that discuss changing the hiring process to more closely resemble day to day work and working with an actual codebase.
My question is how does this work for new grads and people that haven't worked in the industry before? Are they using these new techniques to hire recent graduates/people that haven't worked as a software dev before? Does this kind of process adversely effect those who haven't worked as a software dev before?
I'm not trying to say that algorithmic/leetcode type problems are a better solution, but rather questioning whether this form of interviewing has some kind of bias.
- 52-6F-62 8y ago> questioning whether this form of interviewing has some kind of bias. In the case above—the bias is toward experience. I don't think that's a bad thing. Context is important, however. I haven't read any Slack postings, but if they're asking for tangible experience this kind of gatekeeping makes more sense than textbook questions. If they're hiring for an entry-level role then a different approach might be merited.
- guitarbill 8y agoCurrently, the existing form also has a bias - towards CS and top CS universities. Yet I keep working with great self-taught engineers from a variety of disciplines, some of whom don't even have degrees. Maybe a shift in hiring wouldn't be a bad thing. As for how, you could focus more on logical thinking, user experience considerations, technical writing, or other, softer skills. For a lot of grads, we already have to re-teach them the language, as universities don't seem to give marks for consistent style/using linters/unittesting/best practices/comments/writing documentation etc. In the time it takes to break these bad habits, you can definitely teach somebody who's technical and done a basic programming course a lot of things.