[otabdeveloper1]

Absolutely untrue.

Whiteboard problems absolutely do work.

The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.

Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises.

How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.

Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.

Source: I've interviewed a great deal of people for lots of positions over the years.

[suzzer99]

The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination of age, rustiness and an escalation of nervousness after failing a couple whiteboards out of the gate.

Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled.

The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.

[baron_harkonnen]

There's also a lot of senior devs who think they are a false negative who are not.

I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills.

When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit.

By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success.

I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.

[munchbunny]

I don't think any good senior devs are under the illusion (privately) that they're rusty at whiteboard interviews. I'm certain my college grad self fresh out of practicing for the ACM contests could have run circles around my recent job search self when it comes to algorithm stuff. I had to practice and then pass a ton of whiteboard rounds to get my current senior developer job, so I'm not saying this out of bitterness.

However, and I think this is the crux of the problem, you're not paying senior developers for that. I've never had to actually do any algorithm slinging on this job. The fanciest it usually gets is chaining some maps and filters.

On the other hand, I have had to do "rocket surgery" on critical path legacy code, write business logic in a maximally predictable and readable way, figure out how to land a non-backwards compatible change with no downtime, convince other teams to help with an initiative my team is leading, design an internal API, etc.

Doing that stuff requires experience, rigor, resourcefulness, and I'm sure you can come up with more "senior" traits. My personal complaint about whiteboard interviews, even systems design interviews, is that they only indirectly measure those traits.

[josephg]

My philosophy when hiring now is to be trying to answer the question of “how much responsibility could I give this candidate and feel confident they could flourish”. A junior engineer should be able to be given a clear spec and be able to implement it. A mid should be able to do the same thing with a poorly specified spec, in a domain they don’t necessarily have experience in. They should know how to learn. A good senior should be able to support a team to figure out what needs to be done, and move heaven and earth to get there. They should be able to fix (and anticipate) any and all problems that show up. Train people. And push back when they’re assigned a problem that doesn’t make sense, or given unreasonable deadlines. A good senior can be responsible for making sure a whole team delivers a working product.

From this perspective, a technical whiteboard interview is one of many tools. Interviews I give usually start with “so your boss asks you to solve problem X ... where do you start?”. Then I throw more and more problems at them (technical, organisational, etc) and see how they respond. “It’s in production and people start complaining that it’s slow. Where do you look first?”. “What problems do you foresee with this design down the line?”. “If you had $1m/yr budget to hire a team to scale this system, what would your ideal team look like? How would you spend the money?”. “An inexperienced team implements this and it’s buggy. What mistakes are you worried they might have made?”

Ultimately we get the traits we hire for. Being able to code (and debug!) is important. But I also want employees who I can delegate to, and trust that they’ll figure things out. I’ve been able to pass whiteboard interviews since second year uni. But I have not stopped learning, and the non technical skills I’ve gained since then are at least as important. Test for them.

[d1zzy]

Saying that "you're not payed for that" is risky. Yes, you're technically right but when you will be at your new fancy job you may need to do MANY things that you aren't technically being payed to do, so that you can deliver. That IMO is one of the essential skills a senior developer has, not that they can do things a junior developer can't, but that they have a breath of knowledge and skills that make them good junior developers at many things they aren't specialized for and are able to make use of them to get the job done. In that light, picking on "one little thing" such as the interview process using something you may not be used to or like or ever need to do when actually hired (whiteboard coding), seems wrong.

[munchbunny]

I don't think I understand your point. I was talking about how algorithms interviews map badly to the skills required by the job description. That's only tangentially related to whether you'll have to do things outside the strict job description.

[suzzer99]

For sure I wasn't the software developer I once was when I was interviewing. I'd been in an architect role at a gargantuan company and mostly POCing things for a few years. Then I went on a 7 month road trip where the majority of my brain was dedicated to learning Spanish.

However I can confidently say that it only took a few weeks of being thrown back in the mix to shake the rust off and get going again.

If I was an employer and could extend contracts at fairly low risk, I'd give devs with a strong resume and a demonstrable open-source library a chance - despite them being a bit shaky on the whiteboard.

[suzzer99]

FWIW - I'm not talking about no demonstration of coding ability at all. I'm just saying don't always assume the person who aces the coding challenge with time to spare is going to be a much better candidate for the job vs. say a dev with an interesting resume and orally demonstrated problem-solving skills - who just passed the coding challenge.

[malvosenior]

