16 ms·

When I was a new college grad, I felt trapped by the fact that everywhere I looked they wanted several years of experience, and I had none yet. How can I get e

When I was a new college grad, I felt trapped by the fact that everywhere I looked they wanted several years of experience, and I had none yet. How can I get experience if it's required to get the job? Now that I am 51, I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code, you should use the established, battle-tested solution that is out there on the internet if you spend 60 seconds looking for it. Much more important is to have the experience of how code complexity accumulates, and how to mitigate that. I cannot spend hours and hours studying up on these algorithms, there are much more important things (real coding-related things) which I need to learn about, to the extent I have time to do that. What should I choose, pytorch or keras? React or Vue? Go? Kubernetes? Spark? All much more important questions than how to do a breadth-first search. So, was I wrong then? Or am I wrong now? Perhaps both.

ergothus 8y ago
I share both of your concerns (while I was very lucky in getting initial experience, I know of other beginners that haven't/arent, so I'm very sympathetic.) . Started coding for work in '95. > 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.
- lowdest 8y ago
  As I see it, the difficult algorithm interviews screen for people who are motivated enough to spend 100s of hours studying for an interview, or know this stuff for some other uncommon reason. Both types are acceptable hires.
  - jammygit 8y ago
    Wouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? 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
    - brabel 8y ago
      > Wouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? 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 :)
      - BossingAround 8y ago
        I really think it depends on the quality of the project. If I'm looking at a candidate, and see 3 projects, each pushed in one commit, each project has 3 classes in one package, and I see pushed compiled classes as well as source classes, that's a clear sign that this person doesn't know what he or she's doing. 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.
    - BossingAround 8y ago
      It's interesting to me how many people value personal projects. From my personal experience, a confusing Github account with a number of small, questionable projects pushed in one commit half a year ago hurts you more than helps you. Personal projects are fine, but I think many people have the mentality of "getting a TODO app in Angular will help me waay more than implementing algorithms in C, that's useless!" which may not necessarily be true.
option 8y ago
There are career stages. For candidates just out of school or with little experience asking algorithmic questions totally makes sense. For more senior candidates (who actually progressed to the next stage, not just spent a lot of years), the questions become more real-life, more open ended and with more than one (or sometimes none) “correct” answer
jacquesm 8y ago
Algorithm interviews are good for people that will be writing algorithms. Most of us are just plumbers, even so a solid knowledge about what algorithms are available and what their strengths and weaknesses are is as important as good knowledge about the tools is to plumbers.
cornellwright 8y ago
Is BFS really that hard, especially if the interviewer is willing to talk it out with you and doesn't care a lot about finding the most efficient solution possible? 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.
- spyspy 8y ago
  You and a lot of other commenters are getting hung up on the BFS example. It's just that - an example. There are dozens of algorithms that are "common" enough to be asked about and diminishing returns to having them all memorized.
  - cornellwright 8y ago
    Sure, but that's my point. So long as the interviewer is telling you what they'd actually like you to do, you should be able to just derive the algorithm you need to do it. At some point the algorithms become difficult enough (particularly if you add lots of constraints like efficiency) that it's pretty unreasonable to expect that in an interview though, and at that point it's a bad question. 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.
    - pishpash 8y ago
      You're still not getting it. Even for BFS, which is not a hard problem, the current state of the market is that enough people have memorized the BFS recipe so that the interview doesn't allocate much of any time to it. You're not going to have/be given time to "just derive the algorithm" or "solve problems simply, quickly, and elegantly." You're competing against rote speed, which, if you don't implement BFS all day or haven't recently done interview prep, you don't have and you're definitely going to fail. 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.
acpetrov 8y ago
I just graduated, so I'm not dealing with constant internship interviews anymore, but at the time I absolutely hated it. 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
- jsmeaton 8y ago
  Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.
  - SamReidHughes 8y ago
    If you can't handle simple data structures problems you need to stay far, far away from software architecture.
    - scarface74 8y ago
      In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
      - 8y ago
mancerayder 8y ago
Honestly, there are so many posts like yours on HN, it's a surprise companies don't change this ridiculous algorithms thing. Hiring managers here complain that candidates all lie and they need to weed them out. However, algorithms bias towards younger people, recently out of college, math hobbyists and people with a lot of free time. 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.
- scarface74 8y ago
  I’m a software developer first and foremost, I am a software architect second these days specializing in building stuff on top of AWS. 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.
  - mancerayder 8y ago
    As a hiring manager I would be impressed by your background. Unfortunately most will never read that far back. Or worse, not have enough experience to understand someone who can do that can handle the needs of their software as a service CRUD app.
