Ten years of experience, still failing phone screens • Hacker News Board

Re: Ten years of experience, still failing phone screens

#291

Post by creamytaco » Sat, Dec 11, 2021, 7:46 PM UTC

vanusa wrote: post #280

creamytaco wrote: post #254

Earlier quoted context omitted.

Your post ought to be ample proof that subjective opinions (like the one you display here) are not solid grounds for hiring decisions. When looking at this person's Github page, I -unlike you- see a vast number of trivial projects that can best be described as regurgitations of other people's work. Even worse, if you actually look at his first pinned project ( https://github.com/kevinburke/nacl ), you'll see that it…

I never said you should just hire someone on the basis of their repo. But rather, if you're looking for a basic smoke test which can answer the question "Can this person actually code? Do I want to spend more time engaging them?" -- there are better ways to do that than expecting them to cram on a list of algorithms to recite over the phone. Like looking at an actual work sample. The fact that you looked at this work…

Engineering is not about whether someone "can code", but whether someone can _engineer solutions to problems_. Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?

This is also what a lot of those engineering interviews are trying to ascertain, in a quantitative manner. I couldn't care less about someone's degrees or ivy league schools or Github projects (in isolation). These are all secondary -if that- considerations, problem solving ability being primary.

Re: Ten years of experience, still failing phone screens

#292

Post by b3morales » Sat, Dec 11, 2021, 7:52 PM UTC

LanceH wrote: post #124

I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't hav…

Very much this. Leetcode is terrible, but the checklist of trivia suggested in the essay is equally terrible, because it's too easy for a genuinely good programmer to simply not have experience with topic X. Or, for more experienced candidates, to not have dealt with that topic for several years and not have the knowledge fresh.

Re: Ten years of experience, still failing phone screens

#293

Post by GiorgioG » Sat, Dec 11, 2021, 8:05 PM UTC

heavenlyblue wrote: post #246

GiorgioG wrote: post #202

Earlier quoted context omitted.

This is how I got a job with a bunch of really smart folks in the early 2000s (they were all MIT grads and I was a graduate of a state liberal arts college in NY.) It was several rounds of interviews and a couple of the folks interviewing me (who clearly liked me) warned me that the interview at the end would be the hardest because the interviewer was an old non-nonsense engineer (MIT CS degree and MIT MBA.) It was i…

So that engineer was a full-nonsense interviewer :)

I suppose in my case he might have been less effective at assessing my technical abilities (there were multiple technical interviewers throughout the day.)

Re: Ten years of experience, still failing phone screens

#294

Post by vanusa » Sat, Dec 11, 2021, 8:29 PM UTC

creamytaco wrote: post #291

vanusa wrote: post #280

Earlier quoted context omitted.

I never said you should just hire someone on the basis of their repo. But rather, if you're looking for a basic smoke test which can answer the question "Can this person actually code? Do I want to spend more time engaging them?" -- there are better ways to do that than expecting them to cram on a list of algorithms to recite over the phone. Like looking at an actual work sample. The fact that you looked at this work…

Engineering is not about whether someone "can code", but whether someone can _engineer solutions to problems_. Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github? This is also what a lot of those engineering interviews are trying to ascertain, in a quantitative manner. I couldn't care less about someone's degrees or ivy league school…

Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?

Using the example you disparaged (his NaCl implementation), I would say:

"On first appearances, clearly yes. The problem was to adapt the a set of standard Go functions to a foreign interface - something one does quite a lot in an engineering environment. Also, the fact that he's aware of projects like NaCl and seeks to learn from the likes of Bernstein and Lange is a positive signal."

If I wanted to, perhaps I could drill down into the code and/or the NaCl spec itself. I don't know Go, so for all I know, maybe his code is actually horseshit. But all I'm saying is - from first appearances, definitely a positive signal. Infinitely more informative that FizzBuzzing (which would insult both his intelligence and mine).

This is also what a lot of those engineering interviews are trying to ascertain.

I've already made it clear that a glance at a repo does not obviate the need for an actual interview.

Re: Ten years of experience, still failing phone screens

#295

Post by ghaff » Sat, Dec 11, 2021, 8:46 PM UTC

heavenlyblue wrote: post #250

oneepic wrote: post #112

Earlier quoted context omitted.

If I was the candidate, and you informed me the interview would be recorded with video, I would politely thank you for your time and end the call.

Why? It could easily be optional by the way. I would be ok with the recording as long as they don’t make my sign the form allowing it to be used as part of some public campaign.

There is mostly no such things as "optional" in those sorts of situations. It's like "Here's a take home project. It's purely optional but it would give us a better sense of what you can do."

In other words, maybe if you utterly wow us in-person you'll get in anyway. But probably not.

Re: Ten years of experience, still failing phone screens

#296

Post by Jach » Sat, Dec 11, 2021, 9:14 PM UTC

b3morales wrote: post #287

Jach wrote: post #235

Earlier quoted context omitted.

I love this because I agree 100%. I accepted the idea that they were "out there" but only really internalized it after I interviewed someone with a Masters in physics who couldn't make any progress on my simple problem. (The problem does assume you can understand the concept of a geometric line, but I give the two line equations most people first run into in junior high, among other things, I'm not testing recall.) E…

> 1) you can detect that like in the first day , or at least first week 2) the amount of damage they can do before detected is small... But the cost is actually minimized already by rejecting in the interview. Just like finding a bug while writing unit tests is cheaper than QA finding it after you make a build, even if QA does so in the first hour of testing.