This is such a great response and I've had similar experiences. As you become more senior you also get more managerial responsibilities which can eat into your time/energy budget to stay up to date on tech not directly related to your job. You may also get more life responsibilities as you age (family...) that further erode your technical edge.

Good on you for having the introspective skills and awareness to identify the problem and do something about it.

[wuliwong]

I don't understand how this is a problem? If OP is a Senior Dev and interviewing for another Senior Dev role, wouldn't you assume that this new role is probably going to require similar skills to perform similar managerial type responsibilities?

I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.

[malvosenior]

A lot of time people will move to a new job for a more senior position than their current job. Being a Sr. Engineer at a Series A funded startup can be very different than being a Sr. Engineer at Facebook (not always, but often). I would expect a higher bar at a larger engineering organization.

If someone is effectively testing for these more difficult subject matters then it's quite possible that they themselves and other co-workers are competent in them (as they passed the same test).

[wuliwong]

Your argument basically boils down to that you think your experience is the norm and OP's is the outlier.

[dantheman]

You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.

[beat]

What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs.

As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details.

Thinking coding is important is a failure mode.

[joshuamorton]

FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews).

The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something.

And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with.

To see the second thing, I need to see concrete code.

[beat]

When I'm interviewing experienced people, I usually gauge technical skill by picking something out of their resume and digging into it with questions. If they don't really understand what happened technically, it's immediately apparent (this is also how you catch inflated resumes). And if they do, I can just keep asking more questions to get a better sense of it.

This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.

[suzzer99]

Yeah this is much better.

This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring

[joshuamorton]

> This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.

But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan.

I want to gauge both, and a coding test is a good way to measure the micro.

[suzzer99]

One problem I have is at my level it's really more about architecting than coding. Although coding is still important.

(And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.)

But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems.

It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.

[beat]

> It also takes a good architect to interview an architect

And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively.

As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.

[hellisothers]

Why is this getting downvoted?

[rhinoceraptor]

I think the most valuable engineering leader would be someone who can remove code, or at least prevent unnecessary code from being written and maintained.

Code is a liability as much as it is an asset.

[suzzer99]

Yeah but then inevitably the company starts grading on a curve. Did the dev nail every single possible mistake or bug? Did they add any extra flourishes? So you're not just testing for basic competence anymore. You're testing for devs who are really good at timed coding challenges - just like with challenges where it's tough to get the right answer in the allotted time.

Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc.

Companies get excited about a dev who aces it with flying colors.

[HillaryBriss]

> inevitably the company starts grading on a curve

which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers

[raincom]

That's what FB does these days: how fast can one code, how bug free, etc.

[everdev]

> companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough

I'd say it's the opposite. Big companies can afford to take a shot on someone and miss without materially impacting the business.

If I'm hiring developer #2 at my 5 person startup, I want someone confident and cool under pressure who has done something similar to what I'm building so many times in real life that the coding test is a cake walk.

A dev hire on a small engineering team (< 5 people) can make or break the business. I'm trying to de-risk that hire as much as possible. I want to design a test that 90% of people will fail so I can find that top 10% developer.

Once I get to 15-20+ devs, I'm much more likely to relax my criteria and look for a diamond in the rough.

[stuxnet79]

I agree. Hiring has both a non-trivial time and money cost. The very same companies that would benefit from finding diamonds in the rough usually don't have the resources to find these devs in the first place. The modern coding interview is designed for the processes and needs of larger tech cos with large amounts of resources. Cargo cult at your own discretion.

[justfor1comment]

This is reasonable from your vantage point. But why should that talented person work for your fledgling startup? Wouldn't he or she have more options on the table?

[everdev]

Absolutely. Then it's all about selling the team, the company and it's potential. If you can't sell your vision to your employees you probably won't be able to sell to your customers either.

[HillaryBriss]

yes. also factor in the probability of receiving a huge number of qualified applicants: for Google it is as close to 1 as it is for any company. for the startup it's far lower. Google does not need to take these risks.

[C1sc0cat]

Even FANGS need developers who can get stuff done to make up for all the JIRA jockeys.

[thorwasdfasdf]

> And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.

Seriously, Where are you finding these candidates? seriously.

I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".

[jboggan]

I've come across them repeatedly and in some cases they have formed the majority of candidates that got to a phone screen. It's a result of our industry having many high paying jobs in relative physical comfort with no hard gatekeepers. Can you imagine what interviewing for a first year law associate's position at a BigLaw firm or a radiology residency would be like if there were no law and med schools and no board certifications?

