9 ms·

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. I'm a kick-ass get-things-done full-stack web eng

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them. A company that needs someone to solve these sorts of problems doesn't want me on their team in the first place, nor would I thrive there. A company that just needs to build damn good web apps is losing out by using these sorts of questions in their interviews. The best interview challenge I've had (actually, it was a take-home, with discussion in the interview proper) was about designing code for re-use and extension. It was a great indicator of the company's practical and mature approach to engineering, and of what they really wanted this hire to accomplish.

humanrebar 9y ago
I agree 95%. However, inevitably there will be a developer that will want to implement a trie for reasons. It's hard to be able to reason with her (or technical leadership when appealing the decision) when advocating for an off the shelf alternative if you can't explain why this isn't a brand new problem. On the flip side, one actually does need to create a new data structure on occasion, and obviously there we would want to be able to implement the common alternatives. Anyway, it's complicated. Especially when hiring for technical leadership.
- vonmoltke 9y ago
  If I need to convince another developer that a particular path is well-worn and that they are drifting towards NIH syndrome I have the benefit of time to develop an argument and resources with which to do so. I do not have 45 minutes, no resources, and just a whiteboard. To pre-counter an expected objection, if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.
  - humanrebar 9y ago
    > I have the benefit of time to develop an argument and resources with which to do so. One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess. Though I agree that no-google, closed-book, no-IDE whiteboard development is very unnatural. > ...if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process. I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.
    - vonmoltke 9y ago
      > One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess. They certainly do, but significant, unchangeable decisions should not be made that way. If I think there is a better alternative to something expressed in one of these discussions, but do not have the details at hand to make the case, I will voice the alternative and compile the details later. Choices like that should not be made without documented rationale anyway. > I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt. The solution is to fix the organizational dysfunction. Hiring to the dysfunction is a band-aid at best.
andrepd 9y ago
It's not about actually having to implement these algorithms in your practical, day-to-day work. It's a challenge to test your reasoning and problem-solving ability in abstract, that you can administer in 15 minutes. You can't really test a candidate with real-world workloads, can you.
- wpietri 9y ago
  You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though. I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.
  - x1798DE 9y ago
    You are often weeding through a large number of applicants, so spending 100 hours on each candidate is just not feasible, and, generally, not necessary. Plus, high quality, experienced developers are not going to want to spend 100+ hours doing real work for companies just to see if they can get a job. I'm more than happy to spend an hour here or there for a phone screen or coding test to show that I understand the basics of data structures and algorithms and that I can use that information and my reasoning ability to solve problems I haven't seen before.
    - wpietri 9y ago
      Then it's a good thing I didn't suggest spending 100 hours per candidate.
  - recursive 9y ago
    And how many candidates do you have to consider to find the right one? And what proportion of the interviewer's time is spent on the live coding interview vs setting it up and arranging it? I've been in this boat recently. It doesn't really take much to get to double or even triple digit hours if you don't automate something.
septimus111 9y ago
I agree that these interviews are often just an annoying rite of passage, and they exclude many very talented programmers, but dismissing companies that use them as 'incompetent' seems like a stretch to me. Learning basic data structures & algorithms is an immensely useful thing for a programmer, and completely essential in many cases. The best of these puzzles are based on problems which people have had to solve in the real world. For the companies, there are many benefits to conducting algorithms interviews: - setting a minimum standard to make sure there is a shared language and knowledge that you can expect any engineer in company to know. - making sure you are able to do more than trivial optimisation and go beyond the abstractions that libraries / frameworks provide - giving you a simple problem to solve in 30 minutes to see if you can program at all.
- jacquesm 9y ago
  It's just laziness incarnate. This pushes all the investment of the first phase of interviewing someone onto an automated process and denies the candidate the opportunity to vet the company which is just as important as the reverse. Well, actually they do allow the candidate to vet the company: the message they send is we don't care about you at all until you do a bunch of busywork and if you're very lucky we might allow a human to spend some cycles on reviewing your results. If as a company that is the kind of message you would want your prospective employees to have that's fine with me but it would be good to remember that interviewing a candidate is a two way street.
  - recursive 9y ago
    > It's just laziness incarnate You could be describing software in general.
    - jacquesm 9y ago
      Not really. Quite a bit of software is like a powertool and I certainly would not want to label the users of powertools as 'lazy'. But these companies are not using software as a powertool, they are using software in a way that attempts to deny their counterparty a mutual investment in the relationship. And that to me is lazy.