- halbritt 8y ago
  There's really no need to screen for liars. Generally speaking, I'll try to ascertain how the candidate represents the skills on their resume. Some represent their skills well and can describe in detail their approach to solving a problem or some such. From there, it's not hard to assess things like passion, determination, etc. 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.
abecedarius 8y ago
You're not wrong, but that one time you see a place for a new algorithm for a specialized problem can make a big enough difference to be worth it. If nobody in your group has the range, it's not likely you'll know when it'll pay to call in the research department with the PhDs exactly when they're needed, either. There's no bright line between coding and invention. 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.
- nnd 8y ago
  How would you go about mastering the principles rather than practicing random algorithmic challenges?
  - abecedarius 8y ago
    Udi Manber's Algorithms: A Creative Approach looks like a promising book to work through. There are lots of great resources that didn't exist when I was an undergrad. 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.
rock_hard 8y ago
This all comes down to what the company is optimizing for. 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!
- rossdavidh 8y ago
  Truth, and also especially so for a company like FB or Google where they probably have an abundance of qualified applicants, for a variety of reasons. For most companies, copying what FB or Google (or Microsoft or whoever) is doing, is probably a bad idea, in tech interviewing or many other things.
- vonmoltke 8y ago
  > 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.
  - pishpash 8y ago
    In at least one aspect, the adage becomes facially untrue -- you can fire bad employees, but you cannot get back good candidates rejected by means of a degrading exercise. You probably lose them forever. In companies where opportunity cost and hidden losses are nobody's responsibility, this sort of mediocrity is well accepted.
    - rock_hard 8y ago
      At FANG good candidates tend to apply again a year or so later
    - sethammons 8y ago
      You can fire the bad ones, sure. After you document everything and cross i's and dot t's. Even if you don't CYA, you still lost team productivity while they onboarded the new person, and that time is lost. Plus the hit to team moral, and possible negative affects to team culture of dealing with an under performer or toxic individual.
kbenson 8y ago
> Much more important is to have the experience of how code complexity accumulates, and how to mitigate that. 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.
LaserToy 8y ago
You are absolute right. I’m telling recruiters upfront that I will spend 0 time preparing and if it is a deal breaker - it is what it is.
LearnerHerzog 8y ago
> I cannot spend hours and hours studying up on these algorithms, there are much more important things (real coding-related things) which I need to learn about, to the extent I have time to do that. 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-into-google-the-15-reasons-why-over-2-million-people-apply-each-year https://www.forbes.com/sites/stanphelps/2014/08/05/cracking-...
- opportune 8y ago
  The easiest way to get hired at Google is to let them come to you, not to directly apply
  - LearnerHerzog 8y ago
    The Field of Dreams approach. "If you build it, they will come"
    - opportune 8y ago
      Really, that's not far from the truth. If you've worked at other well known "good" companies and worked on hot/important stuff, and that info is on linkedin, you will probably get approached by a google recruiter at some point. And unless you fuck up your call with them to make sure you're interested and a real person, that basically guarantees you a first round technical phone screen, which is the hardest part of getting hired at Google. You can study as much as you want and be the best engineer possible, but that won't matter if you don't get to the first round interview. You basically "build" a linkedin profile that comes up when recruiters search for technically hot things, and then they will come knocking
slimshady94 8y ago
Reiterating my view, I feel like the interviewing grind has become akin to gymming - you go to your mental gym, build up your 'muscles' by doing pointless repetitive tasks AKA algorithms you'd never use in real life (probably like how bodybuilders would never need to deadlift 125kgs in their daily life). It doesn't directly help you do your job but you know bodybuilders have higher than average fitness levels. So in the same manner, devs grinding leetcode probably have higher 'fitness' levels (mostly a type of muscle memory for programming) than devs who don't.
- um_ya 8y ago
  Except lifting weight has a DIRECT affect on increasing muscle mass. Doing pointless algorithms don't have any direct affect on your coding skills. I know plenty of college grads that can memorize all sorts of algorithms, but are shit at real world code. If I'm a company hiring to do REAL WORLD CODE, I'm going to ask questions pertaining to the position I'm willing to fill. The problem with these companies, is that they are hiring more than they need, therefore they aren't asking questions pertaining to any REAL job they're looking to fill.
