Hacker News Reader

For what it's worth on the hiring side, applicants lie (or more charitably, wildly overestimate their own abilities) all the time. Of resumes I see, 50% of them will not show up on time to their interview. Of the 50% that do, 80% cannot pass fizzbuzz.

Past companies and open source contributions are not perfect indicators. I've seen people with stellar resumes fail to even know the syntax for an 'if' statement in any language of their choosing. I've had people absolutely ace takehome exams, yet in person don't know how to write a function.

False positives are also much more expensive than false negatives, so companies would rather accidentally weed out good candidates than risk hiring bad ones.

To put some hard numbers to this: further down this thread, there's a post about how "any engineer" could answer a question the poster thinks is too easy. I looked up the question in our back end and, in fact, barely a third of people who take our quiz get it right (the correct answer isn't even the most common one!).

That's maybe a little unfair (plenty of people who aren't engineers take our quiz out of curiosity), but the basic point here - that companies are frustrated because they keep getting fizzbuzz-incapable applicants - is more-or-less accurate. That has been (and continues to be) a big part of our offering on the other side of our platform: in the same way that we can provide data about company behavior to engineers, we can provide independent verification of an applicant's skills to companies.

> Of resumes I see, 50% of them will not show up on time to their interview. Of the 50% that do, 80% cannot pass fizzbuzz.

Wow, sounds like you either need to change your sourcing or improve your early screening. If that many poor candidates are making it to the interview stage something is wrong with the process.

I should have clarified, the first interview is just a code screen. People submit resumes, and we test them with fizzbuzz. 90% of applicants are removed at this first filter.

How many (if any) of that 90% are just non-replies?

Probably 5%. It's extremely low.

Most either don't show up on time or fail fizzbuzz.

> Of the 50% that do, 80% cannot pass fizzbuzz.

If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.

> Past companies and open source contributions are not perfect indicators.

This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase? I run a tiny throwaway open source project (~600 GH stars) and even my reviews are pretty stringent. This point of view is not consistent. It's like saying "I know people that ran in marathons, but couldn't even run for half a mile in my interview."

> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.

I've seen similar. I wouldn't say 80%, but somewhere in the 20% range of people on phone screens. If I ask a similar modulo question that isn't obviously a rephrased FizzBuzz (i.e. "write a function that returns every 4th item in a list"), that percentage goes up dramatically. A lot of candidates memorize FizzBuzz without actually understanding what's happening and how to use it.

> This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase? I run a tiny throwaway open source project (~600 GH stars) and even my reviews are pretty stringent. This point of view is not consistent. It's like saying "I know people that ran in marathons, but couldn't even run for half a mile in my interview."

There are no time constraints, and no way to tell how much of their contribution is from their own knowledge and how much is copied from StackOverflow/other open source projects/etc. The point of view is consistent; I can't run a marathon, but I can walk 26 miles. That's fine for the local charity marathon, but it's not going to cut it if I want to do competitive marathons. The constraints and expectations are wildly different.

> There are no time constraints

Even ignoring the fact that you keep moving the goalposts and are taking my "marathon" analogy way too literally, the argument that any kind of real-world coding involves "time constraints" akin to a 30-minute stress-ridden whiteboard interview is just bonkers.

Programming verbally over the phone is a skill that requires learning.

I can run a marathon but I can't run 100. Your interview is one of many that I am making time over lunch. I'm tired and getting a perfect mark on a take home isn't as important as getting it done quickly so I can find time to apply to other positions before I go back to work.

If you are not paying someone to do the interview you are not going to get anyone's best. Even if you pay people are trying to juggle things to get the interview to work.

And to the parent post. 50% of people being late means they took the time out to talk to you and come to your offices and didn't gage the time or didn't think it mattered. That doesn't make them bad programmers and shouldn't even matter to the interviewer. Was the car service the employer used late picking the employee or did they have to come on their own?