hashkb 9y ago
> I'm a kick-ass get-things-done full-stack web engineer. And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.
- cauterized 9y ago
  But I did learn the principle, back in school. I've just never needed to use it.
- bigtimeidiot 9y ago
  >If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?
  - hashkb 9y ago
    No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
    - logfromblammo 9y ago
      Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies. Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?" A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".
gpderetta 9y ago
I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).
- duiker101 9y ago
  This is very true, but I don't think that anyone interviewing for a position like yours will reference to this list of things to test their candidates.
- quantumhobbit 9y ago
  Where does one get a job writing actual algorithms and data structures? I actually enjoy that and am pretty good at it. I'm sick of jobs that are nothing but glueing together poorly documented and tested libraries.
  - quadrature 9y ago
    Data Engineering, SRE, Production Engineering are really good for that kind of thing. Especially at a larger company, but the truth is those opportunities aren't going to come up that often, you don't want to be continuously inventing your own technology unless you're living on the bleeding edge like Google.
  - gpderetta 9y ago
    I'm currently working in finance. Before that I was working at a major search engine which doesn't start with G.
  - Silhouette 9y ago
    Where does one get a job writing actual algorithms and data structures? Two big areas that come to mind are simulation/mathematical modelling, where you're often crunching data in ways that aren't just textbook examples, and embedded systems, where you often have resource constraints that make efficiency more important. This doesn't just mean modelling weather systems on supercomputers or writing the control software for cars, though. For example, consider user interfaces. We are increasingly looking for more intuitive input methods using techniques like natural language processing, speech recognition, handwriting recognition, and gesture-based UIs. We are looking for more intuitive output methods, such as integrating additional data with real world imagery like maps or the view through a 3D head set or camera. We are looking for systems that learn patterns in their users' behaviour and adapt to provide more likely options more quickly next time. You won't see much of this if you're just writing simple form-based web front-ends for CRUD applications. A lot of real world software is like that, and it gets a lot of useful work done, but it's mostly pretty mundane, join-the-dots work as far as the programming goes. However, there are plenty of interesting problems out there and we could directly improve the user's experience in new and helpful ways if we could solve them, and much of that work involve developing data structures and algorithms far beyond anything you'd find in an introductory textbook.
swalsh 9y ago
I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on. I have 4 books in the "The art of computer programming" series on my desk. They've been more or less decoration for several years, until I ran into a problem I couldn't google. Since I read them, I had an idea of where to start, and I used it as inspiration to craft a new solution tweaked from one of these foundational algorithms. That said, not everyone is strong in algorithm development, and you can be a kick ass programmer without that skill. I'd only ask these questions if I needed someone with that skill on my team.
- duiker101 9y ago
  In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.
  - hashkb 9y ago
    You are OK with not knowing how to invent, innovate, push the envelope, etc because you don't need to in order to collect your paycheck? Seems sad! Where is your passion for the craft?
    - jsnathan 9y ago
      That's not what he said.
    - duiker101 9y ago
      You misunderstood me. Of course I love to invent and innovate. That's why I don't like memorizing solution to coding challenges. But just because I don't know them by hearth doesn't mean I don't know where to find the solution. Which is the more important skill.