- alextheparrot 8y ago
  It is also a form of “proof of work”. If you are willing to go to the lengths of learning these things, maybe you’ll be able to learn other things that are harder to assess during an interview.
  - lawnchair_larry 8y ago
    In that case, we should just get candidates to weave wicker baskets.
- rossdavidh 8y ago
  But, if I'm a scout for a football team, I don't want to see you in the gym, I want to see you play football. Maybe, ideally, I'd like to see both, but seeing you play football is by far the more important thing.
QML 8y ago
As someone who is interviewing for internships, I view all of these algorithms interviews as a necessary evil. While they may not reflect the day to day job demands of programming, they are certainly easier to measure and serve as a benchmark for candidates. 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.
BurningFrog 8y ago
I'm in a similar situation. 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...
- shashasha 8y ago
  I believe for older engineers who regularly read these threads, this is the comment. Wish it weren’t true, but it is.
credit_guy 8y ago
> What should I choose, pytorch or keras? 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.
- rossdavidh 8y ago
  How dare you add real information to our conversation here. :)
- Lyingdutchman 8y ago
  Somewhat late question: What would you recommend as the alternative for someone without nvidia gpu? Google colab?
  - credit_guy 8y ago
    I don't have a good answer to that (i.e. that I personally checked). However, FastAI lists some solutions in their latest version of the "practical deep learning for coders" course [1]. The google cloud version for example [2] was calculated to cost only about $40-$50 for the duration of their course (2 months), which is way, way better than the $10/day on AWS that I tried. [1] https://www.fast.ai/2019/01/24/course-v3/ https://www.fast.ai/2019/01/24/course-v3/ [2] https://course.fast.ai/start_gcp.html#budget-compute https://course.fast.ai/start_gcp.html#budget-compute
    - Lyingdutchman 8y ago
      I was aware of the fast.ai course, but not those guides. Thank you.
molodec 8y ago
I wrote a custom HashMap for Java, used BFS and DBS on graphs, wrote a top down custom parser, custom string searching algorithms to solve real business problems. I would rather work with someone who knows how neural networks really work rather than who knows pytorch or keras, because they can be learned rather easily. In some industries knowledge of algorithms can be more valuable than knowing a myriad of frameworks that change every few years any way.
- rimliu 8y ago
  There are people who really know how NN work? I thought there were only people who know how to implement them ;)
  - molodec 8y ago
    You right, but I would say we do know how artificial NN work, because we are able to construct them, but we don't actually know why they work ;)
- brabel 8y ago
  > In some industries knowledge of algorithms can be more valuable than knowing a myriad of frameworks that change every few years any way. 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-goldman-sachs-hppc-koloboke-trove-january-2015/ 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).
hellllllllooo 8y ago
As someone recently interviewing I targeted roles where I didn't have to jump through these hoops and it worked out fine. Contacting people I had worked with before who could vouch for me made it much easier to land a job. 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.
temp231239 8y ago
While I agree with you on the non-algorithmic coding skill being more important in most of the scenarios that an coder deals with at work, I feel having basic understanding of algorithmic skill is important as well for coder success. Interview should test basic algo skills along with other important skills, but when I put myself in interviewers shoe I realize how difficult its is to test on real coding challenges as every company has its own sets of tools and techniques that they use and prefer. Testing it would require first detailing coder on companies present tech culture which is a difficult for a code to get in short duration.
rudolph9 8y ago
Have you considered that they aren’t necessarily looking for a particular answer or even a correct answer but rather your thought process while working through problems and how you engage with a peer?
- hello_moto 8y ago
  Sadly they are looking for the most precise and optimum answer (at least at FB they do)
ttiurani 8y ago
I think the hidden agenda here might be that big corps also test for the candidate's a) motivation and b) obedience. Are you the sort of person who's willing to learn whiteboard programming on your spare time, and then tolerate abuse from the interviewers? The type of unethical business most of the big corps do works best with subservient, diligent code slingers.
- pikma 8y ago
  Is your experience that interviewers "abuse" candidates? I interview candidates about once a week, and I always try to make them feel at ease and comfortable, no matter if they are doing well or not. I would be curious to learn about other people's experiences.
  - ttiurani 8y ago
    I personally have only anecdotal evidence, but I've read now many stories where the interviewers of these giants refuse to engage in a two-way, human-to-human conversation with the candidate but instead make the ordeal deliberately prolonged, stressful and unconfortable. I'd call that abuse. 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.