There are a surprising number of people who have done marathons that couldn't run half a mile - https://www.verywellfit.com/finding-walker-friendly-marathon...

> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection. I've heard so much about this "programmer charlatan" that lies on his resume and ends up blowing up million dollar systems, but have yet to see any tangible proof.

I dunno about the back half (blowing up million dollar system) but the front half, certainly.

We used to ask "write min()" at a previous employ, and the pass rate was probably <50%. I still to this day structure my coding question around "it has to get them to write a for() loop". It's not trick questions (I understand why people don't like those, and those can die out, yes.) it's things like "here's a sample grammar, how would we go about parsing it?" which is something that I've used any number of times in my career.¹ Other candidates fail to display understanding, let alone deep understanding, about things like HTTP or Linux. Not exactly niche topics, and during this example period my employer at the time was clearly posting for "backend software engineer". And not just one or the other, but all of them, simultaneously. Since I can't establish any proof of anything, so… what other choice is there, but to pass?

¹while there are parsing libraries, yes, and I'll use those first / when I can, I would also say that 50% of the time, for whatever reason — better error reporting, better control — I end up going with a partially or mostly hand-rolled state machine or recursive descent parser. Also, while I wish people would just encode their data in something like JSON, or YAML, or whatever, it doesn't really matter, they. keep. making. new. grammars. Often inside those other grammars. Just today I had to deal with a config — a YAML config! — that wanted "key values". Turns out, it wanted strings formatted like "key:value", not YAML mappings.

> If this is actually true, which I highly doubt (I've interviewed people, too), your process is terrible at preselection.

With a bad pipeline, it's extremely likely, especially if you cheap out and try the bootcamp route (there's a reason Lambda is desperate enough they will "loan" a student you can try before you hire!).

It costs nothing to send a resume after all...

>This is self-contradictory: how/why would any open source project let someone that doesn't know fizzbuzz contribute to their codebase?

They could maybe just be making small or simple changes. Or perhaps mostly working on markup, templates, CSS, etc.

