My frustration isn't exactly like yours (my time is probably a lot less valuable). I feel that the questions are all geared at puzzle solvers.

If you're a puzzle solver, you love answers. You love digging into the details. You love finding out the basic components of a system. I think these are the people who excel in academics.

Almost every other intern I met once I got to the bay area was a puzzle solver. They were also competitive and had amazing grades. And these people LOVED algo questions. Over lunch, they could go through half a dozen questions.

I slipped through the cracks I guess. I'm bored by puzzles, have awful grades (and in a worse program), and not so competitive. What I do enjoy, however, is building up. I like modeling and being about to think at greater and greater levels of abstraction to solve problems that aren't puzzles, but instead open ended questions.

Anyway, I think both of these types of people have a place is software, and only one is given attention

In their eyes, they have given you a problem involving a tree from the graph theory and you are insisting on an "out of the box" solution involving woodpeckers.

Let me elaborate.

Usually hypothetical situation is just a way to talk about an abstract problem.

It's easier to visualize and to talk about an egg falling and breaking (or not) than abstract measurements.

Now what you call 'thinking outside the box' is just attacking the irrelevant details of an imaginary situation which is there purely for convinience and can be replaced with another hypothetical situation corresponding to the same abstract problem.

It's actually supposed to be mutual judgement. But I agree: be respectful if you decide to drop a remark about the relevance of the question. There are enough reasons to treat people with respect even if you can afford to turn them down.

Agreed, I was being sarcastic.

The people in Creative Lab were impressed with the ride range of knowledge I had, the SRE guys who rejected me got stuck into me for mixing up some VMware terminology.

In my opinion, you will do well if you focus on building your own business sooner or later.

It goes something like: "Hey, new Engineer, I need you to work on experimental feature X". - Then the engineer builds system Y to provide feature X, probably poorly architected and not scalable, not expecting it to go anywhere. Some months later, app containing feature X gets distributed to thousands of users, or goes viral and hits millions of users.

Congratulations, like it or not, you have now become the lead architect of the now-widely-deployed "experimental" system Y, and you are going to either crash and burn or become a damn good software architect by maintaining it out of sheer necessity. Later, you find yourself putting "Lead Software Designer" on your resume, having earned that role and title.

A lot of successful software was originally designed "by mistake" and grows far, far greater than its original purpose. And in contrast, you get the well-designed software that was properly architected, but never goes anywhere because it never saw the light of a successful deployment at scale.

Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.

Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.

I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.

1) Gathering requirements.

2) Turning those requirements into data structures.

I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way.

When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different).

Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up.

I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.

It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.

In my experience, algorithm interviews aren't even very good at measuring aptitude for algorithms. Recent study and aptitude for the format have too much influence. Asking candidates about architecture has been much better at predicting their aptitude for architecture.

If you can rigorously ask architecture questions, and don't let people get away with hand-waving, that sounds fine. I've been asked good architecture questions and I've been badly asked bad architecture questions too, so... it depends on the question, and how you ask.

As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture.

Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept.

Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all.

It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems.

Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it.

I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking.

(And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuh... )

I really needed to hear this thanks.

Web servers and clients, for example, are a case where I've seen bad architecting cause months of damage. An Emacs function hook or advice system, likewise, requires care in terms of when the hook is called, and what the rules for their scoping are. It's a bad software architect that thinks they can just slap callbacks on something.

I'm no expert but I know a logistics company that has the 30 workers 1 puzzle guy setup. He maybe writes 20 lines of code a week but its on stuff other people cant figure out. However if he was the only type there literally nothing would ever get done.

I've been out of college more than 10 years now, do a mix of hardware and software (so am not coding all day everyday) and I can hack together algorithms like BFS if I spend a couple of minutes thinking about it.