deleted 9y ago
[deleted]
sidlls 9y ago
> I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. This is far too broad. There are plenty of jobs in certain companies where a good understanding of the theory and practice encapsulated by these challenges is the bare-minimum requirement for doing well. Companies that leverage coding challenges like these for these positions aren't incompetent (at least, not for that reason). Just because your work doesn't require this depth of understanding of CS doesn't mean there is no such work. I'm skeptical, however, that the number of such jobs is very large, even in the "usual suspects" companies (Google, Amazon, etc.). Most jobs, even in these places, one can get by with the most rudimentary ability to understand what 'greater than' and 'lesser than' means and a chart describing time/space complexities of various structures and algorithms in a library.
southphillyman 9y ago
Honestly, is it unreasonable to require that people brush up on this stuff every couple of years? In my experience the majority of companies just want you to be able to do fizz buzz level whiteboarding and intelligently speak to your experience. I feel like we all know in advance which companies typically require a month long review of algorithms before the interview. IF you want to work for one of them then do what you need to do to get the job there. We all agree it's annoying but I really don't think it's as big a deal as people make it out to be.
- FLUX-YOU 9y ago
  You can conceivably move up to management, never have to deal with algorithm hazing again, and make more than the guy that has to refresh every few years. The rewards just do not add up for this to remain an industry practice.
  - Silhouette 9y ago
    But the innovative businesses that develop genuinely new technologies also hire "the guys that has to refresh every few years". Leaving aside the potential financial gains if you're in early enough and they have a big exit, those also tend to be interesting places to work. Moving into management is essentially changing career, and for the kind of person who actually enjoys programming and wants to do something creative and technical, there's no reason to assume they would either enjoy the new role or be any good at it.
  - khedoros1 9y ago
    That sounds like a career change that I wouldn't enjoy, despite being able to also avoid some of my least-favorite aspects of staying on the dev side of things.