It's possible they know a bit of programming but just don't happen to know how to check if a number is evenly divisible by another number. This isn't something an open source project would necessarily know you don't know. (I agree it's something any programmer should know, but I can see how someone could contribute certain things to certain projects without that knowledge gap being discovered.)

I learned about the modulo operator very early on, but if I didn't know it existed, I'd admittedly struggle with the question for a bit and would seem like I don't know how to program; especially in a pressured interview environment. If it were Python or something I think I'd come up with something awkward like `if i / divisor == float(int(i / divisor))` within a minute or a few minutes, but who knows, maybe the pressure would mess with me.

> 50% of them will not show up on time to their interview. Of the 50% that do, 80% cannot pass fizzbuzz.

Of the people that turn up late to the interview, what percentage pass fizzbuzz?

> And, I get it, Google doesn't care. Amazon doesn't care. (There's an argument that they should.)

And yet they will still email you, year after year… as a dev that's worked in finance/academic research labs and for low funded/bootstraped startups all over the world for the past 10 years… I'll never get into these big companies because I simply try to find companies that need work done yesterday, see my experience (maybe reach out to past corps i've done work for), and give me an offer for at least a short term contract (and these big companies will never do this).

The worst is when I've think I found an interesting company (that on more than one occasion, publicly likes to complain about not having enough devs… lol), start talking a bit and they send me a triplebyte link… maybe it will be different this time, but I doubt it because these behaviors are too ingrained in a lot of corporate processes (even if its mostly "big co does this, me small co must copy"-NPC type thinking)…

I agree, To me discovery process is broken. FANG sends email every year once you have already reached onsite. But I am trying to get into this tech companies new IPO's not FANG. I have applied to many good ones.

I have Github repo. I have my own portfolio. I have wrote flutter app deployed to play store to demonstrate I can function individually and still can write production ready code. And All the above just on my own spare time.

But every company I have applied told me my skill set doesn't aligned with them. I get response from them that there is no traction on my resume. While some friends get interview after interview and others don't.

I am not saying that I am the best but we need different process where entry is given and now show me what you can do.

What I find particularly jarring about tech interviews is that they often don't adapt to the actual role you're interviewing for.

I moved from engineering to management over 5 years ago now and still in interviews for positions like "head of" in 100+ people companies or other management roles in bigger companies I got asked the usual algorithm questions.

I just have zero interest to prepare for these interviews, I don't have the time or the motivation, and I honestly just don't care about the answers. Most of my job, and my team's job, has nothing to do with them.

The world might be different in FAANG, and admittedly I have not worked there (though I have worked for other top companies) – but most companies are not at that scale, and they should not use the same metrics, particularly for management roles.

Decades of poor technical interview practices started by a blog post (the one about fizzbuzz). It's amazing how a single blog post changed the entire industry by causing such fear about "false positives". Looking at that blog post now, it's obvious how it lacks real analysis of the situation:

* The blog post complains that even experienced engineers they interviewed couldn't write some simple code on paper. Did anyone stop and think that maybe it's writing code on paper in an interview setting that's the problem? Stop and think about this. Imagine writing code like you usually do in a text editor. And then writing code with pen and paper. Backspace? Can't do that. Copy/paste some line to move code? Can't do that. Add some newlines? Can't do that. Run the code using the compiler? Can't do that. Of course most developers, even experienced ones, will do poorly under these conditions, this is not how code is normally written. On top of the already stressful situation of an interview, there's this suddenly completely foreign and limited way to write code.

* Even the blog post only mentioned fizzbuzz as a quick, easy question to filter out zero coding ability. Another way to say this, it was meant to filter out coding skill <= 0. Not skill <= 50 or skill <= 90. Zero. After that, the interview was supposed to move on to things that actually matter for software engineering. The present day interview has strayed extremely far from this. These days, you get asked two leetcode questions during an interview and even if you perfectly answer the first one, if you don't get the second one then you're an automatic fail. That was certainly not the intent of the original fizzbuzz, since answering any leetcode clearly shows coding ability. And the interview never has a chance to move on to the part that actually discusses software engineering skills. Or even if it does and they do very well on those interviews, the failure of only getting 1/2 leetcode questions correct overrules everything else since they must avoid "false positives".

Triplebyte quizzes are a much more realistic representation of job skills than leetcode quizzes.

You think literal geniuses can't solve sligtly challenging algorithm questions ?

> You think literal geniuses can't solve sligtly challenging algorithm questions ?

(N.B. I was being a bit hyperbolic, but, yes, for example, I highly doubt Steve Jobs could.) The spirit of my point is that most smart people don't care about the kind of idiotic minutia typical hiring panels ask. They care about interesting/creative problems.

I mean Steve Jobs may not be a great software developer. I don't think companies are hiring for a Steve Jobs. You could be really good at other things and not be great at programming

A SJ type is what TB would need to orient this pivot… to turn the problem around. Sourcing ideas on HN will only lead to “faster horses” suggestions. BTW did the TB interview after been lured by dark patterns on social media a while back when I was still using. Got the bloom filter from a hipster that was playing on his phone while I coded tictactoe in a langage I hadn’t used In years. Complete waste of time. Then they wanted to make profiles I hadn’t signed up for public, good thing they listened to the backlash. Just saying; it seems the management needs to use an hypothetical service like theirs but that works to find someone to help them on the angle for that pivot… a headhunter ?:-)

Tongue in cheek, good luck on the pivot guys, it is a tough problem.

I think maybe someone like Donald Knuth would have been a better example.

Maybe everyone's using this problem as their first screen:

https://keithschwarz.com/interesting/code/?dir=find-duplicat...

They usually can, but not necessarily under strict time constraints and the pressure associated with a whiteboard coding exercise.