I get that there are many awful interviewers out there and that hiring is pretty broken, but BFS seems like a pretty reasonable interview question, so long as the interviewer talks through what it actually needs to do and isn't only looking for a memorized answer. The question is well contained, doesn't require the candidate to know any specific API or framework, and can be implemented in pretty much any language. Probably the biggest downside to it is it's such a common question that many candidates study it ahead of time which makes it a worse filter.

Rather than memorizing a thousand algorithms, I generally focus on being able to solve problems simply, quickly, and elegantly, which will help in actually doing most jobs.

I've heard people actually defend these useless interviews on correlation grounds, like people who are docile, follow the herd, and "prepare" are good hard-working workers who also tend to have done well in school or look polished in other aspects of life. That's what these interviews are really looking for. So, if you're not a well known expert, suck it up, be a servile cog and follow the script.

The trick seems to be knowing when the game is worth playing. There are certainly situations where competition is too fierce and requires too much preparation, so it's not worth doing if you don't really enjoy the game.

I'm not sure getting hired at a large tech firm is quite that competitive, though? They do hire lots of people all the time.

Of course, I could probably come up with a way to do it by myself. I could probably even come up with an efficient way if I spent an afternoon/day on it.

But why do that when I can google it, and get 3 blog posts and 2 stack overflow answers detailing the different options and the trade offs between them, most likely even with an implementation I can base mine off of?

That's why these interview situations are stupid. They're like school where copying is cheating, whereas in real-world situations copying is a great way of doing something.

A lot of resources out there are wrong, inaccurate, or not reasonable for your particular context, and it requires a reasonable amount of algorithmic intelligence to be able to sniff out what's appropriate.

If I had a dollar for every high-upvoted SO post that misstates a problem or doesn't offer proper caveats... but I can make that judgment because I've already thought about a related problem in the past.

It's like asking why one should learn how to write properly when Grammarly and spell checkers exist, or why mental arithmetic is useful when we have calculators—at some point those your tools will be inappropriate or unavailable. Search tools are force multipliers, not replacements for personal knowledge and intuition.

Right, and having that algorithmic intelligence is key part of me being a good developer. But testing how someone implements an algorithm in time-scarce circumstances is not a good test of that kind of intelligence because it is likely to favour people who have been exposed to that particular algorithm before (even if they only rote-learnt information about it - as many interviewees seem to do in practice) over people who have the capability to think deeply and reason correctly about it, but have not previously been exposed to that problem.

BFS is not something I thought about much in the last 5 years, and quite frankly could care less about. I got stuck when I knew I needed 'something' to finish implementing BFS, but couldn't remember and the google interviewer offered no help. What I couldn't remember was the queue.

THIS is the problem. The (unreasonably) timed nature of the exercise means that the only people that will do well are the people that prep heavily for this specific skill, in much the same way that people about to take the LSAT are likely to do better than it than actual fucking lawyers with proven experience.

Because which law school they went to is on their resumé and the average LSAT scores for each school are trivially available, tracking very, very closely with school prestige.

a lot of great data scientists dont even know how to use python, let alone implement a tree and tree traversal. there is so much more interesting and pertinent stuff I spend my cycles on learning / keeping in my head than undergrad cs bs.

But, if you explain what it is in words, and have them whiteboard how to turn those words into pseudocode or somesuch, then it could be a appropriate, sure.

Who could really solve these problems, error free, on the spot with no prior exposure to underlying concepts?!?

That doesn't mean all "implement X algorithm questions" are categorically bad.

But put them in a room and say "Make us a 2 layer red velvet cake" with no access to a recipe, and you're not going to get a red velvet cake. It's an easy recipe that most people easily recognize with just a glance, and anyone could make it if they have a recipe on-hand or make red velvet cakes with abnormally high regularity. But most people, even if they're great chefs otherwise, will fail.

Recognizing that a concept exists and implementing a relatively complex concept are different things.

