On a serious note, most developers really don’t code complex algorithms all the time. The bar for interviews is way too high— to the point that most people get discouraged from pursuing a career in IT.

What about the opposite problem though? How do you weed out all the fakers, skiddies, liars, cheaters, and copy-pasters? How do you figure out who knows what, and how they think?

The actual discussion and article are much more interesting:

https://news.ycombinator.com/item/...

The solution on the thread seemed to be "work for smaller companies".

My coding interview was this: We are good as long as you can code.

I sent them samples of my work within a couple of hours of my interview. They provided offer next day.

You've got a great point. The thing is that some companies (namely Google) avoid False Positives and some are applying for the wrong role (the guy in the OP's screenshot is a good example of this).

@endor You'll never do that in an interview. You only find that out on the job - that's what a probation period is for.

Think I've ranted about this before. This tactic might have worked well when Google, Facebook, Amazon etc. were the only "cool" companies everyone wanted to work for - but these days a lot of good candidates will just think "screw that interview process" and apply to another cool, well paid company with a much saner barrier to entry.

I suspect they're losing a lot of good people because of it, and it won't be long before they're forced to rethink.

@endor

I've hired about 50 devs in the last 3 years, and interviewed a bunch more.

The threshold to get an interview at our company is to write a simple standalone feature which has actually already been built in practice by us:

A small dashboard, which visually aggregates some statistics about end users.

In the example repo there is ONLY a csv file with the data, and a readme with the requirement "display this data in a graph, display the sum of this metric, and make everything filterable by some property x"

It's nothing extreme in terms of logic, a minimal product can probably be set up in 30 minutes.

But the requirements are very vague, on purpose. There is no listed tech stack. There is no framework, or programming language. Just... "make this for me".

Because that's pretty much what the average PM will tell a developer.

I judge them by a whole bunch of things:

1. Do they build what they think is expected, or get back to me to ask for clarifications?

2. Do they build fast and minimal, or make it a huge project with bells and whistles?

3. Do they write plain code, or use a framework?

4. Can I read the code and understand it? Is the structure & naming helpful or confusing?

5. Do they make a frontend-only website where you paste in the CSV? Android APK file? Set up a GraphQL API? Qt linux desktop app? CLI ncurses utility? Do they render the result as animated SMIL SVG in the browser console? (yes -- all of these happened)

6. Where is the processing/aggregation happening? SQL? Backend looping code? Worker queues?

7. Would their solution scale if I feeded it 100x the amount of data?

8. Tests? Docs? Docker container?

There are no immediate "rights" and "wrongs" in above choices, but it gives me an idea of their approach -- what team they might fit in, and in what position.

For example: For some problems we need lone wolf optimization-crazy devs who autistically bite themselves into an issue until they find a solution -- for other problems we need critical thinking social prototype-builders who aren't afraid to continuously challenge PMs.

@endor Show your projects or the project that you are currently working. It's a 5 hours interview so you have all the time to explain everything.

@Berkmann18 Applying for the wrong role? Google and big tech Silicon Valley companies only ask Leet Code questions.

Ironically, I doubt I could pass an interview at one of the cool kids companies for a position doing what I do every day because the interview questions do not remotely resemble the actual job.

When I conduct interviews, I give a simple take home assignment, much similar to our daily work. If the code seems good enough, I then call the candidate for a second interview, where I discuss the assignment and suggest some small changes/features to code on spot. This is just to ensure that there was no plagiarism involved. Works great, takes little time and never had a bad hire.

@endor I'm pretty sure we could take ideas from other industries outside of technology that have already solved this issue. Industries that have existed long before programming. These concerns are nothing new and have been managed. The tech industry could fix this by doing paid trial periods, training people, accepting that there is always risk when hiring, etc.

Last job I had, the interview test was completely different from the work

@TheBeardedOne Bait and switch!

Been there done that 😠

This one time when I took an interview for Toptal. I told them I was quite good at PHP.
They threw an exam where I had to create graphs with that using data in a tree format.
I knew at the instant that even if I had written code for a millennia, I would never pass 😂

@endor big companies usually take upto 6-7 programming interviews.

I am pretty sure that if those were replaced by actual development interview in different environments with slight modifications, the company would be able to identify the better candidates than those programming ninjas.

Infact i feel the whole system of coding as filter is flawed and more prone to error. Today, you can mug up 1000 common questions and crack first few rounds of 90% of the companies. And most of the companies don't really have programming researchers, so the interviewer might also be some developer with a lost touch on modern algorithms