austincheney 8y ago
> I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code 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 https://en.wikipedia.org/wiki/Invented_here
zoom6628 8y ago
You are so right. Im 55 now and have developed on tools, a lot of ERP/Manufacturing stuff, compliance, integration tools. Have never had the need to reach for Knuth so that shows either I am pig-ignorant, arrogant, or there is no real need in general. It is good to know algorithms but these are not the main stuff of the real world. Learn about design patterns, user experience, product philosophy, and invest time in learning about your company (who, how and why started, markets, competition) and you will go further and faster than being able to ace a whiteboard interview on the foibles of event processing in Vue. And yes i still cant write good javascript - because IT IS NOT IMPORTANT so i have avoided until this year and Im now learning it as a hobby, not a need.
namelosw 8y ago
I found essentially most 'algorithms' code is just terrible code. A lot of people spent a lot of time learning algorithms other than more broad techniques write terrible code every day. 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.
collyw 8y ago
I feel exactly the same.
GuB-42 8y ago
Even if if you don't roll your own code, knowing how it works is still important. I see cargos cult code far too often. 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.
world32 8y ago
Are algorithm puzzles really that ubiquitous in the US? 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.
- gdy 8y ago
  What do they ask in the UK?
  - nvarsj 8y ago
    It's not much different in the UK if you apply to FAANG, hedge fund, or a cargo culting startup.
  - AsyncAwait 8y ago
    I have interviewed in the UK and did algorithm whiteboarding, so I'd say it's company-specific, rather than country-specific.
  - world32 8y ago
    In my experience they typically ask you questions about the experience you've listed on your CV. If you say you have experience working with AWS, then they might ask you something like "explain what a VPC is and why is it useful?". Other more general questions are usually along the lines of "tell me about a solution to a problem you solved and how you designed the solution to that problem". 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.
ex_amazon_sde 8y ago
Ex Amazon here. We never asked silly puzzle questions, but asking questions about algorithmic complexity paid off when hiring strong, senior engineers. > 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.
ljm 8y ago
This is my main beef with tech interviews: you get given a test, or an algorithm, or put under the spotlight in a pairing session to solve a problem in essentially the least efficient way possible. It's usually under the guise of seeing how you think, but it's pretty damn hard to do that without also judging how the code looks and how much you were able to write. 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.
- Vadoff 8y ago
  >This then becomes representative of your experience... 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. 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.

ergothus 8y ago

I share both of your concerns (while I was very lucky in getting initial experience, I know of other beginners that haven't/arent, so I'm very sympathetic.) . Started coding for work in '95. > 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.

lowdest 8y ago
As I see it, the difficult algorithm interviews screen for people who are motivated enough to spend 100s of hours studying for an interview, or know this stuff for some other uncommon reason. Both types are acceptable hires.
- jammygit 8y ago
  Wouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? 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
  - brabel 8y ago
    > Wouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? 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 :)
    - BossingAround 8y ago
      I really think it depends on the quality of the project. If I'm looking at a candidate, and see 3 projects, each pushed in one commit, each project has 3 classes in one package, and I see pushed compiled classes as well as source classes, that's a clear sign that this person doesn't know what he or she's doing. 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.
  - BossingAround 8y ago
    It's interesting to me how many people value personal projects. From my personal experience, a confusing Github account with a number of small, questionable projects pushed in one commit half a year ago hurts you more than helps you. Personal projects are fine, but I think many people have the mentality of "getting a TODO app in Angular will help me waay more than implementing algorithms in C, that's useless!" which may not necessarily be true.

option 8y ago

There are career stages. For candidates just out of school or with little experience asking algorithmic questions totally makes sense. For more senior candidates (who actually progressed to the next stage, not just spent a lot of years), the questions become more real-life, more open ended and with more than one (or sometimes none) “correct” answer

jacquesm 8y ago

Algorithm interviews are good for people that will be writing algorithms. Most of us are just plumbers, even so a solid knowledge about what algorithms are available and what their strengths and weaknesses are is as important as good knowledge about the tools is to plumbers.

cornellwright 8y ago