To know how to make a novel cake (not a recipe you've memorized), you need to have a good understanding of how the different ingredients interact. You probably even have a good sense of why they're there.

Those seem like exactly the qualities you'd want to look for in a cake maker. Sure, they'll probably be going from recipes in their day to day job. But they'll be able to tweak them intelligently too.

But most restaurants are looking for someone who knows how to cook and use the tools in the kitchen. A chef who doesn't specialize in cakes will still probably be fine if you give them 5 minutes to look up a recipe and make one. In the same way, the overwhelming majority of tech job openings are in need of programmers with some degree of specialization and the ability to know how to look up what they don't know and the experience/knowledge to know how to put that info to use.

The state of programming interviews for the past few decades has been to find people who've memorized all the "recipes" of CS. Most of the jobs, though, are about using some Javascript flavor of the month library and making it work with some other popular library and writing a bunch of interface code. Someone on the team might have to write an implementation of breadth-first search in their toy language, in which case they look up "bfs" on wikipedia and just rewrite the algo given.

Companies are testing employees on how to make cakes when their job will be all about making burgers to order.

I'm dubious of this claim. Google/Alphabet has a PPE of ~$150,000. Activision-Blizzard has a PPE of ~$33,000, EA had ~$95,000, and Ubisoft ~$15000. I think the only possible major game studios who could meet your claim are Epic or maybe Valve. Unfortunately, those numbers aren't public. So I'm going to assume you work on Steam, since Epic's new platform is likely too recent to have lots of users, and also I don't think it was competently designed.

(the other thing is that this metric isn't particularly meaningful. Google invests a huge amount in unprofitable things with the goal of profits 5 or 10 years down the line. Google devotes thousands of engineers and billions of dollars to things it knows aren't profitable. That doesn't make Google more or less competent, it just implies different priorities than one that's entirely driven by immediate returns).

>Based on my experience (currently responsible for a huge chunk of a major gaming platform, with hundreds millions users), inflexibility, emotional immaturity, inability to think outside of the box, inability to listen and admit failures, lack of emphaty, not understanding basics of sales(to sell own ideas) are major things that contribute to a bad performance reviews.

All of these are important, but they only become important once you have the baseline level of competence. If you have two equally competent people, then yes indeed the softer skills like flexibility, creativity, humility, and communication skills start to matter, and eventually they matter a lot. But those are only good things if you assume a baseline level of competence.

Consider two options. One is that you screen solely for competence. You get only competent engineers along a wide range of interpersonal/soft skills. Some can grow into leadership roles, some can't (or at least it takes longer). But even the most convincing, best "salesperson" has great engineering talent. Then the alternative: that great salesperson is a bad engineer. The ideas they promote aren't always good ones, sometimes they're bad. That's not just "not good", its actively harmful.

>Our strongest engineers will not pass google interview without preparation (me included) and it is telling.

What does it tell? You seem to be suggesting that Google is optimizing badly, and that's possible. But that is by no means the only conclusion. Here's an alternative: "The most profitable things are not always the most technically challenging". Every once in a while you'll see people on HN commenting about how they wired up a shopify store that provides some significant passive income. That's not challenging. It would take an average engineer a week to do, if that. It's still profitable. But that doesn't make you qualified to work at Google (or Valve).

But, as with a concept like 0, making the cognitive leap to understanding that there should be a way to represent the lack of something is counterintuitive (indeed, consider Tony Hoare's billion dollar mistake. The "right" way to represent the absence of an object is a hard problem). However, once you've been exposed to it, it's not particularly challenging to rederive the necessary pieces.

So yes, complaining about BFS is, imo, akin to complaining about being asked what the result of the arithmetic operation `35 - 12 - 23` is.

I'm not asked to implement BFS every day, but the concept of a tree traversal is incredibly common.

Even more explicitly, a lot of my recent work has been involving automated refactoring tooling, so there's lots of work with abstract syntax trees and control flow graphs, which are trees or graphs, and therefore need be traversed.

Yes I can probably implement a sufficiently fast maze solving algorithm, depending on exactly the environmental constraints (for ezple, given the problem as stated I'd assume something like a* using a precomputed mat heuristic would be fast for most mazes of reasonable size, I promise either didn't google that).

But I wouldn't expect someone to answer that in an interview. Hell, I don't ask dynamic programming questions because I think they're too obscure and tricky (in the riddle way). My most common interview question involves a problem I've faced multiple times at work, has multiple valid solutions, and which I had to implement myself in various flavors before eventually coming across a relatively obscure standard library implemention.

Although before I was able to identify that implementation, I had to solve the problem 2 or 3 times, see the different flavors, and identify the common themes and the theoretical underpinnings.

I don't expect a candidate to do that without help, and most don't. But it sure sounds like you think that I'm somehow a bad engineer for asking a question that tests on the job skills I've needed, and the ability to break a problem down into component parts and implement them cleanly.

But oh no, it uses an algorithm. It's a terrible question and I should just ask a question about software engineering that doesn't use any algorithms. Because obviously people will always be able to identify the standard library implemention (no candidate I've interviewed ever has, in fact). So colore dubious of this whole argument about whiteboarding questions being a bad test.

Consider that BFS was first published in 1945, while the turing machine was published almost 10 years prior. Is BFS an implicitly more complex concept than a turing machine? That seems like a strange argument to make, but I'm certainly interested.

> was I wrong then? Or am I wrong now? Perhaps both.

Neither, I think. The Algorithm interviews are bad for 90% of the positions out there, and experience matters much more than trivia, so you were right then.

And today, everyone is trying to hire "senior" (and above), so there's no concept of "will learn, lacks experience" - and the algorthm questions do badly at identify THAT, so you're right today too.

It turns out that interviewing is hard, and we don't know what works well. Most of us think "we" are the ones that can obviously see what's wrong and everyone else is interviewing poorly. Most of us are wrong.

But even besides that, we need to focus more on getting newer coders that DON'T have experience. We'll spend years looking for people that have experience...longer than it would take to grow that experience. We want seniors because we want people that will grow without being mentored, because we have far more work than people...but we skip one of the ways to reduce that workload.

I'd much rather have an interview that was teaching something new, and see how the person processed it. That's not a good interview either, but at least it is trying accomplish the correct goal.

And when we do interview for senior and above, experience will count a lot more than building a frickin' linked list.

Cowen’s Second Law: There is a literature on everything. Hiring is no different. Why do so many of us that say “of course you shouldn’t reimplement timsort, stand on the shoulder of giants” either make up an interview process based on gut feeling or cargo cult one based on what we heard google does?

So no matter if you've read the literature and implemented a process, there is something wrong with it.

That's why there threads persist. Every process has something wrong with it depending on who you are. Funnily enough everyone eventually manages to sort themselves into the right category.

The system isn't broken any more than armed conflict is broken as a way of settling disputes. It's works, it's just a little terrifying and awful.

Personally, I'd rather not work somewhere that hired based on drilling fringe information - what will the job be like? Maybe I'll feel differently in 10 or 20 years

I would hope so, because I do all those things and, after over a decade writing software, find the ability to solve puzzles almost completely useless for most coding I've ever done. But reality doesn't need to make sense. So, if you want to work for Google or Facebook, learn puzzles anyway :)

That may not be necessarily a bad thing, depending on the position of course. But projects are not the be all end all, at least not in my company, and where I interviewed.

1. The first interview must not be a technical assessment — identify shared interests, look for collaboration opportunities. You need to understand if the person in front of you will be someone you would work with for the next 10 years, their current technical skills have little to do with this.

2. At the end of the first interview, right before the logistic questions, assess how they position in the junior-senior axis — either with direct questions or by pushing them to the topic. Once you‘ve done that ask an evil surgically difficult question — the correctness of the answer is not what you‘re looking for: pay attention to how they present their (eventual) missing knowledge, or how the address the answer by giving context. A senior developer doesn’t know everything, but must know enough to manage gaps in their knowledge.

3. Search for young and talented people — search for the fire in their eyes. You want someone which, eventually, will reach goals by their own.

That said, I do like the interviewing approach we're replying to, other than that "y" word... :-)

Did you know that it is perfectly legal to discriminate against young people?

Yeah sucks to be them, I guess. Apparently nobody cares about discrimination against those people.

Old people are among the richest people in the world. But I guess when things are made fair, and neither young or old people are discriminated against, that appears like "discrimination" against those who are now being treated fairly.

Even though I'm sure there is a lot of variance between interviewers, I can't help but think that the abusive style of whiteboard grilling must "work" in that it results in able workforce, and that might be because of the reason I suggested.

I know this is off-topic, but you can't go wrong with Keras. "Deep Learning with Python" by Francois Chollet (the creator of Keras) is a Kernighan-level book. A book like this comes around once a decade (or two). If you decide to go for it though, make sure you don't follow its instructions about the amazon cloud deep learning VM's; you'll end up paying $10 per day, even if you stop the VM.

What would you recommend as the alternative for someone without nvidia gpu? Google colab?

[1] https://www.fast.ai/2019/01/24/course-v3/ [2] https://course.fast.ai/start_gcp.html#budget-compute

Thank you.

Some analogies make sense, some probably don't map well.

Google prefers to hire Devs with strong CS foundations because they assume these Devs can contribute in many areas.

If they were only to hire someone based off something that they've done before and excel only in that area, they'd be like other companies who only hire selectively based on specific skill-set (e.g.: Java Dev, or 3D/game devs).

https://en.wikipedia.org/wiki/NFL_Scouting_Combine

Me, I tell them in the first phone screen, "I'm a Systems/DevOps guy, I don't do algorithms and whatnot so I'm just letting you know in advance in case you ask me to whiteboard something like that." So far I was only spurned once out of half a dozen screens employing this statement.

If you want to screen liars, there are a million ways to do it. Truth is, folks, most interviewers don't read resumes in depth, and they're not clever enough to interview for honesty.

But I might try to do some algorithm type interview, but wouldn’t feel bad if I bombed it. In fact, the only algorithm type interview I have done in the last 10 years, they made me an offer but I declined it for another job that asked more architectural questions.

The way I see it, if I could write 65C02 and x86 assembly language programs in the 80s, I think I can handle the needs of your software as a service CRUD app.

Usually, I'm just looking for one thing the candidate does well. There's really not much room for lying and if they claim to have some crucial skill and then I discover after the fact that they don't, that's grounds for dismissal.

Everybody here seems to assume they are trying to filter for the good candidates...but what they are actually trying to do with these kind of interviews is filter out the bad ones!

Because the damage when hiring a bad candidate is much higher than the damage from missing out on a good one!

I get that this is the conventional wisdom in a subset of this industry, but in my experience this "truth" does not have as much objective support as the people who keep repeating it think it does.

In companies where opportunity cost and hidden losses are nobody's responsibility, this sort of mediocrity is well accepted.

The answers to both sets of questions are very situational, yet some people treat them as if they have universal answers.

Less than the cost of being perpetually afraid of being fired.

If an engineer on my team got fired, no matter how much they deserved it, I'd probably start looking for a new job or team immediately.

The fear of being let go isnt something I'd ever want to deal with.

Of course it sucks for the individual...but such is life

The top companies with these leetcode tests probably don't care that good people being rejected or avoiding them because of the amount of preparation required. Middle sized companies and startups doing leetcode tests are missing good people and probably can't afford the same number of false negatives as someone like Google with an endless supply of candidates.

I would much rather spend a weekend doing a take home test and showing how I actually work than being asked to write irrelevant code on a whiteboard. I think leetcode style interviewing is driven by time constraints of the interviewer and some more effort and thought needs to be put in on how to choose people based on the specifics of the actual role they are hiring for.

I think the counterargument might be that at our age, you should have a network of people who will hire you just based on your stellar performance on previous jobs, if you're that experienced and sophisticated.

If you somehow don't, well, maybe you need to brush up on your tree balancing skills...

This is exceedingly rare... so you wrote a HashMap implementation in Java?? None of the custom maps discussed [here](http://java-performance.info/hashmap-overview-jdk-fastutil-g...) were enough? It must be a really rare problem you're working on if there's no library that provides an acceptable solution for it in Java.

> I would rather work with someone who knows how neural networks really work rather than who knows pytorch or keras

I would rather work with someone who knows general programming (which is not the same as algorithms - there's so much more to it!) and software design... but if working on a product that uses a framework heavily, good knowledge of that framework can be the difference between getting things done in minutes VS weeks (of painful and time-consuming battling with the framework to do thing the way you think they should be done, rather than how it's done within the framework).

More mundanely, when I was starting out at a small shop (I'm around your age) my coworkers hadn't mastered undergrad algorithms, and it made a significant difference in what we could do.

It's unfortunate that attempting to test for this seems to have encouraged too much memorizing of known tricks relative to better mastery of principles.

But how do you approach them? What prompted my comment was all the times people comment online about "memorizing algorithms" to prepare for interviews -- learning about algorithms will include a lot of them sticking in memory, yes, but approaching it as cramming a textbook into memory the way students cram for a final exam seems... disappointing.

That's so right. But that is experience, so I think when you know most the candidates don't have it, you end up looking for other stuff to test, and then your interview process gets infected, and eventually when you are interviewing for positions that should have experience, you get a lot of the same bullshit questions.

There are plenty of stories here of novice programmers doing some passion project, and 6-12 months after learning to program they are busting out some fairly complex algorithms that to someone that took the long route of getting a CS degree can look somewhat amazing, and frankly, humbling. But I think what's going on is that's the easy stuff to get a hold of, because all it takes is some judicious googling, or more likely, asking some professionals from help, and you're pointed in the right direction for the tool that solves your need, so you use it. Getting amazing progress on a new project isn't really hard.

Getting sustained progress, or being able to fix your problem a year or two in once you realize a major architectural change is required, and not being bogged down for months and losing interest, those are amazing, and those take experience or constant mentoring to achieve usually.

Or maybe I'm just projecting what I currently value.

This then becomes representative of your experience in spite of that fact that you are never likely to be confronted with that kind of problem with that kind of timeframe. Whatever's on your CV, and whatever you can say about what you've learned over the years, becomes totally irrelevant in the face of that.

I think it's offensive and I don't like how the industry has standardised on basically assuming everyone's a bullshitter. What's worse is that you'll have to repeat this over and over again for any company you interview with.

To that extent I'd much rather see the formation of a professional body that offers a trustworthy credential, potentially one that you need to renew every couple of years to ensure you're still current. That comes with challenges of its own but I'd rather have something that is both verifiable and can be reused.

Don't think this is true. At most tech interviews, the algorithms portion is more of a technical bar. It's usually the CV, years of relevant experience, and performance on the architecture/system design interview that determines what leveling you are.

>To that extent I'd much rather see the formation of a professional body that offers a trustworthy credential

Every company values different things from their candidates, so I don't think a formal interview process will ever go away. That said, there are companies like Triplebyte that try and standardize the interview process - they usually don't ask algorithm questions either. It's not quite a certification, but they'll fast-forward you through the interview process at companies that use them.

I completely disagree with you, because how do you define rare. In my case as a JavaScript developer many cases commonly considered rare are in fact exceedingly common and important, but considered rare due to tooling and people hiding from them. When the reality is invented here syndrome every problem is either a configuration or rare. I make it an important point to attempt to discover this distinction when I am interviewing for a new position or interviewing new candidates.

I have often seen weak developers promoted to senior because they are good with tools, trends, and configurations only to struggle in the face of an original problem. You can't simply hope to download your way out of every development problem and hope to be taken seriously as a senior. That reality is something many people are unwilling to accept at great emotional peril.

https://en.wikipedia.org/wiki/Invented_here

In the UK I've interviewed at dozens of companies and never once been asked to code a breadth first search or something like that. Nor have I ever heard of a developer being asked to solve such things in interviews over here.

Also a company hiring a mid-level developer (say around 3 years experience) doesn't really have that much of a pool to chose from. Most good developers are already in jobs and pickings are slim, its a buyers market.

The few times that I've been asked very specific technical questions they have always been related to the job I was applying for. Example: a ruby on rails job interview I was shown a few ActiveRecord models and asked what is wrong with them and how I would improve them - the answer was that they were all really polymorphic models but that was not how they were implemented in the code. Or for a frontend role, they might ask you "explain the javascript prototype chain to me".

Again, in my experience, its always seemed like the interview was more of a personal test rather than a technical one. Will the person be easy to work with? Will they be communicative or will they bottle up their issues and resent the team for it. Are they willing to learn? Will they be able to hande occasional pressure and stress? I think its generally accepted that its extremely difficult to accurately gauge a person's technical abilities in an interview. Also employees always start on a probationary contract in which they can be fired with 1-2 weeks notice, this usually lasts between 3-6 months, so if it turns out the employee was blagging it in the interview then it will become apparent pretty quickly and they will likely not make it past the probation period.

Are "real code-related things" really much more important if it only takes hours and hours to learn something that might get you an offer at one of these companies?

Perhaps those hours and hours are actually far more valuable 'financially' speaking than a lifetime of studying code that is valuable 'technically' speaking. I don't doubt that some of the big name companies use rarely-used algorithms with battle-tested solutions on purpose JUST to see if you prepared for battle. They look for non-technical smarts because they have no shortage of technically prodigious applicants.

At Google, with over 400 applicants for every position, they have no shortage of technically-competent engineers. They look for people who think way outside the box and try new things, sometimes resulting in industry defining inventiveness. It's ~10 times harder to get hired at Google than get into Harvard.

https://www.forbes.com/sites/stanphelps/2014/08/05/cracking-...

You basically "build" a linkedin profile that comes up when recruiters search for technically hot things, and then they will come knocking

An alias for so-called 'algorithms' is 'imperative style' for 'functional programming style', or 'procedural programming' for 'object-oriented programming'.

They are too arcane to read, hard to modify and error-prone. Most of them require mutable data structures, intermediate snapshot for a special optimization purpose, make everything much harder to reuse.

It mostly requires you to instruct every piece of code, every step of execution. Instead of just describing what you need, and let the code find a way to fulfill it autonomously, in a declarative manner like Haskell or Prolog.

And 99% of software companies do not really have the need of requiring their employees having a deep grasp of algorithms, while most of them need their code somehow more maintainable. Those of the Leetcode oriented interviews are just really bad.

Personally, I believe business sense and culture stuff are very important. As for skill part, a lot of concepts could be more useful than algorithms like understanding of domain and relation modeling, immutable data structures, lazy evaluation, reactive design etc.

Not all of them are bad though; I had an interview that had me implement a basic data structure in accordance to the specifications given. It didn’t require memorization, practice, or any “Leetcode grinding” — only fundamentals in communication and programming. The time I had was about an hour so this is definitely a plausible substitute.

> Much more important is to have the experience of how code complexity accumulates, and how to mitigate that

That's part of the reason. The average developer knows how to pick a popular library and throw code at it until it works. When entire teams do that you end up with endless complexity.

That's why Google and Amazon are known for [re]inventing their own solutions.

Granted that you only need a vague idea about the algorithm. But going from a vague idea to working code is also a valuable skill.