Considering the rate of false positives in any software engineering interview process there is every incentive for the underqualified and unqualified to "fake it 'til they make it". It's also difficult to tell the difference between someone failing upwards and someone aggressively managing their career by switching positions with lateral raises in this hot job market, hence the need to distrust the skill of even senior developers and force this rigmarole on every level of engineering talent.

[rootusrootus]

Crappy head hunters. I have some outside firms who have sent me good people very reliably, and then once in a while HR will make me try another company who probably gave us a cheap quote, and I'll get a series of terrible candidates from them. I've even been given outright frauds -- people who paid someone else to phone screen for them.

[vidarh]

Cut and paste answers to initial screening questions was my favorite. How I knew they were cut and pasted? I got paranoid after some suspicious answers and started doing searches for random lines from the answers.

The included such brilliant things as cut and pasting an answer from a forum that was followed by a dozen comments of people explaining how wrong that answer was, and someone who answered what should have needed a short sentence with two pages from an Oracle manual giving an answer that did not apply to the question. .

It's not that we expected everyone to be honest about not using Google - it didn't matter, it was an initial screening question. But we did expect them to at least bother to restate the answer in their own words if they looked it up. And get it right..

[tkahnoski]

I've used simple problems 'write a function to give me a maximum from a list' and 'provide a list of test scenarios to validate this function'.

This has a surprisingly high failure rate even in cases where we just email it to the candidate and discuss in a phone interview the next day. I don't think it has anything to do with a persons ability to program but likely derives from a person's ability to understand a work request.

[ben509]

"I need a function to add two numbers together."

Innumeracy is the norm: I'd guess > 85% of people don't understand the concept of a function.

And they probably can code if they were working independently. Or they've done some classes, wathced some videos and think they understand it.

But when you add the pressure of an interview, your unpracticed skills fall apart. Also, you have to think on your feet to fill in the blanks in a question.

That's how it should be, because we're not hiring hobbyists; candidates need to be able to demonstrate that they're pros, and able to do so under the pressure of an interview.

I've done my share of phone screens who were flatly unqualified as developers. (Thankfully we've never had someone completely clueless land an in-person interview. That's also a disservice to the candidate as we should provide better guidance through the phone screen.)

Some of them are junior, possibly they lie on their resume and simply keep applying to job after job. That's the 99% that Joel wrote about[1].

You also occasionally get guys who were in management or similar roles and are looking to transition to being engineers. And I think these may have a similar problem to the senior engineers: they have lost the skill (or never had it) and are finding out the hard way.

[1]: https://www.joelonsoftware.com/2005/01/27/news-58/

[rhombocombus]

I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company. I spend a minuscule fraction of my time writing algorithms in my daily practice, most of my time is spent integrating disparate technologies, data wrangling, and working across teams to get the information I need to make our product. Clearly there needs to be some vetting of someone's skill, but problem solving and troubleshooting are way more valued skills in my group than the ability to write a fibonacci sequence on the whiteboard. I have had far better success asking questions around diagnostic process and troubleshooting to find talented devs than I ever did using whiteboard like tests.

[ben509]

> I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company.

It's not an analog. It's the actual skill up close. They should be explaining their thoughts as they go, and you're asking why they do A instead of B.

> I spend a minuscule fraction of my time writing algorithms in my daily practice

A good problem isn't simply an algorithm, but also tests how they break a problem down, how they compose a solution, how they think through engineering tradeoffs, and how they communicate all this to you.

Consider the difference between an artist and an amateur painter. That the artist has practiced brush strokes is not surprising, anyone can practice painting a lot. What really matters is the artist can take the image in their mind and composing it into a complete scene and then express it all that through their medium of choice.

> but problem solving and troubleshooting are way more valued skills in my group

Is that a good thing? If your group wrote better code, wouldn't they have less troubleshooting to do?

Yes, that's a tautology, but I've worked on code that was kludges on top of kludges. And while kludges can be inevitable, if they persist, it indicates the person doesn't have the mastery to see a better way to express a problem. That's a skill deficit.

When I'm analyzing someone's ability to code, I'm presenting it as a problem to solve. We solve problems by restating them in such a way that the solution falls naturally from the question.

The candidates who can do this well will put together well structured, coherent code, and my team will spend more time delivering features and less time troubleshooting.

[wuliwong]

Same. I've never had someone come in for a face-to-face interview that literally couldn't code at all. I've worked at and interviewed loads of people from small startups all the way up to a top 5 US tech giant. Still have never came across that case.

[ApolloFortyNine]