Is BFS really that hard, especially if the interviewer is willing to talk it out with you and doesn't care a lot about finding the most efficient solution possible? 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.

spyspy 8y ago
You and a lot of other commenters are getting hung up on the BFS example. It's just that - an example. There are dozens of algorithms that are "common" enough to be asked about and diminishing returns to having them all memorized.
- cornellwright 8y ago
  Sure, but that's my point. So long as the interviewer is telling you what they'd actually like you to do, you should be able to just derive the algorithm you need to do it. At some point the algorithms become difficult enough (particularly if you add lots of constraints like efficiency) that it's pretty unreasonable to expect that in an interview though, and at that point it's a bad question. 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.
  - pishpash 8y ago
    You're still not getting it. Even for BFS, which is not a hard problem, the current state of the market is that enough people have memorized the BFS recipe so that the interview doesn't allocate much of any time to it. You're not going to have/be given time to "just derive the algorithm" or "solve problems simply, quickly, and elegantly." You're competing against rote speed, which, if you don't implement BFS all day or haven't recently done interview prep, you don't have and you're definitely going to fail. 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.

acpetrov 8y ago

I just graduated, so I'm not dealing with constant internship interviews anymore, but at the time I absolutely hated it. 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

jsmeaton 8y ago
Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.
- SamReidHughes 8y ago
  If you can't handle simple data structures problems you need to stay far, far away from software architecture.
  - scarface74 8y ago
    In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
    - 8y ago

mancerayder 8y ago

Honestly, there are so many posts like yours on HN, it's a surprise companies don't change this ridiculous algorithms thing. Hiring managers here complain that candidates all lie and they need to weed them out. However, algorithms bias towards younger people, recently out of college, math hobbyists and people with a lot of free time. 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.

scarface74 8y ago
I’m a software developer first and foremost, I am a software architect second these days specializing in building stuff on top of AWS. 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.
- mancerayder 8y ago
  As a hiring manager I would be impressed by your background. Unfortunately most will never read that far back. Or worse, not have enough experience to understand someone who can do that can handle the needs of their software as a service CRUD app.
halbritt 8y ago
There's really no need to screen for liars. Generally speaking, I'll try to ascertain how the candidate represents the skills on their resume. Some represent their skills well and can describe in detail their approach to solving a problem or some such. From there, it's not hard to assess things like passion, determination, etc. 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.

abecedarius 8y ago

You're not wrong, but that one time you see a place for a new algorithm for a specialized problem can make a big enough difference to be worth it. If nobody in your group has the range, it's not likely you'll know when it'll pay to call in the research department with the PhDs exactly when they're needed, either. There's no bright line between coding and invention. 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.

nnd 8y ago
How would you go about mastering the principles rather than practicing random algorithmic challenges?
- abecedarius 8y ago
  Udi Manber's Algorithms: A Creative Approach looks like a promising book to work through. There are lots of great resources that didn't exist when I was an undergrad. 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.

rock_hard 8y ago

This all comes down to what the company is optimizing for. 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!

rossdavidh 8y ago
Truth, and also especially so for a company like FB or Google where they probably have an abundance of qualified applicants, for a variety of reasons. For most companies, copying what FB or Google (or Microsoft or whoever) is doing, is probably a bad idea, in tech interviewing or many other things.
vonmoltke 8y ago
> 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.
- pishpash 8y ago
  In at least one aspect, the adage becomes facially untrue -- you can fire bad employees, but you cannot get back good candidates rejected by means of a degrading exercise. You probably lose them forever. In companies where opportunity cost and hidden losses are nobody's responsibility, this sort of mediocrity is well accepted.
  - rock_hard 8y ago
    At FANG good candidates tend to apply again a year or so later
  - sethammons 8y ago
    You can fire the bad ones, sure. After you document everything and cross i's and dot t's. Even if you don't CYA, you still lost team productivity while they onboarded the new person, and that time is lost. Plus the hit to team moral, and possible negative affects to team culture of dealing with an under performer or toxic individual.

kbenson 8y ago

> Much more important is to have the experience of how code complexity accumulates, and how to mitigate that. 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.

LaserToy 8y ago

You are absolute right. I’m telling recruiters upfront that I will spend 0 time preparing and if it is a deal breaker - it is what it is.

LearnerHerzog 8y ago

