Your experience is not enough. I've seen candidates with a resume full of experience that are very good at talking fall flat on their face on incredibly simple coding problems. I can't tell from a discussion if you faked it. Lying is not as difficult as you think it is.

Bit of a false dichotomy don't you think? Surely a 'incredibly simple coding problem' is different than whiteboarding leetcode. Perhaps your questions aren't enough?

Not necessarily. Leetcode problems go from “just iterate over the collection collecting some data as you go” to “Knuth solved this once and thankfully he wrote it down in a book for us mortals”.

Maybe part of the problem with these threads is that posters don’t clarify exactly what they’re complaining about.

Yes, I'd agree.

I think you can asses the knowledge of a person better by asking meaningful questions than asking to write a binary search or sorting integers in place. Unless you want to hire juniors.

For some things yes. I just can't understand the resistance of people who write code for a living to be asked to write code.

For typical dev jobs, hardly anyone writes sorting/searching algorithms, or algorithms at all. In fact, if someone working on web/apps/database stuff is spending time on algorithms, they are doing it wrong. Algorithms are a sort of pleasant luxury for most devs.

Depending on details, it's similar to asking an author to recite, verbatim, Shakespeare verses and calling gotcha on every mistake.

There are situations where it is legitimate, but for app/web/db devs it's just a rigged trivia competition.

Then what should the interviewer ask when it comes to coding question?

Take home small project? "Half" hates that.

Leetcode? The other "half" of population can't stand that.

Fizzbuzz? Too easy.

No code? How can they tell you can code, naturally?

Framework specific questions? Write something in Flask? What if you're looking for someone who's good at development but have not used a specific tech stack?

As the interviewer, I approach candidates with an open-ended friendly gesture. I tell them flat out I want to assess their coding ability, but on grounds they are comfortable and familiar with.

Before the interview, I tell them to bring whatever materials they want to the interview, whether it is virtual or not. Books, notes, videos, whatever, I don’t care. The materials are to support them showing off to me, in their favorite language, with their favorite ecosystem (editor, IDE, compiler, version control, etc.), solving a typical task they address that takes up about half a page (or more) of code on a standard US letter or international A4 sheet in 12-point Courier New, 1.5 inch or 3.8 cm borders, no lines that are entirely a comment (when counting just code).

The hyper-specific layout specifications were emerged by all sorts of crazy responses I got in the early years when I started this approach.

Could be a standalone program, a function, a code fragment, a library, really anything. I’m pretty comfortable in a very wide range of coding environments, and always happy to learn new ones, so I’ve been comfortable navigating the responses I get.

I even tell people I don’t care whether it is their own code or something they literally copy and paste off the Internet. But they need to be ready to talk about it, and take it in different directions. Just tell me ahead of time the toolchain, materials and code they chose.

I tell them I’m going to ask them to teach me about the code, and ask questions to clarify for myself along the way as if I’m going to take it over and maintain it myself, and customize the code and they will help me troubleshoot the customizations.

Through this approach I’m looking for the ability to communicate about code. Without springing surprises upon them. Being able to code is table stakes and this approach quickly flushes out who cannot code at a specific level required for the position. But I work exclusively in settings where there are teams of coders, and even “lone wolf” coders must be effective at conveying what they’ve built to others in case they win the Powerball/Lotto.

I can work with a variety of levels within a certain band of coding ability. I can work with someone who isn’t familiar with my clients’ specific toolchains. I can work with poor documentation, commenting, and writing skills. What I’ve been unable to solve for so far though, is someone not only utterly incapable of communicating what they’ve coded, but completely indifferent to improving.

You’ve missed some other formats that are already used in production. Domain-specific pair programming exists for both web and mobile engineering interviews. There’s also “read this code and debug it” which is an underrated format.

I’m not even sure the Leetcode style needs to be abolished, so much as it can be tweaked to remove some of the additional pressures of the format (time limits, stress from monitoring, overuse of memorization)

> What if you're looking for someone who's good at development but have not used a specific tech stack?

Then you have an interview specific to that use case of candidate. It doesn’t invalidate the format used in interviewing other types of candidates.

> The other "half" of population can't stand that

There will always be, I think, people who don't like whatever way you choose to do software job interviews, because they're not good at it, and then, some of them don't like it.

> Take home small project

Hmm yes it's unfair that some people don't have the time. What if everyone got to start at the same time, say, 12:00 UTC the 1st Saturday each month, and everyone got exactly 2 hours. Maybe that could work also for people with kids -- after all, 2 hours isn't much more than travelling to and back from an on site interview (in the same city).

Time and days could vary, trying to make it work for everyone

You can evaluate code other ways, like a take home to be discussed at a later interview.

"Half" population over HN dislikes take home: argument ranging from waste time to pay us if you want us to do your job (I highly doubt 98% take home asked candidates to solve real business issue the employer are facing with since take home has a deadline that is longer than in-person interview but also take into consideration your time).

I've seen this counter-point come up so many times. It's true, some times people might lie and be good at talking. Amongst programmers, though, that is simply not true, at least to the point of being frequent enough that we need to subject everyone to obnoxious whiteboard and leetcode interview formats.