There's a tradeoff between the costs of trying to detect possible issues at various stages, and the costs of damage if those issues aren't caught until later. This makes the caught-earlier-is-cheaper analogy not always hold, because the costs you spend to detect an issue at some stage can easily outweigh the costs of the issue itself at any later stage. Hence the industry doesn't follow NASA practices, or even more reasonably make use of TLA+ as basic professional practice like unit tests have largely become. Many bugs have such negligible impact that they remain unfixed, regardless of when they were caught, regardless even of whether the customer found them or knows about them. We also realize that some bugs still make it past everything and get to production, so it's worthwhile to spend effort trying to reduce the cost of production bugs, which might for instance involve having a faster and smoother deploy process.

So in hiring, there are costs companies pay to avoid a bad hire, and costs that result as a consequence of bad hires -- which they mostly can only estimate because of bad hires getting through anyway, everything on the consequences side is formally probabilistic. You can think of it as hiring-filter-costs + P(bad-hire) * consequences-of-bad-hire. So yes, if P(bad-hire) is 0 because of your amazing hiring filter, then you'll never have to pay for the consequences-of-bad-hire. And supposedly, increasing hiring-filter-costs should decrease P(bad-hire), though over time we've found many practices that don't actually do that, and smarter companies have stopped doing them.

My thinking boils down to we can and should reduce hiring-filter-costs (which I want to think of as including opportunity costs and negative externalities on the whole industry, but it's not necessary), but fear prevents even experimenting at many places because there's an idea that any reduction will increase P(bad-hire) too much, and consequences-of-bad-hire are too large. So, why not focus more on identifying and lowering the consequences-of-bad-hire? Do that, and we'll also be able to lower hiring-filter-costs even if they increase P(bad-hire), which they aren't guaranteed to do anyway.

Re: Ten years of experience, still failing phone screens

#297

Post by sdiupIGPWEfh » Sat, Dec 11, 2021, 9:43 PM UTC

MathMonkeyMan wrote: post #252

sdiupIGPWEfh wrote: post #226

> Coderpad must work for some people since companies are able to hire a nonzero number of engineers, but it is definitely not a good fit for me. Seems everywhere I've applied recently has been using Coderpad. Lately I've been accepting interview requests for principle roles from on-site recruiters, and I've been consistently rejected after these Coderpad tech screens. What's bugging me, however, is the "challenges" h…

I've never done this, but you might consider getting an experienced interviewer to do a mock interview with you (of the same sort you've breezed through before). It might be a coincidence that you have been rejected multiple times, or it might be some small behavioral thing that someone could tell you about. Alternatively, you can say "screw this," and I wouldn't blame you.

Huh, I like that idea. Thank you. Possibly a good excuse to get in touch with some former colleagues as well, which I suppose couldn't hurt either.

Mercifully, I'm not quite yet desperate about leave my current role. But I do feel like my career (and salary) progression is stagnant; not seeing much opportunity where I'm at. I'm thankful for what I've got, but I think it's smart to be looking. Just found it weird to face rejection so much from people reaching out to me in the first place, in a supposedly hot market.

Re: Ten years of experience, still failing phone screens

#298

Post by vanusa » Sat, Dec 11, 2021, 9:44 PM UTC

treis wrote: post #209

vanusa wrote: post #2

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain…

>Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing Perhaps it's just me, but I took a look and I'm not convinced. Nothing jumps out to me as overwhelming proof of programming ability.

Nothing jumps out to me as overwhelming proof of programming ability.

Are you suggesting that leetcode tests provide "overwhelming proof of programming ability"?

Re: Ten years of experience, still failing phone screens

#299

Post by redis_mlc » Sat, Dec 11, 2021, 9:49 PM UTC

vanusa wrote: post #17

redis_mlc wrote: post #3

Earlier quoted context omitted.

> This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Looks like he has ADHD. Maybe somebody with more time can go through his blog post line-by-line and figure out what's going on. Most of my Coderpad stuff compiles and runs the first time, so I don't use his incremental test method, or see a need for it. Maybe he learned programming on heavy-weight IDEs and got…

Looks like he has ADHD. That sounds ad-hominem. I found the post perfectly readable. Maybe he learned programming on heavy-weight IDEs and got trapped mentally in those? Maybe he just thinks differently than you do? His body of work is not suggestive of someone "trapped" in an IDE or other dysfunctional midset.

> That sounds ad-hominem. I found the post perfectly readable.

I wasn't referring to his blogging style, I was referring to his description of his "struggle" development process.

> Maybe he just thinks differently than you do?

He certainly does. He might want to find out what's going on by talking to other developers.

One of his comments in this thread says he uses vim, so it's not an IDE issue.

Re: Ten years of experience, still failing phone screens

#300

Post by redis_mlc » Sat, Dec 11, 2021, 9:54 PM UTC

kevinburke wrote: post #15

redis_mlc wrote: post #3

Earlier quoted context omitted.

> This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Looks like he has ADHD. Maybe somebody with more time can go through his blog post line-by-line and figure out what's going on. Most of my Coderpad stuff compiles and runs the first time, so I don't use his incremental test method, or see a need for it. Maybe he learned programming on heavy-weight IDEs and got…

I use Vim, it's just different learning and development styles, I think. I’m very capable of focusing when there is a lot of money on the line.

Thanks for the followup answers.

I also use vi (no syntax/color highlighting, no plugins, original vi commands only.)

I think you should talk to some other developers and see what's going on with your ability to focus. (I'm one of the top application developers in a particular language and can actually think in that language, so that level of familiarity helps me.)