> I cannot spend hours and hours studying up on these algorithms, there are much more important things (real coding-related things) which I need to learn about, to the extent I have time to do that. 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-into-google-the-15-reasons-why-over-2-million-people-apply-each-year https://www.forbes.com/sites/stanphelps/2014/08/05/cracking-...

opportune 8y ago
The easiest way to get hired at Google is to let them come to you, not to directly apply
- LearnerHerzog 8y ago
  The Field of Dreams approach. "If you build it, they will come"
  - opportune 8y ago
    Really, that's not far from the truth. If you've worked at other well known "good" companies and worked on hot/important stuff, and that info is on linkedin, you will probably get approached by a google recruiter at some point. And unless you fuck up your call with them to make sure you're interested and a real person, that basically guarantees you a first round technical phone screen, which is the hardest part of getting hired at Google. You can study as much as you want and be the best engineer possible, but that won't matter if you don't get to the first round interview. You basically "build" a linkedin profile that comes up when recruiters search for technically hot things, and then they will come knocking

slimshady94 8y ago

Reiterating my view, I feel like the interviewing grind has become akin to gymming - you go to your mental gym, build up your 'muscles' by doing pointless repetitive tasks AKA algorithms you'd never use in real life (probably like how bodybuilders would never need to deadlift 125kgs in their daily life). It doesn't directly help you do your job but you know bodybuilders have higher than average fitness levels. So in the same manner, devs grinding leetcode probably have higher 'fitness' levels (mostly a type of muscle memory for programming) than devs who don't.

um_ya 8y ago
Except lifting weight has a DIRECT affect on increasing muscle mass. Doing pointless algorithms don't have any direct affect on your coding skills. I know plenty of college grads that can memorize all sorts of algorithms, but are shit at real world code. If I'm a company hiring to do REAL WORLD CODE, I'm going to ask questions pertaining to the position I'm willing to fill. The problem with these companies, is that they are hiring more than they need, therefore they aren't asking questions pertaining to any REAL job they're looking to fill.
alextheparrot 8y ago
It is also a form of “proof of work”. If you are willing to go to the lengths of learning these things, maybe you’ll be able to learn other things that are harder to assess during an interview.
- lawnchair_larry 8y ago
  In that case, we should just get candidates to weave wicker baskets.
rossdavidh 8y ago
But, if I'm a scout for a football team, I don't want to see you in the gym, I want to see you play football. Maybe, ideally, I'd like to see both, but seeing you play football is by far the more important thing.

QML 8y ago

As someone who is interviewing for internships, I view all of these algorithms interviews as a necessary evil. While they may not reflect the day to day job demands of programming, they are certainly easier to measure and serve as a benchmark for candidates. 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.

BurningFrog 8y ago

I'm in a similar situation. 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...

shashasha 8y ago
I believe for older engineers who regularly read these threads, this is the comment. Wish it weren’t true, but it is.

credit_guy 8y ago

> What should I choose, pytorch or keras? 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.

rossdavidh 8y ago
How dare you add real information to our conversation here. :)
Lyingdutchman 8y ago
Somewhat late question: What would you recommend as the alternative for someone without nvidia gpu? Google colab?
- credit_guy 8y ago
  I don't have a good answer to that (i.e. that I personally checked). However, FastAI lists some solutions in their latest version of the "practical deep learning for coders" course [1]. The google cloud version for example [2] was calculated to cost only about $40-$50 for the duration of their course (2 months), which is way, way better than the $10/day on AWS that I tried. [1] https://www.fast.ai/2019/01/24/course-v3/ https://www.fast.ai/2019/01/24/course-v3/ [2] https://course.fast.ai/start_gcp.html#budget-compute https://course.fast.ai/start_gcp.html#budget-compute
  - Lyingdutchman 8y ago
    I was aware of the fast.ai course, but not those guides. Thank you.

molodec 8y ago

I wrote a custom HashMap for Java, used BFS and DBS on graphs, wrote a top down custom parser, custom string searching algorithms to solve real business problems. I would rather work with someone who knows how neural networks really work rather than who knows pytorch or keras, because they can be learned rather easily. In some industries knowledge of algorithms can be more valuable than knowing a myriad of frameworks that change every few years any way.

rimliu 8y ago
There are people who really know how NN work? I thought there were only people who know how to implement them ;)
- molodec 8y ago
  You right, but I would say we do know how artificial NN work, because we are able to construct them, but we don't actually know why they work ;)
