[cauterized]

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies.

I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them.

A company that needs someone to solve these sorts of problems doesn't want me on their team in the first place, nor would I thrive there. A company that just needs to build damn good web apps is losing out by using these sorts of questions in their interviews.

The best interview challenge I've had (actually, it was a take-home, with discussion in the interview proper) was about designing code for re-use and extension. It was a great indicator of the company's practical and mature approach to engineering, and of what they really wanted this hire to accomplish.

[hashkb]

> I'm a kick-ass get-things-done full-stack web engineer.

And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.

[bigtimeidiot]

>If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team

So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?

[rebootthesystem]

I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person.

Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't.

My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc.

A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough.

I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview.

I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.

[cauterized]

But I did learn the principle, back in school. I've just never needed to use it.

[swalsh]

I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on.

I have 4 books in the "The art of computer programming" series on my desk. They've been more or less decoration for several years, until I ran into a problem I couldn't google. Since I read them, I had an idea of where to start, and I used it as inspiration to craft a new solution tweaked from one of these foundational algorithms.

That said, not everyone is strong in algorithm development, and you can be a kick ass programmer without that skill. I'd only ask these questions if I needed someone with that skill on my team.

[duiker101]

In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.

[stickperson]

I tend to place engineers in one of two buckets-- those who make tools and those who use the tools. Most people fall into the latter bucket and can get by without hardcore CS knowledge.

[fencepost]

Googling for a library is all well and good, but if you can't evaluate whether it's well designed and well written then you might as well rephrase it as "Google for someone else's problems to add to my own."

The background knowledge to understand what you're looking for and looking at is really important in these cases. You mention having and having read TAOCP, that already puts you ahead of >99.99% of the people doing programming out there - 95% of whom couldn't tell you who Knuth is, what he's written, or what Drofnats refers to.

[septimus111]

I agree that these interviews are often just an annoying rite of passage, and they exclude many very talented programmers, but dismissing companies that use them as 'incompetent' seems like a stretch to me.

Learning basic data structures & algorithms is an immensely useful thing for a programmer, and completely essential in many cases. The best of these puzzles are based on problems which people have had to solve in the real world. For the companies, there are many benefits to conducting algorithms interviews:

- setting a minimum standard to make sure there is a shared language and knowledge that you can expect any engineer in company to know.

- making sure you are able to do more than trivial optimisation and go beyond the abstractions that libraries / frameworks provide

- giving you a simple problem to solve in 30 minutes to see if you can program at all.

[jacquesm]

It's just laziness incarnate. This pushes all the investment of the first phase of interviewing someone onto an automated process and denies the candidate the opportunity to vet the company which is just as important as the reverse.

Well, actually they do allow the candidate to vet the company: the message they send is we don't care about you at all until you do a bunch of busywork and if you're very lucky we might allow a human to spend some cycles on reviewing your results.

If as a company that is the kind of message you would want your prospective employees to have that's fine with me but it would be good to remember that interviewing a candidate is a two way street.

[gpderetta]

I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday.

Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

[rpedroso]

I primarily write python web-based APIs for a web application + 2 mobile apps. Just the other day, I was dealing with an endpoint that had to update hierarchical data (i.e. a collection of trees).

Due to the circumstances, normalization wasn't an efficient option. I ended up throwing together a barebones tree with a 5-line DFS implementation to traverse it. It handled inserts, updates and deletions (for my use-case) in linear time.

The details aren't so important as the fact that adding a dependency would have been overkill for my needs. This isn't to say that efficient graph implementation libraries should not exist or be used, but I was able to produce this code faster by having that basic CS knowledge.

[quantumhobbit]

Where does one get a job writing actual algorithms and data structures? I actually enjoy that and am pretty good at it. I'm sick of jobs that are nothing but glueing together poorly documented and tested libraries.

[duiker101]

This is very true, but I don't think that anyone interviewing for a position like yours will reference to this list of things to test their candidates.

[southphillyman]

Honestly, is it unreasonable to require that people brush up on this stuff every couple of years? In my experience the majority of companies just want you to be able to do fizz buzz level whiteboarding and intelligently speak to your experience. I feel like we all know in advance which companies typically require a month long review of algorithms before the interview. IF you want to work for one of them then do what you need to do to get the job there. We all agree it's annoying but I really don't think it's as big a deal as people make it out to be.

[FLUX-YOU]

You can conceivably move up to management, never have to deal with algorithm hazing again, and make more than the guy that has to refresh every few years.

The rewards just do not add up for this to remain an industry practice.

[sidlls]

> I see these challenges as a great way for excellent experienced developers to weed out incompetent companies.

This is far too broad. There are plenty of jobs in certain companies where a good understanding of the theory and practice encapsulated by these challenges is the bare-minimum requirement for doing well. Companies that leverage coding challenges like these for these positions aren't incompetent (at least, not for that reason). Just because your work doesn't require this depth of understanding of CS doesn't mean there is no such work.

I'm skeptical, however, that the number of such jobs is very large, even in the "usual suspects" companies (Google, Amazon, etc.). Most jobs, even in these places, one can get by with the most rudimentary ability to understand what 'greater than' and 'lesser than' means and a chart describing time/space complexities of various structures and algorithms in a library.

[andrepd]

It's not about actually having to implement these algorithms in your practical, day-to-day work. It's a challenge to test your reasoning and problem-solving ability in abstract, that you can administer in 15 minutes. You can't really test a candidate with real-world workloads, can you.

[wpietri]

You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though.

I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.

[hack_edu]

> You can't really test a candidate with real-world workloads, can you.

But you can test a candidate with imaginary non-workloads?