It's generally a lack of problem solving skills in my experience. The main coding question I ask is actually a short word problem (less than 4 sentences for the entire problem statement).

Without giving away the question I ask, I can tell you the solution is a for loop and an if statement. If I told them exactly what they needed to solve the problem, I'm sure most could write the code (though honestly some would have still failed). It's a question I would think could fit as one of 5 on an intro to programming class final, yet I've had candidates with 10+ years of experience fail it. I even had one such candidate argue with me over asking a coding question when his resume shows so much experience at different roles.

[pathseeker]

It happens if you don't do phone screens. People lie on their resumes.

[erik_seaberg]

This. I can't trust your résumé at all, but it does tell me what you think should be reasonable to ask.

[maehwasu]

+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them.

Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.

[aetherson]

I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search.

People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it.

It is very true that you need to qualify someone's ability to write code at all.

I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program.

There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."

[cr0sh]

The best coding challenge for a hiring process I ever had happened, of all places, when I applied for a PHP development position at Fender.

At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time...

I'm thinking - really? Something this basic...

But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc...

...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that...

Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting.

During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or...

We had one guy sit for a while, then just got up and walked out without a word.

As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer.

Interesting aside:

A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.

[pathseeker]

>then implement any kind of sort for an array, then implement depth-first-search.

How have you not grokked how useless those questions actually are when it comes to knowledge about writing software? Those are both trivia in the same category as "implement the TCP acking mechanism".

[vidarh]

Not my experience, as long as you're prepared to accept that people may need some prompting, and won't necessarily find the optimal solutions.

Someone who knows the 'trivia' may remember how to implement quicksort without actually being any good.

But someone with even a little bit of understanding and some prodding to not worry about efficiency will be able to come up with some sort of solution, even if bubblesort. If people appear truly petrified, it's easy to give them a chance by breaking down the problem and see if they can reason about it. E.g.whay if you start with a two element array? Then how about 3? How do you generalise that?

Someone with both the trivia and the smarts will give you a good solution and be able to muse about tradeoffs of different implementation methods, pivot selection and the like.

It's usually fairly simple to find out if people understand the solution they offer up and can reason about it, and that's often a lot more important than whether they come up with a great solution.

[aetherson]

Re-implementing bubble-sort is, I think, a pretty reasonable fizzbuzz-style question. Can people think in loops.

Depth first search I would now be a little less eager to do (I was asking these questions ten years ago), but there were a few things that I felt came out well from it: if someone wrote something like:

if (DFS(node.left) || DFS(node.right)) return true else return false

That seems to me like it demonstrates at the very least some immaturity of how to write professional code. If the person doesn't know how to do recursion, that stands out. If they fundamentally don't know how to deal with a stack, that stands out.

If someone has never encountered DFS and just gets fundamentally stock on what the algorithm is at all, then that's, I agree, not wildly meaningful. But that was not, in general, a reason why people didn't get the DFS question.

EDIT: I will also note that I've had a couple of people on HN react with horror at the notion that someone might be asked to impelement DFS or BFS. While I agree that these aren't perfect questions, I think they're pretty radically different than some of the puzzle-y or impossible-to-re-derive questions that you sometimes hear about. The algorithm for DFS is:

1. Check to see if the input is null. If it is, return false. 2. Check to see if the input's value is the searched operand. If it is, return true. 3. Return DFS(left) || DFS(right)

Breadth-first is a tiny bit harder, but it's still a while loop on a queue and just test equality and push the children onto the queue. It's about ten lines of code and it's far from rocket science. If nobody ever taught you about binary trees at all, you might still be a great programmer. But if you're a good programmer, and you ever got taught about binary trees (which most people who have traditional backgrounds have), then you should be able to recreate those algorithms from first principles in, I don't know, 15-30 minutes.

[maehwasu]

In my experience, the sweet spot is anything that involves recursion or pointers, preferably in combination. You get some false negatives, but not tons if you don’t disqualify non-elegant solutions.

[lowercased]

a series of easy-medium-hard to gauge where someone is at might be that 'sweet spot' - there's not one question that would cover enough, although I think fizzbuzz tries to.

[frigfog]

What do you mean by Fizzbuzz? Normal fizzbuzz or the pointless overengineering fizzbuzz?

[theWheez]

This is incredible to me. How can one get to senior or middle software engineering positions without the ability to write such trivial code?

[cr0sh]

It does seem incredible, but it happens.

One place I worked at, the company hired a developer who claimed to have a CompSci masters.

He was completely unable to code anything. I thought it strange.

I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all.

He only stuck around a couple of weeks.

