[dahart]

> a rapidly growing population of devs who feel like they're locked out due to the technical interview process.

I’m not convinced all these articles about “hiring is broken” and “interviews are broken” actually help with this problem. They are pining for something that may not exist (and may not be possible), and failing to help candidates understand and excel within the current system’s imperfections.

I get the impression that many young devs have skewed expectations and aren’t practicing job interviews before attempting them, and believe that their coding skills are the only things that should matter. The article here reinforces those expectations by repeatedly talking about evaluating competency without acknowledging that competency in soft skills like writing and communication and attitude are often at least as important as competency in software engineering, for example.

That said, I would very much agree with your approach and that a technical apprentice is a nice way for both the candidate and the company to learn about each other. Internships naturally do this without necessarily having the expectation of hiring the intern - though I’ve seen a lot of interns hired because they prove themselves competent.

One problem with a technical apprentice role as an alternative to longer interviews is that you have to expect to not hire a large percentage of the apprentices (otherwise there’s no point). In that sense, the apprenticeship becomes a much more demanding interview, and the commitment and risks are much higher for both the candidate and the company. As someone who does a lot of interviewing and resume reading and hiring, I’m not sure I would change my interview process if I hired more apprentices (but I already spend a lot of time looking for potential over experience.)

[stove]

I would argue that _none_ of the articles about “hiring is broken” and “interviews are broken” actually help with this problem.

There is near-universal consensus that technical hiring is atrocious and yet very few people putting forth possible solutions and/or companies willing to experiment with the status quo.

My ideas are: * Real-world interview questions * Standardized testing for "soft" skills. It can be done. * Dedicated onboarding resources * Apprenticeships for entry-level engineers with dedicated training programs * Remove all names from all inbound job applications * Offer _more_ money for internal referrals. Make them on par with what you'd pay a recruiter.

[dahart]

> There is near-universal consensus that technical hiring is atrocious

I hear this a lot on Hacker News, but not inside any companies. And when asked why people think it's atrocious, I rarely get a set of answers that agree on the specifics. I'd love to hear more about what metrics show evidence that hiring is atrocious, as well as what is making it atrocious for you. What does that mean in the pre-coronavirus context? Are companies not finding people, and are people not getting jobs? I'm asking honestly and seriously, so I can improve my own hiring practices. I don't doubt there's a problem, I just don't have a handle on exactly what it is, and the reports here on HN aren't matching my own experience. I admit I don't match the profile of the average web developer, so I may be ignorant of what's happening in the broader tech world today, especially regarding recent hires from school.

In my own experience interviewing at and hiring for multiple companies over the last 20 years, what I've seen and done matches some of your ideas. We are getting and giving real world interview questions. The interviews are at least somewhat standardized. There are dedicated onboarding resources.

I haven't seen names redacted anywhere, and that's a good idea to normalize cultural or gender biases, but problematic if you want people to review your online portfolio, or if you know someone in the company who can vouch for you, both of which many candidates do want.

It is my experience that internal referrals have significantly higher chance of success, pay for the candidate is likely to be higher than for external candidates, and referrers are typically rewarded financially for the referral. Many people complain that the referral system is part of the problem under the logic that it can encourage nepotism and echo chamber behavior. I don't fully agree, but I don't think this is as obvious of a win as you suggest either, or that the majority of people would agree with it.

[TurkishPoptart]

It's atrocious but most companies won't reveal specifics because _those_ people were hired via the same process. So it plays into survivorship bias. And nothing will change.

[dahart]

Could you elaborate on why you think it’s atrocious?

I’m not sure I agree that the processes are hidden, every company I’ve ever worked for (several large corps you’ve heard of + several startups) talks about hiring practices publicly. Glassdoor and other sites, including HN, have all kinds of information & stories about what happens during interviews.

[jakkyboi]

I'll give my limited perspective.

Software engineering is a field that is both requires breadth and depth at a very high bar for acceptance. From the interviewing side and the many interviews I've been through, it often feels impossible to overcome. The breadth that the field requires leaves gaps in knowledge, where anecdotally I've been asked what's a language I'm an expert in, or to detail the deep particulars of react app development, or to solve X problem with the greatest efficiency with ease and have lots of input on your thought process. I don't mean to paint a picture where you're not allowed to test anyone on anything, but as an average dev, it feels like stabs in the dark compounded with not having a clear path to improving, because everyone's interviews are different. You can improve on the fundamentals, but that only helps so much.

To me, communication and problem solving skills are the biggest factors of what makes a good SWE. I find that most technical interviews don't look for talent that's acceptable, but what's exceptional; not for who's capable, but for who's accomplished.

My firm belief is that many devs who struggle getting a job now, could have walked into any company pre 2010 and gotten a job with the skills they have now.

This is all with the caveat of the knowledge that high salary commands high talent, but my opinion is that the bar is set ridiculously high without regard for how arduous the process is.

I have had a few very fair, but challenging interviews, and I do think that's a step in the right direction.

[dahart]

Seems totally reasonable, thanks for sharing your perspective. I’d agree that a lot of interviews can range from hard to insane. I’m really curious what that means in terms of measurable outcomes... like how many fresh CS graduates are completely failing to land a job? How many companies are failing to find candidates? Stuff like that...

FWIW, I warn people I’m going to ask questions they don’t know, and I ramp the questions up until people can’t answer them. I know it can be uncomfortable, but I also like finding the bounds of what people know. I do ask a lot of easy questions, and the majority of the interview isn’t knowledge questions at all, it’s open-ended conversation, usually about experience. I don’t have a sense for whether asking a few questions that are too hard for the candidate puts my interviews in the category you’re describing, or whether you’re talking about an entirely different level of arduous.

[bluGill]

Where I work hr won't let us ask any question that isn't scientificly proven to make a difference. It makes it hard to ask technical questions.

[dahart]

Oh that's fascinating! Can you talk about what questions are scientifically proven to make a difference, and/or the methodology of proving it? I've read bits and pieces here and there, but not seriously followed such research. I imagine that style, specific words, amount of follow-up, and even mood in the room can play important factors here in the "success rates" of certain interview questions...?

[bluGill]

I just ask the prepared questions... That is a good question but I force myself to concentrate on other interesting questions.

They have said that if we want a new question added to the list we need a good link controlled experiment : ask a random sample of candidates, don't use the answer, and then evaluate after 6 months if there is a difference between the two groups performance on the job.

[908B64B197]

If HR is dictating how to conduct interviews for engineering staff, your company has some deep problems.

[dahart]

Care to back that up with any reasons? Engineers are absolutely not immune to cultural and gender biases, the evidence may be pointing the other way, that we currently have greater than average biases in tech. Isn’t oversight likely to make it better, not worse? While it may be a problem to not be able to ask some kinds of technical questions, like the GP comment alluded to, what is wrong with the idea of trying to limit questions to those that are proven to be relevant to candidate performance? This seems similar to how I heard that graduate school performance and success in the sciences doesn’t correlate with GRE math & science scores anywhere near as much as it correlates with the language & writing tests... I wouldn’t be surprised if technical interview questions do not do a good job of identifying who you should hire...

[908B64B197]

Some technical questions are really sink or swim. [0]

I've seen interviews get totally derailed by a simple FizzBuzz question. [1]

I wonder if the GRE situation doesn't have more to do with selection bias, ie applications with a score lower than a certain threshold aren't considered at all or that folks that aren't convinced of their ability in math & science simply won't apply to graduate school.

[0] https://blog.codinghorror.com/why-cant-programmers-program/ [1] https://news.ycombinator.com/item?id=22338415