[gizmodo59]

"reasoning and problem-solving ability in abstract"

Implementing a syntactically correct tic tac toe program on a whiteboard doesn't fit it. Plus many are comfortable in working behind the screen than to work in front of white board (real world)

[collyw]

Why not ask me to bring in some work I have and discuss it?

[dahart]

Most programmers on the market don't have a lot of experience, due to the programmer population increasing in size quickly over the last decades. (https://en.m.wikipedia.org/wiki/Population_pyramid)

So one big question all companies have is how to interview for programming positions by kids fresh out of school or who've had a job for at most a couple of years.

This is less a question of competence and more a reflection of the age structure of the market for programmers. You will be working with people younger and less experienced than you. You will probably be hiring people younger than you -- how will you interview them?

As someone with a couple decades professional experience, I see these challenges as one of many ways for competent companies to attempt to find competent programmers despite a lack of experience by the interviewee.

The last company I interviewed for gave me coding challenges, but that's not all they asked, I got plenty of questions that allowed my experience to shine. If you only got coding challenges as an experienced developer, then yes, that would be a reason to avoid that company.

On the flip side, my willingness to take the coding challenges in my interview allowed me to highlight my practical experience, because I crushed them with little preparation. Other experienced devs who refused the coding challenges or dragged their feet and complained about them lost the opportunity to receive an offer.

[JustSomeNobody]

That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.

[NTDF9]

>> That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.

Dude, in EE interviews, we just ask them some basic about capacitor and how to use it. We don't ask them to derive the mathematical equations of electrolytic capacitors.

In fact, in most EE interviews, you just use them to solve ONE problem and be done. Nobody questions you know EE stuff once you've solved ONE problem.

In programming interviews, you have to solve MANY problems and interviewers just want to keep finding ways of docking points.

[thearn4]

Sadly, that describes more than a few EEs and MEs that I've worked with in the past. Where the act of turning a key in a commercial software package starts to displace practical design considerations that they learned in the classroom.

[enraged_camel]

You don't need to be able to build a capacitor from scratch in order to understand how they work. Furthermore, electrical engineers don't have to build capacitors from scratch during job interviews to prove their competence.

[Dolores12]

> I've never had to deal with one of these sorts of problems in my day to day work;

You are from different niche and actually you are being paid less than those guys who knows the stuff you don't

From [0]:

"[S]killed cloud and backend developers, as well as those who work in emerging technologies including Internet of Things, machine learning and augmented/virtual reality can make more money than frontend web and mobile developers whose skills have become more commoditized..."

[0] https://www.linux.com/news/developer-nation/2017/3/visionmob...

[partycoder]

A completely delusional comment, devoid of any roots in reality whatsoever, and an insult to the decency and dignity of software engineering, as well as an invitation to strip software engineering of the respect and compensation it deserves.

A 13 year old making a website for his dog in PHP can fit your definition of full stack web engineer.

The underlying parts of this "full" stack require significant domain knowledge around algorithms, data structures, computer architectures, operating systems, distributed systems, networking and communications, programming languages, etc... and most importantly, critical thinking and engineering rigor beyond trial and error and cargo cult copy-pasting from stackoverflow into your "get-things-done" duct-taped spaghetti code base.

Those underlying parts created by the people that you now call "incompetent" are required to design, implement and maintain the "kick-ass" babyproofed playground you live in and that allows you to put food on your table. Have some respect.

If you are so kick-ass and get-things-done, checkout the source code for Linux, Chromium, v8, node or libuv, Python, Ruby or whatever technology you use and try to get something done there to a level of quality in which it gets accepted and see what happens. You and your kick-ass denomination will be stomped over and brought back to reality.

[ramblenode]

The problem with your reasoning is that you expect the interview to mirror job requirements rather than select for job performance. In many cases the best instrument to measure the latter will resemble the former, but there's nothing intrinsic about the relationship. If giving someone a brain teaser or having them recite trivia provides a strong signal for job performance, then it makes sense to use these instruments. You could argue that they don't provide a meaningful signal (which I think Google may have discovered with the brain teasers), but that is a separate discussion.

Something else to consider is that the interview is optimized to select for true positives and reject false positives at different rates. It's been discussed elsewhere that for a company like Google avoiding false positives is much more important than finding good candidates. So it may be the case that some instruments like trivia recitation provide the right signal at the intersection of the optimization curves. The fact that many (even most) qualified candidates score poorly on these instruments doesn't impugn their utility; their primary goal isn't to identify good candidates but to filter out bad ones.

[azaydak]

I suffer greatly in coding interview questions. I'm not a kick-ass full-stack engineer but rather a research engineer. I code every day but usually it is proof-of-concept demonstrations so I lack formal education / guidance of many professional coders. I'll knock a take home assignment out of the park but I do envy people who are great coders.

[charles-salvia]

To me this sounds like you just develop dependency-laden bloatware, i.e. you'll throw in some 5 gigabyte Javascript library just to do one thing.

[humanrebar]

I agree 95%. However, inevitably there will be a developer that will want to implement a trie for reasons. It's hard to be able to reason with her (or technical leadership when appealing the decision) when advocating for an off the shelf alternative if you can't explain why this isn't a brand new problem. On the flip side, one actually does need to create a new data structure on occasion, and obviously there we would want to be able to implement the common alternatives.

Anyway, it's complicated. Especially when hiring for technical leadership.

[vonmoltke]

If I need to convince another developer that a particular path is well-worn and that they are drifting towards NIH syndrome I have the benefit of time to develop an argument and resources with which to do so. I do not have 45 minutes, no resources, and just a whiteboard.

To pre-counter an expected objection, if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.