I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system."

Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills.

Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.

[magduf]

I once worked in a place where they wanted to hire a few contractors to help out, and I had to help phone-interview a few. I remember one guy whose resume claimed he was an expert in C++, so I simply asked him to tell me what a "class" was in C++. He couldn't answer.

[falsedan]

shit, I'd have to look up NAND gates. also: that's EE, not CS.

[cr0sh]

There's actually two acceptable answers for the question...

I should note that my statements below may be FOC; I do not myself have a CS or EE degree, so take what I say with a modicum of salt...

But first, note that I wrote "function", not "circuit".

It could be argued that CS, on the whole, is a subset of mathematics, particularly that of boolean algebra and logic. As such, the functional equivalency between the abstract of boolean logic/algebra, and its implementation on a physical substrate, could be considered among the most important of CS concepts.

One could also argue (maybe?) that Turing's "equivalency theorem" might be related to such as well. Consider the case of an emulation of hardware done in software; one could consider that - at a base level, it is boolean logic expressed physically, being expressed equivalently as boolean software functions.

The opposite it also true, of course - that it is possible to express software boolean functionality in the equivalent physical form.

What form it physically takes does not matter (other than speed of course), which is why I also didn't ask for an implementation/representation in electrical terms or schematic form, but rather a diagram of something that could be expressed as a physical and mechanical object. If the person were so inclined, they could express it as a series of levers and marbles, or in LEGO, or Meccano, or any other similar option.

EE knowledge is not needed here, I don't believe (Martin Gardner might agree).

[falsedan]

> One could also argue (maybe?) that Turing's "equivalency theorem"

lol wat

did you talk like this to the CS masters, no wonder they left

[0x8BADF00D]

TechLead said it best IMO. If a developer cannot understand basic concepts like recursion, then they are in the wrong industry.

[vidarh]

I think some just have outdated skills and don't know how in the environments they're faced with.

Sometimes people move between senior eng. and management positions and back depending on organization sizes. I certainly have had engineering manager positions where I went several years without needing to code for my job. If I'd stayed longer and not coded for fun, and then gone on to the type of positions I did next, which were much more hands on, and using different labguages I can imagine I might have found it hard.

Thankfully I've always enjoyed programming on side projects too, so staying up to date has never felt like a chore.

[chrisseaton]

I think some people's typical coding is call one API, and then send the result to another API, or just print it out. They never need to write anything like a loop or logic.

[maehwasu]

It was incredible to me too. But it’s reality.

As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.

[erik_seaberg]

Are there a lot of senior people who don't interview? Fortunately most of my candidates have been at least marginal, but the first couple of useless ones years ago were all it took to convince me that we can't ever skip coding questions.

[b_t_s]

"The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list."

I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who was literally unable to code a trivial problem. The last time I met a "programmer" who couldn't code was first semester university, and I thought most of them quickly flunked out/changed majors. I wonder if there is something about your company/recruiting process that is particularly attractive to them, or if our prescreen(which I'm admittedly no expert on) is just particularly good at filtering them out, or if there's some other explanation.

[jamiepenney]

I've performed close to 400 screening interviews now for a range of companies. There's a good chunk of people that struggle to write a solution that correctly compiled to an "aggregate this data" style problem. People with the "correct" CV that have made it through the HR filter. It's a real problem.

[HelloNurse]

There are people who overestimate their ability. For example, I've worked with a very junior programmer (too junior for a good whiteboarding performance) who took extensive notes about everything, appeared to learn quickly, was probably convinced that he was learning, but performed poorly because he failed to think enough.

I saw him do SQL joins on the wrong column, cause accidents in source control, lose changes because he wasn't looking at the file and folder names on screen, and so on. Hard to realize for him, and hard to guess in an interview.

[drspacemonkey]

I've also been doing interviews for a few years at three different companies, and I've encountered it. It depends heavily on the quality of the recruiter. Good recruiters will attempt to filter out complete duds, bad recruiters will pack a clown car full of "rockstar candidates" that just wasted my time. There was one particularly bad instance where a guy with 10 years of experience and a masters degree got stuck for an hour trying to write a for loop. With unfettered access to Google.

[drugme]

The vast majority of applicants cannot code at all. And I mean that literally.

No, you mean that hyperbolically.

Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience.

What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all."

As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college).

Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process.

And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1]

