Hacker News Reader

Comment by majormajor | Hacker News Reader

Now imagine if instead of coding exercises we had the interview process from other industries that weighs degree and past experience more heavily in the absence of any other sort of testing. What would it look like to break in then? Completing a BS in your spare time?

EDIT: Most ideas I've seen about replacement for live coding - like take home projects or contract-to-hire - are not really any more friendly to people with busy schedules anyway.

View on HN

The craziest part of tech interviews for me is the way its just accepted that you do it this way regardless of how long someone has been in the industry.

If companies were grilling people new to the career trying to figure out if they could FizzBuzz their way out of wet paper bag (I realize some can't) it would be one thing. Without a track record you don't have much to go on, but the fact that you can work in the industry for decades, ship well-received products people have heard of, have a long list of references willing to verify that you were instrumental in shipping those products, and a lot of companies still expect you to jump through "reverse this string in place" type code puzzles seems kinda bonkers to me... but a lot of the industry just accepts that This Is The Way.

You can bypass this with direct personal connections of course, but its weird to me that so many companies put effectively 0 weight into prior easy to verify accomplishments if the people looking to hire don't know the person on a personal level.

Is “reverse this string in place” really a puzzle to you? Seems like a straightforward and realistic (for low level programmers) exercise.

I've done a fair amount of startup interviewing, and my biggest takeaway was that I had no ability to discern if someone's resume on its own was fluff or real. And often, there seemed to be an inverse correlation between how impressive someone sounded and their actual technical abilities. It's possible I'm just missing some techniques or judgement but I don't think so.

I don't think that FizzBuzz/similar gotcha-type questions like that are useful, especially since most of them are all over interview prep sites, so I don't use them. But I've definitely interviewed people with impressive-looking resumes who straightforwardly didn't seem to be able to code; they couldn't respond to simple questions ("You mentioned you used Language Y in this project; what do you like and dislike about that language?") or were clearly bullshitting their responses. I've felt insulted at times when I get FizzBuzz in an interview, but I kinda get it.

All that said, this is a systematic issue that gets blamed on individual interviewers when the blame should fall on the company. I'm a decade into my career, worked at companies of all sizes, and I've never had or heard of anyone getting trained in interviewing. Outside of informal efforts with coworkers, I've never had a job provide me with a rubric for what I should be interviewing for (shit, I usually find out I'm interviewing someone day-of or day-before). If companies gave a damn about interviewing, I think the process wouldn't be so slapdash, and fewer interviewers would fall back on crap like FizzBuzz.

Only for those that are stuck getting a job as soon as possible and cannot afford to say no.

Otherwise there are plenty of companies that haven't fall into leetcode cargo cult.

My experience is that generally you can't bypass leetcode interviews via networking.

At most, you might be allowed to skip the phone screen. Or you might be given slightly more leeway in getting the solution.

There are exceptions of course. One close friend/ex-colleague has an uncanny ability to network himself into a coding job at various NYC hedge funds. These being hedge funds, they all pay at least above average (we're not talking about Citadel or Jane Street here), but the downside is that he has to be very unpicky about what the role exactly entails. So this can lead him to very unsexy jobs like shuffling XML feed files back and forth or doing MS Access/Excel VBA stuff, etc. But he can snap his fingers, make a few phone calls to executives and managers he knows at multiple mid tier hedge funds, and start working in a matter of days.

Or how impressive their GitHub is.

Or another mostly (rightfully so IMO) choice you see here. Set a low bar to hiring but have a probationary period after which you fire a notable percentage.

Yeah probationary period would be great for companies, maybe better for people trying to break into industry (unless they can't fired and can't get their old job back), and not so good for most people already in the industry.

From looking at job postings, there's no shortage of jobs for people already in the industry, and a proportionally much lower number of positions for entry-level. Every company has open positions for seniors, but no one wants to train them up.

I think this is mainly a side effect of the kind of work being performed at companies has leaned over the decades towards an increasingly bimodal skills distribution, and the entry level work's sophistication is eroding from advances in automation and continuous improvement feedback loops.

For example, I see at all of my clients entry level help desk positions to do things like help with provisioning a new employee's Wintel laptop, answer internal software packaging problems, intake VPN trouble reports, that sort of activity. But not nearly as much as when I entered the industry, because so much has been automated away or folded into centralized management systems, and the trend continues with advances in desktop engineering. On the other hand, I see an explosion of demand for the desktop engineering team positions.

This is being reflected in many other IT areas as far as I can tell. There is a constant push these days at all my clients to automate all repetitive work, and a much bigger appetite from leadership to automate entry level work even when the ROI payoff is longer than 1-4 fiscal quarters than when I started. The push isn't due to direct labor savings though: it is to drive down variance of configurations exposed to the more senior and expensive roles, so the real high-payoff automation can really shine, and they can reduce business-as-usual work hours remediating the impact from those variances.

You still have to decide who gets the probationary period and who doesn't. To figure that out you still have to do interviews and filter. Probationary periods don't solve anything except it makes it easier to fire people before the end is over.

Firing people is not exactly hard in the USA.

It's perhaps not hard but the expectation if you take a new job is that you won't be randomly fired in a few months because you don't meet some unstated high bar.

Every new hire has a probationary period to it. If you go into a new job thinking you'll make it past 6 months automatically, then that's a big assumption. While it shouldn't be hard to just do your job and get past the probation period, it's hard to know if the company didn't just hire a bunch of people to get past a crunch without an intention of keeping them.

Implicitly. But there's a difference between "wow, you're a bad hire" and "you're not an 80%er."

"Does not meet expectations" is always a cop out, but a great catch-all if aren't an 80%er.

I agree with your second sentence. Your first is much less of a thing for people like me. Sure, an impressive github is...impressive. However, I have never posted anything publicly to github, so my existence would look sparse which is also the same description for my social profile. I just don't use github for side hustle type of projects.

I have a decent amount of commits to my Github, but it's to 98% private projects. Things that may become products someday. Don't have a whole lot to show potential employers. My day jobs have always been private or onprem repos.

I think take-home projects might take the same amount of time as leetcode, when you count studying, but are much less stressful. As long as enough time is given.

This really doesn't fix the problem of breaking into CS, and it's not even practical when there are too many candidates. Leetcode gives a gigantic number of false negatives, but that's a price companies are willing to pay.

I don't agree. I much prefer to spend one hour doing a live coding interview than spending 24h working on a test. It is much more time spent, and therefore more stressful.

If you can ace a 1 hour coding interview without any preparation then more power to you! But many of us have to spend months doing practice problems to perform well in that 1 hour interview. I’ve heard many stories of people doing hundreds of practice problems to pass these kinds of interviews.

I’d much rather dedicate a weekend to solve a take home challenge using technologies I already know than dedicate many months to learn a set of algorithms I would rarely use.

I make a point of never doing "projects" during a recruitment process. The fact is that there are too many good opportunities out there that will not require me two spend a full day or even several days in a week to complete a job application, without compensation. Whenever I hear that there is a "project" to complete, I just tell them that I already have tons of projects to work on and pass the "opportunity".

Reply on news.ycombinator.com