brabel 8y ago
> In some industries knowledge of algorithms can be more valuable than knowing a myriad of frameworks that change every few years any way. 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-goldman-sachs-hppc-koloboke-trove-january-2015/ 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).

hellllllllooo 8y ago

As someone recently interviewing I targeted roles where I didn't have to jump through these hoops and it worked out fine. Contacting people I had worked with before who could vouch for me made it much easier to land a job. 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.

temp231239 8y ago

While I agree with you on the non-algorithmic coding skill being more important in most of the scenarios that an coder deals with at work, I feel having basic understanding of algorithmic skill is important as well for coder success. Interview should test basic algo skills along with other important skills, but when I put myself in interviewers shoe I realize how difficult its is to test on real coding challenges as every company has its own sets of tools and techniques that they use and prefer. Testing it would require first detailing coder on companies present tech culture which is a difficult for a code to get in short duration.

rudolph9 8y ago

Have you considered that they aren’t necessarily looking for a particular answer or even a correct answer but rather your thought process while working through problems and how you engage with a peer?

hello_moto 8y ago
Sadly they are looking for the most precise and optimum answer (at least at FB they do)

ttiurani 8y ago

I think the hidden agenda here might be that big corps also test for the candidate's a) motivation and b) obedience. Are you the sort of person who's willing to learn whiteboard programming on your spare time, and then tolerate abuse from the interviewers? The type of unethical business most of the big corps do works best with subservient, diligent code slingers.

pikma 8y ago
Is your experience that interviewers "abuse" candidates? I interview candidates about once a week, and I always try to make them feel at ease and comfortable, no matter if they are doing well or not. I would be curious to learn about other people's experiences.
- ttiurani 8y ago
  I personally have only anecdotal evidence, but I've read now many stories where the interviewers of these giants refuse to engage in a two-way, human-to-human conversation with the candidate but instead make the ordeal deliberately prolonged, stressful and unconfortable. I'd call that abuse. 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.

austincheney 8y ago

> I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code 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 https://en.wikipedia.org/wiki/Invented_here

zoom6628 8y ago

You are so right. Im 55 now and have developed on tools, a lot of ERP/Manufacturing stuff, compliance, integration tools. Have never had the need to reach for Knuth so that shows either I am pig-ignorant, arrogant, or there is no real need in general. It is good to know algorithms but these are not the main stuff of the real world. Learn about design patterns, user experience, product philosophy, and invest time in learning about your company (who, how and why started, markets, competition) and you will go further and faster than being able to ace a whiteboard interview on the foibles of event processing in Vue. And yes i still cant write good javascript - because IT IS NOT IMPORTANT so i have avoided until this year and Im now learning it as a hobby, not a need.

namelosw 8y ago

I found essentially most 'algorithms' code is just terrible code. A lot of people spent a lot of time learning algorithms other than more broad techniques write terrible code every day. 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.

collyw 8y ago

I feel exactly the same.

GuB-42 8y ago

Even if if you don't roll your own code, knowing how it works is still important. I see cargos cult code far too often. 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.

world32 8y ago

Are algorithm puzzles really that ubiquitous in the US? 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.

gdy 8y ago
What do they ask in the UK?
- nvarsj 8y ago
  It's not much different in the UK if you apply to FAANG, hedge fund, or a cargo culting startup.
- AsyncAwait 8y ago
  I have interviewed in the UK and did algorithm whiteboarding, so I'd say it's company-specific, rather than country-specific.
- world32 8y ago
  In my experience they typically ask you questions about the experience you've listed on your CV. If you say you have experience working with AWS, then they might ask you something like "explain what a VPC is and why is it useful?". Other more general questions are usually along the lines of "tell me about a solution to a problem you solved and how you designed the solution to that problem". 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.

ex_amazon_sde 8y ago

Ex Amazon here. We never asked silly puzzle questions, but asking questions about algorithmic complexity paid off when hiring strong, senior engineers. > 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.

ljm 8y ago

This is my main beef with tech interviews: you get given a test, or an algorithm, or put under the spotlight in a pairing session to solve a problem in essentially the least efficient way possible. It's usually under the guise of seeing how you think, but it's pretty damn hard to do that without also judging how the code looks and how much you were able to write. 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.

Vadoff 8y ago
>This then becomes representative of your experience... 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. 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.