[1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter".

And one more thing:

How, you ask? By ... dodging responsibility.

No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.

[__jal]

Sounds like you don't phone screen.

I've screened people like you describe, but the only time I've interviewed them face-to-face was when they didn't have a technical phone screen for whatever reason.

FWIW, one of the ways I screen companies when I'm looking is whiteboard problems. I refuse them and move on. In my experience, only HugeCos and places with problems use them. I'm sure that's not true, but I have a necessarily small sample-size, and skipping over firms that do it has worked well for me so far, and there are plenty of fish in the sea. (I do in fact suck at writing on whiteboards, I just don't consider it a skill worth developing to pursue jobs I probably don't want.)

[pathseeker]

You're probably using a different definition of "whiteboard problem" than is common for what is used a places like Google/Facebook/etc.

I agree with you 100% if "whiteboard problem" means, sit with them while they type up a function in an IDE that does something common (e.g. validates a string, implements some error handling, do a failure backoff, etc).

I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.

[cr0sh]

> I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.

From an interviewing perspective, asking someone to "solve" this kind of problem on a whiteboard would be interesting to see.

One thing I'd tell them is to not worry about the code; that is, if they just want to write the process in pseudocode or something like that - as long as the logic can be followed, that would be ok. In other words, give them the leeway to not worry about proper coding, knowledge of functions, etc - but instead let them concentrate on the problem.

I wouldn't expect anyone to solve such a question - but it would give a good insight into how they go about solving a problem. Do they ask questions? What happens when they get stuck? Can they explain their reasoning? And so forth.

Let them do what they can, give them 30 minutes or so; if they look lost, ask them some questions, see how they respond, etc.

I think such a question could be very valuable - if presented in the right way.

[JohnFen]

> The vast majority of applicants cannot code at all.

I've been interviewing devs for years, and this is not my experience at all. The vast majority of applicants that I've interviewed can code, although they tend to be minimally competent at it.

[wuliwong]

>Whiteboard problems absolutely do work.

>The vast majority of applicants cannot code at all.

You kinda set up a strawman here. If the purpose of the whiteboard problem was just to establish some very low baseline of coding ability then I doubt many people would argue about their effectiveness. But companies don't use whiteboard problems for that purpose. In my experience (on both sides of the table) they are given with increasing levels of difficulty to see how far the candidate can go. They do not simply ask a few basic questions like "how would you write a function that returned the sum of two numbers" or "count the number of elements in a given array."

I'm not saying there is a really good answer to this. The best I've seen is that some people just seem to be good at hiring and others are not. I am one who is not. I am also a terrible interviewee. The whole process whigs me out.

[ApolloFortyNine]

The number of people I've had fail simple questions (not binary node problems, I mean problems where the optimal solution is basically a for loop with an if statement) is absolutely insane. I would say at least 50% of applicants fail to solve the coding question, and this is interviewing for a 100k+ US job in medium sized city (so low cost of living, and good salary for the area).

We have 'hard' questions in our pool we can ask (where optimization actually comes into play) but I've found that the easy questions weed out so many candidates it's not worth it. There's no room for debate if someone tries to write 15+ if statements rather than creating a loop and one if statement.

[justfor1comment]

May be the company you hire for has a mediocre reputation. So that people with average programming skills don't mind applying. People are generally good at self sorting. At some level they must be thinking they can get this job and end up being surprised that all the rounds are not behavioral rounds.

[MentallyRetired]

My frustration is that this is the only industry I know of that makes you perform a pre-hiring test. Can you imagine if a construction worker had 1 hour to assemble a dog house as proof that he can build?

[Tade0]

There exist automated processes[0] that efficiently reject such candidates - no need to bother staff with doing the same manually.

[0] https://www.codility.com/

[danesparza]

Soo ... not sure if you read the article, but that's exactly what it was discussing.

[StavrosK]

The article is down.

[wuliwong]

It's funny, the worst engineer I ever hired did great on our Codility tests. Maybe he just cheated, he actually scored higher than myself. Just a little anecdote but we no longer use Codility at my company. :)

[algoreithm]

FTFY:

Absolutely untrue in my experience, I can't speak for other people. To imply that this is absolutely untrue in the global space would require that I have interviewed everyone.

Whiteboard problems absolutely do work in my interviews. Again, use of the word absolute indicates that I've never interviewed without a whiteboard. Given the high number of candidates I've interviewed, this might indicate a flaw in the interview process.

The vast majority of applicants I select for interviews cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. I should consider the possibility that I'm selecting the wrong people for interviews.

Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. Clearly other companies are making the same mistakes I am making in their candidate selection process.

How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.

Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.

Source: I've interviewed a great deal of poorly selected people for lots of positions over the years.