And in the event of the [rare] mistake in hiring someone who does this, you will know quite quickly after they start and you will fire them. Problem solved.

Look, I only have anecdotes to offer, but based on my experience, you are simply wrong.

It might be a different place, a different market from yours, etc. But at least here (and I've verified this anecdote with numerous people), many people who have very high experience levels simply can't code, at all. Or at least, can't do it given the coding task we give them (2 hours with a computer and full internet access, to do a few tasks in Python).

I'm not saying that people are lying on their resumes - just that supposed experience in an impressive sounding company doesn't necessarily translate to real world coding ability.

That may be and it could just be coincidence or location or whatever. Don't get me wrong, though, I have definitely interviewed highly (well, supposedly) experienced software engineers who, when faced with actually writing and reading code, could barely understand. So, I acknowledge that it does happen but just that in my experience, not overly often.

In the times that I have seen it happen, though, I almost always wonder how the heck it's possible? Either they really did lie about their experience (possibly but let's assume not) OR they have worked at places that didn't interview well (?) somehow just skated by for years on end? Or maybe there is another possibility for why this happens.

This could perhaps be construed arrogant, as though you're able to pick and choose who you interview for, but now that I've been through such an annoying amount of full interview chains until I was inevitably rejected, I think the opposite is true. The better place to spend your time, unless you're deliberately grinding data structures and algorithms problems, is on other companies' interviews who aren't just hiring arbitrary programming/salary/status ladder chasers (not there's necessarily anything wrong with that if you are one of the first two, or maybe the third).

So many companies try and do the FAANG thing now, that if they aren't going to compensate you accordingly for the same work, when really what they should be looking for is experience and general competency, then you might as well not interview with them. It's truly an unbelievable amount of time and energy involved in some of these, and there's so much variability in how you're evaluated, that it's probably not worth it.

A graph of "Interview Effort vs Total Compensation" should become an industry meme so that eventually HR are required to show on job ads where the advertised position lay on the graph.

How do they react to being told that? I don’t imagine many companies are prepared to rework their interviews on the fly like that, so my naive guess would be that they continue with the interview and proceed to offer the original salary they planned to

Few years ago I went to an interview at EA for some infrastructure engineering job. And the technical person/director conducting the interview asked me some FizzBuzz questions. I provoked him by saying: "let's take 30 minutes you and me and see who can write more FizzBuzz variants and more performant." He replied he doesn't have time for bullshit. I asked him why he assumed that I had time for bullshit? And that was the end of the interview.

The previous answer he disliked was to the question of what would I do if something happens and he is not available for me to ask him to take a decision. He expected that I'll fire him a mail. But instead the answer was that I will assume the responsibility and take the decision myself.

After the interview I was glad I did not work for them.

My reading of your story is that you decided during an interview that it wasn’t a good fit (totally fair!) and then responded to that situation by rudely provoking your interviewer. If you think that’s an appropriate response in a work setting I would suggest you work on your interpersonal skills.

Your coworkers have feelings and you want them to have positive feelings towards you since that makes it easier to work together. Deliberate rudeness kinda breaks that.

I am not rude to people. I want people to like me. I do respect people. One thing I don't tolerate, though, is being treated poorly.

By that point I was looking to terminate the interview. Looking retrospectively, I should just have stand up and thank them for their time. That person rubbed me in the wrong way and I couldn't support the belittling.

Nah, some of these manager types are a little too full of themselves and could use a reality check. He did them a favor. If enough people do this, maybe late one night this manager may start to wonder if there may be a point. If we all smile and nod things will never change.

It's been a while since I interviewed but that second one has always come up for me, and I find it exceedingly horrible.

Why can't the business just say "the policy is that you email a manager/call another manager/assume responsibility" and that's the end of it? Getting quizzed on the "correct" answer to their business policies is absurd.

It's perfectly reasonable for interviewers to ask FizzBuzz type questions. Many candidates can't answer them, so it's a good quick filter.

I'm not surprised he didn't have time for your bullshit.

I agree that other question is stupid. Clearly it depends on what the something is. He shouldn't expect an email for every decision so either he's a crazy micromanager or there's no valid answer.

I've just told numerous companies that I won't do it, and they don't care, because they're just trying to fill seats and the sellers market isn't what some people make it out to be.

I am not searching for work. The recruiters are reaching out to me. And many companies are not trying to whiteboard me.

I am searching for work, but these are largely asked by recruiters of me. It usually goes 0.5) Call with recruiter 1) coding test 2) call with 1 - 3 other people 3) Call with CTO or something 4) usually there's some other call

I've started saying no to these though

When I was searching for jobs I got the best offers from companies that didn't require code interviews nor they required too many meetings.

Well, that gives me all the more reason to try and continue to avoid these tasks. It is genuinely distressing though how many mediocre companies are adopting these horrific interview chains. More often than not starting with some multi-hour coding task before speaking with anyone worth speaking to. It's pretty bad.

I had someone hiring a web/app dev position and they had me make a 2D platformer game for a coding task... I still have no idea why.. It was some education startup trying to find someone to write socket code. They were really nice but by the end of it I wasn't super stoked on coding tasks.

>How do they react to being told that? They tell me that this is how things work for their company. Which means I do not have to waste my time with them.