dahart 9y ago
Most programmers on the market don't have a lot of experience, due to the programmer population increasing in size quickly over the last decades. (https://en.m.wikipedia.org/wiki/Population_pyramid https://en.m.wikipedia.org/wiki/Population_pyramid) So one big question all companies have is how to interview for programming positions by kids fresh out of school or who've had a job for at most a couple of years. This is less a question of competence and more a reflection of the age structure of the market for programmers. You will be working with people younger and less experienced than you. You will probably be hiring people younger than you -- how will you interview them? As someone with a couple decades professional experience, I see these challenges as one of many ways for competent companies to attempt to find competent programmers despite a lack of experience by the interviewee. The last company I interviewed for gave me coding challenges, but that's not all they asked, I got plenty of questions that allowed my experience to shine. If you only got coding challenges as an experienced developer, then yes, that would be a reason to avoid that company. On the flip side, my willingness to take the coding challenges in my interview allowed me to highlight my practical experience, because I crushed them with little preparation. Other experienced devs who refused the coding challenges or dragged their feet and complained about them lost the opportunity to receive an offer.
azaydak 9y ago
I suffer greatly in coding interview questions. I'm not a kick-ass full-stack engineer but rather a research engineer. I code every day but usually it is proof-of-concept demonstrations so I lack formal education / guidance of many professional coders. I'll knock a take home assignment out of the park but I do envy people who are great coders.
charles-salvia 9y ago
To me this sounds like you just develop dependency-laden bloatware, i.e. you'll throw in some 5 gigabyte Javascript library just to do one thing.
Dolores12 9y ago
> I've never had to deal with one of these sorts of problems in my day to day work; You are from different niche and actually you are being paid less than those guys who knows the stuff you don't From [0]: "[S]killed cloud and backend developers, as well as those who work in emerging technologies including Internet of Things, machine learning and augmented/virtual reality can make more money than frontend web and mobile developers whose skills have become more commoditized..." [0] https://www.linux.com/news/developer-nation/2017/3/visionmobile-report-lays-out-developer-salaries-skill-software-sector-and-location https://www.linux.com/news/developer-nation/2017/3/visionmob...
JustSomeNobody 9y ago
That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.
- enraged_camel 9y ago
  You don't need to be able to build a capacitor from scratch in order to understand how they work. Furthermore, electrical engineers don't have to build capacitors from scratch during job interviews to prove their competence.
  - khedoros1 9y ago
    No, but there's a level of the EE tech stack where you do need to understand (and have the ability to build) the level below. I don't need to know: how to construct a transistor, build a logic gate, build a look-ahead adder, construct an ALU, CPU, computer hardware, write assembly, or write a compiler to do my job (although the last couple start getting close enough to my bailiwick that I think they're useful). I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". The discussion would end up going into some properties of capacitors, why they chose that exact form of oscillator, expected use-cases, etc. The behavior of the object lower in the "stack" becomes important, and so does a real understanding of how they work. Of course, actually requiring them to build one would be ridiculous.
    - enraged_camel 9y ago
      >>I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". Sure, but that's the equivalent of drawing a diagram that explains how quick sort works, as opposed to implementing it using real code. Most companies demand the latter during interviews.
      - khedoros1 9y ago
partycoder 9y ago
A completely delusional comment, devoid of any roots in reality whatsoever, and an insult to the decency and dignity of software engineering, as well as an invitation to strip software engineering of the respect and compensation it deserves. A 13 year old making a website for his dog in PHP can fit your definition of full stack web engineer. The underlying parts of this "full" stack require significant domain knowledge around algorithms, data structures, computer architectures, operating systems, distributed systems, networking and communications, programming languages, etc... and most importantly, critical thinking and engineering rigor beyond trial and error and cargo cult copy-pasting from stackoverflow into your "get-things-done" duct-taped spaghetti code base. Those underlying parts created by the people that you now call "incompetent" are required to design, implement and maintain the "kick-ass" babyproofed playground you live in and that allows you to put food on your table. Have some respect. If you are so kick-ass and get-things-done, checkout the source code for Linux, Chromium, v8, node or libuv, Python, Ruby or whatever technology you use and try to get something done there to a level of quality in which it gets accepted and see what happens. You and your kick-ass denomination will be stomped over and brought back to reality.
ramblenode 9y ago
The problem with your reasoning is that you expect the interview to mirror job requirements rather than select for job performance. In many cases the best instrument to measure the latter will resemble the former, but there's nothing intrinsic about the relationship. If giving someone a brain teaser or having them recite trivia provides a strong signal for job performance, then it makes sense to use these instruments. You could argue that they don't provide a meaningful signal (which I think Google may have discovered with the brain teasers), but that is a separate discussion. Something else to consider is that the interview is optimized to select for true positives and reject false positives at different rates. It's been discussed elsewhere that for a company like Google avoiding false positives is much more important than finding good candidates. So it may be the case that some instruments like trivia recitation provide the right signal at the intersection of the optimization curves. The fact that many (even most) qualified candidates score poorly on these instruments doesn't impugn their utility; their primary goal isn't to identify good candidates but to filter out bad ones.

humanrebar 9y ago

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

vonmoltke 9y ago
If I need to convince another developer that a particular path is well-worn and that they are drifting towards NIH syndrome I have the benefit of time to develop an argument and resources with which to do so. I do not have 45 minutes, no resources, and just a whiteboard. To pre-counter an expected objection, if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.
- humanrebar 9y ago
  > I have the benefit of time to develop an argument and resources with which to do so. One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess. Though I agree that no-google, closed-book, no-IDE whiteboard development is very unnatural. > ...if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process. I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.
  - vonmoltke 9y ago
    > One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess. They certainly do, but significant, unchangeable decisions should not be made that way. If I think there is a better alternative to something expressed in one of these discussions, but do not have the details at hand to make the case, I will voice the alternative and compile the details later. Choices like that should not be made without documented rationale anyway. > I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt. The solution is to fix the organizational dysfunction. Hiring to the dysfunction is a band-aid at best.

andrepd 9y ago

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

wpietri 9y ago
You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though. I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.
- x1798DE 9y ago
  You are often weeding through a large number of applicants, so spending 100 hours on each candidate is just not feasible, and, generally, not necessary. Plus, high quality, experienced developers are not going to want to spend 100+ hours doing real work for companies just to see if they can get a job. I'm more than happy to spend an hour here or there for a phone screen or coding test to show that I understand the basics of data structures and algorithms and that I can use that information and my reasoning ability to solve problems I haven't seen before.
  - wpietri 9y ago
    Then it's a good thing I didn't suggest spending 100 hours per candidate.
- recursive 9y ago
  And how many candidates do you have to consider to find the right one? And what proportion of the interviewer's time is spent on the live coding interview vs setting it up and arranging it? I've been in this boat recently. It doesn't really take much to get to double or even triple digit hours if you don't automate something.

septimus111 9y ago

I agree that these interviews are often just an annoying rite of passage, and they exclude many very talented programmers, but dismissing companies that use them as 'incompetent' seems like a stretch to me. Learning basic data structures & algorithms is an immensely useful thing for a programmer, and completely essential in many cases. The best of these puzzles are based on problems which people have had to solve in the real world. For the companies, there are many benefits to conducting algorithms interviews: - setting a minimum standard to make sure there is a shared language and knowledge that you can expect any engineer in company to know. - making sure you are able to do more than trivial optimisation and go beyond the abstractions that libraries / frameworks provide - giving you a simple problem to solve in 30 minutes to see if you can program at all.

jacquesm 9y ago
It's just laziness incarnate. This pushes all the investment of the first phase of interviewing someone onto an automated process and denies the candidate the opportunity to vet the company which is just as important as the reverse. Well, actually they do allow the candidate to vet the company: the message they send is we don't care about you at all until you do a bunch of busywork and if you're very lucky we might allow a human to spend some cycles on reviewing your results. If as a company that is the kind of message you would want your prospective employees to have that's fine with me but it would be good to remember that interviewing a candidate is a two way street.
- recursive 9y ago
  > It's just laziness incarnate You could be describing software in general.
  - jacquesm 9y ago
    Not really. Quite a bit of software is like a powertool and I certainly would not want to label the users of powertools as 'lazy'. But these companies are not using software as a powertool, they are using software in a way that attempts to deny their counterparty a mutual investment in the relationship. And that to me is lazy.

hashkb 9y ago

> I'm a kick-ass get-things-done full-stack web engineer. And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.

cauterized 9y ago
But I did learn the principle, back in school. I've just never needed to use it.
bigtimeidiot 9y ago
>If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?
- hashkb 9y ago
  No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
  - logfromblammo 9y ago
    Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies. Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?" A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".

gpderetta 9y ago

I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

duiker101 9y ago
This is very true, but I don't think that anyone interviewing for a position like yours will reference to this list of things to test their candidates.
quantumhobbit 9y ago
Where does one get a job writing actual algorithms and data structures? I actually enjoy that and am pretty good at it. I'm sick of jobs that are nothing but glueing together poorly documented and tested libraries.
- quadrature 9y ago
  Data Engineering, SRE, Production Engineering are really good for that kind of thing. Especially at a larger company, but the truth is those opportunities aren't going to come up that often, you don't want to be continuously inventing your own technology unless you're living on the bleeding edge like Google.
- gpderetta 9y ago
  I'm currently working in finance. Before that I was working at a major search engine which doesn't start with G.
- Silhouette 9y ago
  Where does one get a job writing actual algorithms and data structures? Two big areas that come to mind are simulation/mathematical modelling, where you're often crunching data in ways that aren't just textbook examples, and embedded systems, where you often have resource constraints that make efficiency more important. This doesn't just mean modelling weather systems on supercomputers or writing the control software for cars, though. For example, consider user interfaces. We are increasingly looking for more intuitive input methods using techniques like natural language processing, speech recognition, handwriting recognition, and gesture-based UIs. We are looking for more intuitive output methods, such as integrating additional data with real world imagery like maps or the view through a 3D head set or camera. We are looking for systems that learn patterns in their users' behaviour and adapt to provide more likely options more quickly next time. You won't see much of this if you're just writing simple form-based web front-ends for CRUD applications. A lot of real world software is like that, and it gets a lot of useful work done, but it's mostly pretty mundane, join-the-dots work as far as the programming goes. However, there are plenty of interesting problems out there and we could directly improve the user's experience in new and helpful ways if we could solve them, and much of that work involve developing data structures and algorithms far beyond anything you'd find in an introductory textbook.

swalsh 9y ago

I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on. I have 4 books in the "The art of computer programming" series on my desk. They've been more or less decoration for several years, until I ran into a problem I couldn't google. Since I read them, I had an idea of where to start, and I used it as inspiration to craft a new solution tweaked from one of these foundational algorithms. That said, not everyone is strong in algorithm development, and you can be a kick ass programmer without that skill. I'd only ask these questions if I needed someone with that skill on my team.

duiker101 9y ago
In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.
- hashkb 9y ago
  You are OK with not knowing how to invent, innovate, push the envelope, etc because you don't need to in order to collect your paycheck? Seems sad! Where is your passion for the craft?
  - jsnathan 9y ago
    That's not what he said.
  - duiker101 9y ago
    You misunderstood me. Of course I love to invent and innovate. That's why I don't like memorizing solution to coding challenges. But just because I don't know them by hearth doesn't mean I don't know where to find the solution. Which is the more important skill.

deleted 9y ago

[deleted]

sidlls 9y ago

> I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. This is far too broad. There are plenty of jobs in certain companies where a good understanding of the theory and practice encapsulated by these challenges is the bare-minimum requirement for doing well. Companies that leverage coding challenges like these for these positions aren't incompetent (at least, not for that reason). Just because your work doesn't require this depth of understanding of CS doesn't mean there is no such work. I'm skeptical, however, that the number of such jobs is very large, even in the "usual suspects" companies (Google, Amazon, etc.). Most jobs, even in these places, one can get by with the most rudimentary ability to understand what 'greater than' and 'lesser than' means and a chart describing time/space complexities of various structures and algorithms in a library.

southphillyman 9y ago

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

FLUX-YOU 9y ago
You can conceivably move up to management, never have to deal with algorithm hazing again, and make more than the guy that has to refresh every few years. The rewards just do not add up for this to remain an industry practice.
- Silhouette 9y ago
  But the innovative businesses that develop genuinely new technologies also hire "the guys that has to refresh every few years". Leaving aside the potential financial gains if you're in early enough and they have a big exit, those also tend to be interesting places to work. Moving into management is essentially changing career, and for the kind of person who actually enjoys programming and wants to do something creative and technical, there's no reason to assume they would either enjoy the new role or be any good at it.
- khedoros1 9y ago
  That sounds like a career change that I wouldn't enjoy, despite being able to also avoid some of my least-favorite aspects of staying on the dev side of things.

dahart 9y ago

Most programmers on the market don't have a lot of experience, due to the programmer population increasing in size quickly over the last decades. (https://en.m.wikipedia.org/wiki/Population_pyramid https://en.m.wikipedia.org/wiki/Population_pyramid) So one big question all companies have is how to interview for programming positions by kids fresh out of school or who've had a job for at most a couple of years. This is less a question of competence and more a reflection of the age structure of the market for programmers. You will be working with people younger and less experienced than you. You will probably be hiring people younger than you -- how will you interview them? As someone with a couple decades professional experience, I see these challenges as one of many ways for competent companies to attempt to find competent programmers despite a lack of experience by the interviewee. The last company I interviewed for gave me coding challenges, but that's not all they asked, I got plenty of questions that allowed my experience to shine. If you only got coding challenges as an experienced developer, then yes, that would be a reason to avoid that company. On the flip side, my willingness to take the coding challenges in my interview allowed me to highlight my practical experience, because I crushed them with little preparation. Other experienced devs who refused the coding challenges or dragged their feet and complained about them lost the opportunity to receive an offer.

azaydak 9y ago

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

charles-salvia 9y ago

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

Dolores12 9y ago

> I've never had to deal with one of these sorts of problems in my day to day work; You are from different niche and actually you are being paid less than those guys who knows the stuff you don't From [0]: "[S]killed cloud and backend developers, as well as those who work in emerging technologies including Internet of Things, machine learning and augmented/virtual reality can make more money than frontend web and mobile developers whose skills have become more commoditized..." [0] https://www.linux.com/news/developer-nation/2017/3/visionmobile-report-lays-out-developer-salaries-skill-software-sector-and-location https://www.linux.com/news/developer-nation/2017/3/visionmob...

JustSomeNobody 9y ago

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

enraged_camel 9y ago
You don't need to be able to build a capacitor from scratch in order to understand how they work. Furthermore, electrical engineers don't have to build capacitors from scratch during job interviews to prove their competence.
- khedoros1 9y ago
  No, but there's a level of the EE tech stack where you do need to understand (and have the ability to build) the level below. I don't need to know: how to construct a transistor, build a logic gate, build a look-ahead adder, construct an ALU, CPU, computer hardware, write assembly, or write a compiler to do my job (although the last couple start getting close enough to my bailiwick that I think they're useful). I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". The discussion would end up going into some properties of capacitors, why they chose that exact form of oscillator, expected use-cases, etc. The behavior of the object lower in the "stack" becomes important, and so does a real understanding of how they work. Of course, actually requiring them to build one would be ridiculous.
  - enraged_camel 9y ago
    >>I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". Sure, but that's the equivalent of drawing a diagram that explains how quick sort works, as opposed to implementing it using real code. Most companies demand the latter during interviews.
    - khedoros1 9y ago

partycoder 9y ago

A completely delusional comment, devoid of any roots in reality whatsoever, and an insult to the decency and dignity of software engineering, as well as an invitation to strip software engineering of the respect and compensation it deserves. A 13 year old making a website for his dog in PHP can fit your definition of full stack web engineer. The underlying parts of this "full" stack require significant domain knowledge around algorithms, data structures, computer architectures, operating systems, distributed systems, networking and communications, programming languages, etc... and most importantly, critical thinking and engineering rigor beyond trial and error and cargo cult copy-pasting from stackoverflow into your "get-things-done" duct-taped spaghetti code base. Those underlying parts created by the people that you now call "incompetent" are required to design, implement and maintain the "kick-ass" babyproofed playground you live in and that allows you to put food on your table. Have some respect. If you are so kick-ass and get-things-done, checkout the source code for Linux, Chromium, v8, node or libuv, Python, Ruby or whatever technology you use and try to get something done there to a level of quality in which it gets accepted and see what happens. You and your kick-ass denomination will be stomped over and brought back to reality.

ramblenode 9y ago

The problem with your reasoning is that you expect the interview to mirror job requirements rather than select for job performance. In many cases the best instrument to measure the latter will resemble the former, but there's nothing intrinsic about the relationship. If giving someone a brain teaser or having them recite trivia provides a strong signal for job performance, then it makes sense to use these instruments. You could argue that they don't provide a meaningful signal (which I think Google may have discovered with the brain teasers), but that is a separate discussion. Something else to consider is that the interview is optimized to select for true positives and reject false positives at different rates. It's been discussed elsewhere that for a company like Google avoiding false positives is much more important than finding good candidates. So it may be the case that some instruments like trivia recitation provide the right signal at the intersection of the optimization curves. The fact that many (even most) qualified candidates score poorly on these instruments doesn't impugn their utility; their primary goal isn't to identify good candidates but to filter out bad ones.