27 ms·

This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps

This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API syntax. But at the same time I get if you’re trying to assess someone’s aptitude for devising novel algorithms, sometimes a closed book test makes sense. I think there are many devs (myself included earlier in my career) that push back in the algorithm tests because, well, it’s really hard. How often do you have to derive novel algos? A lot of our work is kind of UI frontends to DBs or gluing things and most of the sort of hard scalable algorithm problems someone else has implemented in a library. So why go through 6 months of really hard study, just to get that kind of job? Well, I think here should be “maker” roles where you can bypass the hard CS stuff and just crank code, if you have an impressive portfolio of work. But having a deep understanding of data structures (not just arrays and maps) and algorithms really gives you a mastery of your craft, especially around performance and scalability. Nobody should be screened out because they didn’t remember a particular bit of syntax though. (But it should be noted most algo tests don’t require anything but the language basics.)

username90 7y ago
I agree, cs needs a split in roles kinda like nurse and doctor.
- soulofmischief 7y ago
  I would say there are many kinds of computer scientists, and not all programmers are computer scientists and vice versa.
- abalone 7y ago
  “Code Practitioner” :-)
  - reaperducer 7y ago
    Free-range artisan software enabler.
- yomly 7y ago
  I liken it to research scientists vs technicians. A technician at CERN maintaining the accelerators is probably pretty damn smart, they probably also understand some particle physics. They may not be the ones driving/designing the experiments and they probably aren't getting their names on those physics papers but that doesn't mean they didn't contribute any value...
- azhenley 7y ago
  BS in CS versus PhD in CS?
  - amelius 7y ago
    Or "IT guy" versus "computer scientist".
    - azhenley 7y ago
      Or even IT, CS, and SE as three distinct degrees/career tracks.
    - abalone 7y ago
      IT person. And that’s different. We’re talking about a code heavy role, just without a strong command of C.S. fundamentals.
- ken 7y ago
  Fred Brooks said this back in 1975. He called it a surgical team. Of course, no manager reads The Mythical Man Month, and those that do don’t follow it.
  - 171243 7y ago
    Correct me if I am wrong but isn't the central premise of the book that if you take a late project and add more people to the team it takes the project longer??? I've literally never met a manager that practiced this. Is the book still relevant? Not disagreeing, just curious.
    - sanderjd 7y ago
      > I've literally never met a manager that practiced this. Yeah it's a pretty universal idea. > Is the book still relevant? Yes, precisely because that idea is so universal. Its advice has been relevant, insightful, and mostly ignored ever since it was written.
    - ergothus 7y ago
      You've never been on a project that was behind and management decided to add resources to it? Impressive! The book is worthwhile, not just for the central lesson, but WHY (TL;DR: communication overhead between different individuals increase as you add "nodes" - interestingly, you can make analogies to L2 cache expiration problems and others) and also a nice view at IBM of the past. And it was written in an era where there wasn't the need to make every book 300 pages long, so it's generally a lot more meat/page, though hardly perfect.
    - mikekchar 7y ago
      It's been ages since I read that book, but there is more to it that just the tag line you mention. It is very common to take a plan for work and to say, "This would take 10 people 1 year to developer, but we need it in 1-2 months. So let's put 100 programmers on the team". This is very much more obvious in Enterprise space and government contracting, but you see the reasoning everywhere. Here's quite a famous example: https://www.statista.com/statistics/272140/employees-of-twitter/ https://www.statista.com/statistics/272140/employees-of-twit... It shows a graph of the number of employees at Twitter over time. In Jan '08, there are 8. In Jan '09 there are 29. In Jan '10 there are 130. In Jan '11 there are 350. In Dec '13 there are 2712. Although a lot of that staff are going to be sales and marketing (and probably the growth is justified), the development team is also growing exponentially during that time. The Mythical Man Month would say that probably they are spending a lot more money than they need to to get the growth they needed. I used to work for a manufacturer of telephony equipment. On one of the products I worked on they had 5000 developers! (A single piece of code!!!). The average amount of code deployed was 1 line of code per day per developer. As much as we can argue that KLOC is a bad measure of productivity, if your average developer is only producing considerably less than 1 KLOC in an entire year, you know you have really, terrible, terrible problems. One of the questions you might want to ask is, if you want to write about 5000 lines of code a day, where is the sweet spot, actually? I think we can agree it's not at 5000 programmers. However, it's often really, really difficult to talk to non-technical management and get them to understand that more programmers does not usually equal more productivity. I could regale you with literally hundreds more examples, but I think it's sufficient to say that, yes, the Mythical Man Month is still really relevant these days.
- colechristensen 7y ago
  Iowa State has separate degrees for Software Engineering and Computer Science Which isn't the difference between doctor and nurse, more like an MD and PhD in medicine, one focused on practice, the other research.
  - abalone 7y ago
    I would think the engineers take algorithm and data structure courses so that’s not quite the distinction we’re talking about here.
    - freeone3000 7y ago
      Right, but theoretical computer science also deals with provability and goes into various areas of topology, reasoning, and proofs. These are not useful to engineers, or are only slightly useful, while a course on systems programming isn't useful to a theoretician, because a universal turing machine doesn't have hardware interrupts. Different specializations for different roles.
      - abalone 7y ago
        I agree. However I think it is not the distinction we’re talking about here, which is about not having a firm grasp of fundamental algorithms and data structures and big O scalability. In school terms it would be more like a technician or vocational training around coding for particular types of projects.
- Sharlin 7y ago
  In Finland, we have a two-tiered system where "proper" research universities primarily offer master's degrees, with a bachelor's just an intermediate step for most, even if they do not intend to pursue an academic career. So, a programmer with a CS degree likely has an MSc. In parallel, there are "applied science universities" that are typically not research-oriented, and by default offer bachelor-level degrees in more practical fields of study such as nursing and engineering (including software engineering).
- EpicBlackCrayon 7y ago
  I think there should be 3 different roles. Computer Scientists - Come up with the foundational algorithms etc. Software Engineers - Translate and map those foundational algorithms into more readily available tooling, occasionally directly building a complex system using engineering principles. Software Developers - Use the tooling created by software engineers to create user friendly solutions for the masses, aka developing apps or websites.
kortilla 7y ago
This comment propagates the nonsense that skills with algos are somehow harder or more exclusive than software engineering skills. They are orthogonal and interviews that conflate them are part of the problem. Consider this, many of the most novel algorithms were published without ever being run in actual software or in part of a larger system.
- abalone 7y ago
  Most people would say algorithms are the building blocks of software engineering, not orthogonal. Most screens also include a systems design test. Maybe you could argue all we ever should do is system design tests. But they don’t always involve coding.
  - kortilla 7y ago
    Aluminum is a building block of modern large airplanes. When hiring aeronautical engineers I don’t grill them on the finer points of aluminum smelting.
rolltiide 7y ago
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Yes the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do. Indeed I interview my candidate's ability to find resources, to know what considerations are needed, how to deal with IDEs, collaborative tools, the git protocol. I will fire someone on the spot for implementing an academic algorithm if there was a library and potentially peer reviewed library they should have used instead.
- GreenJelloShot 7y ago
  Are you hiring?
  - rolltiide 7y ago
    No, but I hope other organizations can adopt my approach.
- abalone 7y ago
  And I think those “maker” types of roles don’t need a hard C.S. screen. But algorithms aren’t just about reimplementing the classics. There are points even in ordinary “DB front end” type of work where understanding algos will affect how you scale. You may find you’ve just been getting away with brute force approaches because that data sets were small. You can go very far like that but there may come a day when it matters and then it will really matter.
  - rolltiide 7y ago
    I don't disagree with you, and it all comes up after the 20 second standup and in the code reviews, not in the interview, and not in a two week long orientation Overfitting for the possibility that it might be necessary in a design choice is not the way to gatekeep candidates
  - kthejoker2 7y ago
    ...and when that day comes you call a specialist to handle the case and let your "ordinary" worker get back to work on the 99% of the job space she's qualified for? I find this very ironic: Hiring for suitability to handle edge cases is also a brute force approach that doesn't scale. A good algorithm optimizes for expe ted inputs and farms out cache misses and unexpected behavior to some other system.
_bxg1 7y ago
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I've met lots of younger devs who have varying degrees of impostor syndrome, so anecdotes like this probably help people like that feel less bad about not knowing everything.
- setr 7y ago
  I'm of the opinion that not googling stuff means you're not a proper engineer. And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.
  - Bang2Bay 7y ago
    Why not Yahoo?
    - bdcravens 7y ago
      Because Yahoo isn't a search engine; the results are powered by another search engine (at this time, Bing)
      - hk__2 7y ago
        The definition of what is a search engine doesn’t change based of its internal implementation (here, Bing).
        bdcravens 7y ago
        Sure, maybe a better term is "virtual search engine" (in the sense the Mobile Virtual Network Operators are just mobile service resellers)
      - autoexec 7y ago
        Bing gets their results from other search engines too. https://www.wired.com/2011/02/bing-copies-google/ https://www.wired.com/2011/02/bing-copies-google/ As far as I can just about every search engine uses results from Google directly or indirectly by using a source like Bing that in turn gets some of their results from Google. If you won't call something a search engine unless it doesn't use anyone else's search results you might have a hard time naming more than one. You can't escape Google.
blackflame7000 7y ago
Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)
- jonfw 7y ago
  A good whiteboard interview doesn't require much outside of basic syntax/data structures, and will offer some form of help along the way (often in the form of a somewhat helpful interviewer).
- sharadov 7y ago
  Every engineer on HN (several threads that I've browsed) seems to have a serious disdain for coder-pad interviews/whiteboard sessions. And I think HN has a good representation of software engineers. So, who are these companies hiring?
  - abalone 7y ago
    Every student I’ve ever met seems to have a serious disdain for exams, but for some reason universities keep giving them.
    - sharadov 7y ago
      I would rather do an exam every year, and get a grade on the skills that they expect. Exams are standardized, granted that they are not perfect, but its closest to a system that works. Am not at the whims and fancies of an individual interviewer.
      - abalone 7y ago
        I'm not sure what you mean by standardization. You're totally at the whim of the exam-maker either way. If anything I find algorithm screens tend to draw from a semi-standard set of fundamentals as outlined in books like Cracking the Coding Interview and tested on Leetcode among many other examples.
lunchables 7y ago
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I see it at least a couple times a week on sub-reddits related to software development. Junior devs who are convinced more senior developers are super-geniuses who know everything from memory.
- deleted 7y ago
  [deleted]
- pmontra 7y ago
  We (I'm 50+) know for sure many more things and I see the surprise of junior developers but the exact details? There are too many of them, especially because senior developers often are not narrowly focused on a single part of a project. A simple example. I'm working with Rails, Django, Phoenix and React (3 different projects). I know I need to do a strftime but I don't remember the exact details in any of Ruby, Python, Elixir and JavaScript. I always google them or grep the source code for other instances.
- wool_gather 7y ago
  Yeah, absolutely. Even more experienced folks sometimes get stuck on this. There's some selection/confirmation bias: you ask questions in chat or whatever, and there's someone who's got a lot of answers, and you're grateful and excited by the help. But you ignore all the time they were only partially right, or wrong, or -- most important! didn't even answer at all because they weren't familiar with the topic. (But someone else did answer, and also gets added to your mental "expert" list.) And of course you don't see all the things that they don't know or are struggling with. (Some of which could easily be things that seem simple and comfortable to you!) I try to dissuade this kind of thinking when I see it: I like answering people's questions, and I take pride in knowing a lot of stuff. But there's way more stuff that I don't know than that I know. And I might need these folks' help with something I'm unfamiliar with, so I don't want them thinking they're "below" me and there's no way they could know something I don't. I'm sure they do!
deleted 7y ago
[deleted]
methodover 7y ago
> But having a deep understanding of data structures (not just arrays and maps) and algorithms really gives you a mastery of your craft, especially around performance and scalability. Can you give an example?
- sanderjd 7y ago
  Ha, yeah, I might say something similar, except that I would say, "mostly just arrays and maps".
- abalone 7y ago
  Ok.. Find all the words that match a search string prefix. I.e. you have a search field and want to show the possible matches as you type. With each new char you’re calling this search and getting back a list of words. The dictionary is in memory in whatever data structure you choose. You only have to return matches if the search is 3 or more chars long. Now, how does your implementation scale when the dictionary has a million words?
  - anaphor 7y ago
    FWIW, even highly accomplished software developers / hackers like Jonathan Blow[1] have said that in almost every case, you should just use an array as your data structure (or some variation of an array), unless you actually have a good reason not to (that will get you a lot of value) Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them, it just means you shouldn't reach for say, a fibonacci heap before you just use an array. [1] https://en.m.wikipedia.org/wiki/Jonathan_Blow https://en.m.wikipedia.org/wiki/Jonathan_Blow
    - abalone 7y ago
      > Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them.. We don't disagree. Understanding data structures is about reaching for the right tool, and very often the hammer of an array/map is the right tool. But the problem I gave isn't that exotic. It's a case where "reaching for an array" is a brute force solution that won't scale. So how do you separate candidates who understand those limitations from those that don't? By asking about those cases. They're not that common, but that doesn't mean they never come up or you won't get a nasty bug if you don't understand these foundations.
inimino 7y ago
> I think here should be “maker” roles where you can bypass the hard CS stuff and just crank code I would call these "user" roles. And perhaps there is a space for a "professional software user" career as we continue building software so unnecessarily complex that only a professional can use it.
inimino 7y ago
Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing that and stop using that.
- benologist 7y ago
  I think compounding the issue is a lot of devs jump complex technologies pretty quickly so we're constantly trying to overcome a deficit in knowledge but never stopping long enough to do so.
  - inimino 7y ago
    Agreed. When we recognize this, we often jump to a new shiny tech rather than stop, remove complexity from the environment, and regroup, as we should.
- lotyrin 7y ago
  Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet. Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task. Basically, I wish I could achieve productive software development from an isolated cabin without an internet connection to provide distractions, with lots of subtle natural ambiance and my own thoughts instead of interruptive social interactions, and synchronize my work product with society on the same cadence with which I would travel to town to get groceries. Obviously, this is not the situation.
  - inimino 7y ago
    > Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet. This is how you can get into Csikszentmihalyi's "flow", if you add a little cognitive work and struggle to it, so it's not just typing in the solution. > Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task. Some tasks are like that, some business opportunities are amenable to that approach, some teams work that way, and many more aren't and don't. But yes, not spinning your wheels is a prerequisite to getting maximally engaged in your work and getting good results. Sometimes that requires a lot of interruptions of the actual work, because the work is rarely well specified in advance. If it was, it probably would not be interesting because it would already have been done. > Obviously, this is not the situation. It could be the situation, and there is work that needs to be done in that way. In fact, this work tends to have high value, including business value, precisely because our dominant working style prevents almost all of us from achieving it. We can get closer by mastering our tools and by choosing tools that afford mastery in their use.
lliamander 7y ago
> How often do you have to derive novel algos? I have done what you could call deriving novel algorithms, and in a commercial context no less[1]. What is or is not an algorithm not very well defined. There was a famous paper which defined an algorithm as "logic + control", which could really describe any code that we write. I think what the experience taught me (where a CS education might help) was how to think algorithmically. The point of algorithmic thinking and algorithmic code is to be able to prove (formally or informally) that certain undesirable states are impossible. Algorithms focused around performance have proofs that unnecessary computations are not performed, cryptographic algorithms have proofs that secrets are not revealed during the computation, concurrency algorithms prove that data races do not occur, and so on. It's actually quite easy to apply this sort of thinking to highly problem-specific code. The more specific the code is, the stronger the guarantees you can prove. What becomes more difficult is writing code that is both generic and is able to make interesting guarantees about the state space of it's execution. It's the code that kind of code (generic with strong guarantees) that are what people typically mean by "algorithms". [1] Not really as bad as this https://xkcd.com/664/ https://xkcd.com/664/
pankajdoharey 7y ago
Well searching such basic stuff may mean you are not.
tzumby 7y ago
I bet you can train a model to predict your skill based on your google searches related to software development.
dragonsh 7y ago
As programmer becomes more proficient at work in things like language syntax, api's, library and algorithms, the usage of googling will go down, as it becomes distraction, instead of helping in doing a programming task quicker. Screening and interview selection is driven by need. If one needs a subject matter expert in specific area, it does make a sense to test the person's familiarity with subject without googling. It also helps to test Duning-Kruger effect. [1] But this is wrong to assume that googling is bad. Being able to search, assimilate and effectively use information (by book or Google), is also a very important skill in itself. I feel doing a test to figure out if the person has understood some common data structures and algorithms is good to see how a person approach and solves the problems, since programming is still an inherently logical puzzle solving. [1] https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect
- jmharvey 7y ago
  > As programmer becomes more proficient at work in things like language syntax, api's, library and algorithms, the usage of googling will go down, as it becomes distraction, instead of helping in doing a programming task quicker. This has been the opposite of my experience. Earlier in my career there was a lot more "sit and think about how to assemble these basic building blocks." Now it's a lot more "man, it would be nice if complex object A could play well with complex object B, I wonder how to make that work and what the pitfalls are." I'm googling different things than I used to, sure, but pretty much any task I'm tackling at this point involves a fair amount of googling for docs, github issues, stack overflow, etc.
solotronics 7y ago
I always bring a laptop to interviews (haven't had one in a long time) and Google stuff during the interview and pull up my notes. If they say something I responded with "well I will always have a laptop at work anyways".
- Noumenon72 7y ago
  Even though I was embarrassed when I couldn't state what inversion of control was because I didn't have my notes to remind me of the "shopping cart vs government form" metaphor, I think having me look it up and read it to them would have been worse. Do you mostly use it for syntax, not stuff like "how do you deal with a deadlock"? https://www.quora.com/How-will-you-explain-Inversion-of-Control-in-laymans-terms/answer/Vladimir-Cvejanovic https://www.quora.com/How-will-you-explain-Inversion-of-Cont...

username90 7y ago

I agree, cs needs a split in roles kinda like nurse and doctor.

soulofmischief 7y ago
I would say there are many kinds of computer scientists, and not all programmers are computer scientists and vice versa.
abalone 7y ago
“Code Practitioner” :-)
- reaperducer 7y ago
  Free-range artisan software enabler.
yomly 7y ago
I liken it to research scientists vs technicians. A technician at CERN maintaining the accelerators is probably pretty damn smart, they probably also understand some particle physics. They may not be the ones driving/designing the experiments and they probably aren't getting their names on those physics papers but that doesn't mean they didn't contribute any value...
azhenley 7y ago
BS in CS versus PhD in CS?
- amelius 7y ago
  Or "IT guy" versus "computer scientist".
  - azhenley 7y ago
    Or even IT, CS, and SE as three distinct degrees/career tracks.
  - abalone 7y ago
    IT person. And that’s different. We’re talking about a code heavy role, just without a strong command of C.S. fundamentals.
ken 7y ago
Fred Brooks said this back in 1975. He called it a surgical team. Of course, no manager reads The Mythical Man Month, and those that do don’t follow it.
- 171243 7y ago
  Correct me if I am wrong but isn't the central premise of the book that if you take a late project and add more people to the team it takes the project longer??? I've literally never met a manager that practiced this. Is the book still relevant? Not disagreeing, just curious.
  - sanderjd 7y ago
    > I've literally never met a manager that practiced this. Yeah it's a pretty universal idea. > Is the book still relevant? Yes, precisely because that idea is so universal. Its advice has been relevant, insightful, and mostly ignored ever since it was written.
  - ergothus 7y ago
    You've never been on a project that was behind and management decided to add resources to it? Impressive! The book is worthwhile, not just for the central lesson, but WHY (TL;DR: communication overhead between different individuals increase as you add "nodes" - interestingly, you can make analogies to L2 cache expiration problems and others) and also a nice view at IBM of the past. And it was written in an era where there wasn't the need to make every book 300 pages long, so it's generally a lot more meat/page, though hardly perfect.
  - mikekchar 7y ago
    It's been ages since I read that book, but there is more to it that just the tag line you mention. It is very common to take a plan for work and to say, "This would take 10 people 1 year to developer, but we need it in 1-2 months. So let's put 100 programmers on the team". This is very much more obvious in Enterprise space and government contracting, but you see the reasoning everywhere. Here's quite a famous example: https://www.statista.com/statistics/272140/employees-of-twitter/ https://www.statista.com/statistics/272140/employees-of-twit... It shows a graph of the number of employees at Twitter over time. In Jan '08, there are 8. In Jan '09 there are 29. In Jan '10 there are 130. In Jan '11 there are 350. In Dec '13 there are 2712. Although a lot of that staff are going to be sales and marketing (and probably the growth is justified), the development team is also growing exponentially during that time. The Mythical Man Month would say that probably they are spending a lot more money than they need to to get the growth they needed. I used to work for a manufacturer of telephony equipment. On one of the products I worked on they had 5000 developers! (A single piece of code!!!). The average amount of code deployed was 1 line of code per day per developer. As much as we can argue that KLOC is a bad measure of productivity, if your average developer is only producing considerably less than 1 KLOC in an entire year, you know you have really, terrible, terrible problems. One of the questions you might want to ask is, if you want to write about 5000 lines of code a day, where is the sweet spot, actually? I think we can agree it's not at 5000 programmers. However, it's often really, really difficult to talk to non-technical management and get them to understand that more programmers does not usually equal more productivity. I could regale you with literally hundreds more examples, but I think it's sufficient to say that, yes, the Mythical Man Month is still really relevant these days.
colechristensen 7y ago
Iowa State has separate degrees for Software Engineering and Computer Science Which isn't the difference between doctor and nurse, more like an MD and PhD in medicine, one focused on practice, the other research.
- abalone 7y ago
  I would think the engineers take algorithm and data structure courses so that’s not quite the distinction we’re talking about here.
  - freeone3000 7y ago
    Right, but theoretical computer science also deals with provability and goes into various areas of topology, reasoning, and proofs. These are not useful to engineers, or are only slightly useful, while a course on systems programming isn't useful to a theoretician, because a universal turing machine doesn't have hardware interrupts. Different specializations for different roles.
    - abalone 7y ago
      I agree. However I think it is not the distinction we’re talking about here, which is about not having a firm grasp of fundamental algorithms and data structures and big O scalability. In school terms it would be more like a technician or vocational training around coding for particular types of projects.
Sharlin 7y ago
In Finland, we have a two-tiered system where "proper" research universities primarily offer master's degrees, with a bachelor's just an intermediate step for most, even if they do not intend to pursue an academic career. So, a programmer with a CS degree likely has an MSc. In parallel, there are "applied science universities" that are typically not research-oriented, and by default offer bachelor-level degrees in more practical fields of study such as nursing and engineering (including software engineering).
EpicBlackCrayon 7y ago
I think there should be 3 different roles. Computer Scientists - Come up with the foundational algorithms etc. Software Engineers - Translate and map those foundational algorithms into more readily available tooling, occasionally directly building a complex system using engineering principles. Software Developers - Use the tooling created by software engineers to create user friendly solutions for the masses, aka developing apps or websites.

kortilla 7y ago

This comment propagates the nonsense that skills with algos are somehow harder or more exclusive than software engineering skills. They are orthogonal and interviews that conflate them are part of the problem. Consider this, many of the most novel algorithms were published without ever being run in actual software or in part of a larger system.

abalone 7y ago
Most people would say algorithms are the building blocks of software engineering, not orthogonal. Most screens also include a systems design test. Maybe you could argue all we ever should do is system design tests. But they don’t always involve coding.
- kortilla 7y ago
  Aluminum is a building block of modern large airplanes. When hiring aeronautical engineers I don’t grill them on the finer points of aluminum smelting.

rolltiide 7y ago

> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Yes the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do. Indeed I interview my candidate's ability to find resources, to know what considerations are needed, how to deal with IDEs, collaborative tools, the git protocol. I will fire someone on the spot for implementing an academic algorithm if there was a library and potentially peer reviewed library they should have used instead.

GreenJelloShot 7y ago
Are you hiring?
- rolltiide 7y ago
  No, but I hope other organizations can adopt my approach.
abalone 7y ago
And I think those “maker” types of roles don’t need a hard C.S. screen. But algorithms aren’t just about reimplementing the classics. There are points even in ordinary “DB front end” type of work where understanding algos will affect how you scale. You may find you’ve just been getting away with brute force approaches because that data sets were small. You can go very far like that but there may come a day when it matters and then it will really matter.
- rolltiide 7y ago
  I don't disagree with you, and it all comes up after the 20 second standup and in the code reviews, not in the interview, and not in a two week long orientation Overfitting for the possibility that it might be necessary in a design choice is not the way to gatekeep candidates
- kthejoker2 7y ago
  ...and when that day comes you call a specialist to handle the case and let your "ordinary" worker get back to work on the 99% of the job space she's qualified for? I find this very ironic: Hiring for suitability to handle edge cases is also a brute force approach that doesn't scale. A good algorithm optimizes for expe ted inputs and farms out cache misses and unexpected behavior to some other system.

_bxg1 7y ago

> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I've met lots of younger devs who have varying degrees of impostor syndrome, so anecdotes like this probably help people like that feel less bad about not knowing everything.

setr 7y ago
I'm of the opinion that not googling stuff means you're not a proper engineer. And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.
- Bang2Bay 7y ago
  Why not Yahoo?
  - bdcravens 7y ago
    Because Yahoo isn't a search engine; the results are powered by another search engine (at this time, Bing)
    - hk__2 7y ago
      The definition of what is a search engine doesn’t change based of its internal implementation (here, Bing).
      - bdcravens 7y ago
        Sure, maybe a better term is "virtual search engine" (in the sense the Mobile Virtual Network Operators are just mobile service resellers)
    - autoexec 7y ago
      Bing gets their results from other search engines too. https://www.wired.com/2011/02/bing-copies-google/ https://www.wired.com/2011/02/bing-copies-google/ As far as I can just about every search engine uses results from Google directly or indirectly by using a source like Bing that in turn gets some of their results from Google. If you won't call something a search engine unless it doesn't use anyone else's search results you might have a hard time naming more than one. You can't escape Google.

blackflame7000 7y ago

Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)

jonfw 7y ago
A good whiteboard interview doesn't require much outside of basic syntax/data structures, and will offer some form of help along the way (often in the form of a somewhat helpful interviewer).
sharadov 7y ago
Every engineer on HN (several threads that I've browsed) seems to have a serious disdain for coder-pad interviews/whiteboard sessions. And I think HN has a good representation of software engineers. So, who are these companies hiring?
- abalone 7y ago
  Every student I’ve ever met seems to have a serious disdain for exams, but for some reason universities keep giving them.
  - sharadov 7y ago
    I would rather do an exam every year, and get a grade on the skills that they expect. Exams are standardized, granted that they are not perfect, but its closest to a system that works. Am not at the whims and fancies of an individual interviewer.
    - abalone 7y ago
      I'm not sure what you mean by standardization. You're totally at the whim of the exam-maker either way. If anything I find algorithm screens tend to draw from a semi-standard set of fundamentals as outlined in books like Cracking the Coding Interview and tested on Leetcode among many other examples.

lunchables 7y ago

> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I see it at least a couple times a week on sub-reddits related to software development. Junior devs who are convinced more senior developers are super-geniuses who know everything from memory.

deleted 7y ago
[deleted]
pmontra 7y ago
We (I'm 50+) know for sure many more things and I see the surprise of junior developers but the exact details? There are too many of them, especially because senior developers often are not narrowly focused on a single part of a project. A simple example. I'm working with Rails, Django, Phoenix and React (3 different projects). I know I need to do a strftime but I don't remember the exact details in any of Ruby, Python, Elixir and JavaScript. I always google them or grep the source code for other instances.
wool_gather 7y ago
Yeah, absolutely. Even more experienced folks sometimes get stuck on this. There's some selection/confirmation bias: you ask questions in chat or whatever, and there's someone who's got a lot of answers, and you're grateful and excited by the help. But you ignore all the time they were only partially right, or wrong, or -- most important! didn't even answer at all because they weren't familiar with the topic. (But someone else did answer, and also gets added to your mental "expert" list.) And of course you don't see all the things that they don't know or are struggling with. (Some of which could easily be things that seem simple and comfortable to you!) I try to dissuade this kind of thinking when I see it: I like answering people's questions, and I take pride in knowing a lot of stuff. But there's way more stuff that I don't know than that I know. And I might need these folks' help with something I'm unfamiliar with, so I don't want them thinking they're "below" me and there's no way they could know something I don't. I'm sure they do!

deleted 7y ago

[deleted]

methodover 7y ago

> But having a deep understanding of data structures (not just arrays and maps) and algorithms really gives you a mastery of your craft, especially around performance and scalability. Can you give an example?

sanderjd 7y ago
Ha, yeah, I might say something similar, except that I would say, "mostly just arrays and maps".
abalone 7y ago
Ok.. Find all the words that match a search string prefix. I.e. you have a search field and want to show the possible matches as you type. With each new char you’re calling this search and getting back a list of words. The dictionary is in memory in whatever data structure you choose. You only have to return matches if the search is 3 or more chars long. Now, how does your implementation scale when the dictionary has a million words?
- anaphor 7y ago
  FWIW, even highly accomplished software developers / hackers like Jonathan Blow[1] have said that in almost every case, you should just use an array as your data structure (or some variation of an array), unless you actually have a good reason not to (that will get you a lot of value) Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them, it just means you shouldn't reach for say, a fibonacci heap before you just use an array. [1] https://en.m.wikipedia.org/wiki/Jonathan_Blow https://en.m.wikipedia.org/wiki/Jonathan_Blow
  - abalone 7y ago
    > Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them.. We don't disagree. Understanding data structures is about reaching for the right tool, and very often the hammer of an array/map is the right tool. But the problem I gave isn't that exotic. It's a case where "reaching for an array" is a brute force solution that won't scale. So how do you separate candidates who understand those limitations from those that don't? By asking about those cases. They're not that common, but that doesn't mean they never come up or you won't get a nasty bug if you don't understand these foundations.

inimino 7y ago

> I think here should be “maker” roles where you can bypass the hard CS stuff and just crank code I would call these "user" roles. And perhaps there is a space for a "professional software user" career as we continue building software so unnecessarily complex that only a professional can use it.

inimino 7y ago

Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing that and stop using that.

benologist 7y ago
I think compounding the issue is a lot of devs jump complex technologies pretty quickly so we're constantly trying to overcome a deficit in knowledge but never stopping long enough to do so.
- inimino 7y ago
  Agreed. When we recognize this, we often jump to a new shiny tech rather than stop, remove complexity from the environment, and regroup, as we should.
lotyrin 7y ago
Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet. Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task. Basically, I wish I could achieve productive software development from an isolated cabin without an internet connection to provide distractions, with lots of subtle natural ambiance and my own thoughts instead of interruptive social interactions, and synchronize my work product with society on the same cadence with which I would travel to town to get groceries. Obviously, this is not the situation.
- inimino 7y ago
  > Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet. This is how you can get into Csikszentmihalyi's "flow", if you add a little cognitive work and struggle to it, so it's not just typing in the solution. > Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task. Some tasks are like that, some business opportunities are amenable to that approach, some teams work that way, and many more aren't and don't. But yes, not spinning your wheels is a prerequisite to getting maximally engaged in your work and getting good results. Sometimes that requires a lot of interruptions of the actual work, because the work is rarely well specified in advance. If it was, it probably would not be interesting because it would already have been done. > Obviously, this is not the situation. It could be the situation, and there is work that needs to be done in that way. In fact, this work tends to have high value, including business value, precisely because our dominant working style prevents almost all of us from achieving it. We can get closer by mastering our tools and by choosing tools that afford mastery in their use.

lliamander 7y ago

> How often do you have to derive novel algos? I have done what you could call deriving novel algorithms, and in a commercial context no less[1]. What is or is not an algorithm not very well defined. There was a famous paper which defined an algorithm as "logic + control", which could really describe any code that we write. I think what the experience taught me (where a CS education might help) was how to think algorithmically. The point of algorithmic thinking and algorithmic code is to be able to prove (formally or informally) that certain undesirable states are impossible. Algorithms focused around performance have proofs that unnecessary computations are not performed, cryptographic algorithms have proofs that secrets are not revealed during the computation, concurrency algorithms prove that data races do not occur, and so on. It's actually quite easy to apply this sort of thinking to highly problem-specific code. The more specific the code is, the stronger the guarantees you can prove. What becomes more difficult is writing code that is both generic and is able to make interesting guarantees about the state space of it's execution. It's the code that kind of code (generic with strong guarantees) that are what people typically mean by "algorithms". [1] Not really as bad as this https://xkcd.com/664/ https://xkcd.com/664/

pankajdoharey 7y ago

Well searching such basic stuff may mean you are not.

tzumby 7y ago

I bet you can train a model to predict your skill based on your google searches related to software development.

dragonsh 7y ago

As programmer becomes more proficient at work in things like language syntax, api's, library and algorithms, the usage of googling will go down, as it becomes distraction, instead of helping in doing a programming task quicker. Screening and interview selection is driven by need. If one needs a subject matter expert in specific area, it does make a sense to test the person's familiarity with subject without googling. It also helps to test Duning-Kruger effect. [1] But this is wrong to assume that googling is bad. Being able to search, assimilate and effectively use information (by book or Google), is also a very important skill in itself. I feel doing a test to figure out if the person has understood some common data structures and algorithms is good to see how a person approach and solves the problems, since programming is still an inherently logical puzzle solving. [1] https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect

jmharvey 7y ago
> As programmer becomes more proficient at work in things like language syntax, api's, library and algorithms, the usage of googling will go down, as it becomes distraction, instead of helping in doing a programming task quicker. This has been the opposite of my experience. Earlier in my career there was a lot more "sit and think about how to assemble these basic building blocks." Now it's a lot more "man, it would be nice if complex object A could play well with complex object B, I wonder how to make that work and what the pitfalls are." I'm googling different things than I used to, sure, but pretty much any task I'm tackling at this point involves a fair amount of googling for docs, github issues, stack overflow, etc.

solotronics 7y ago

I always bring a laptop to interviews (haven't had one in a long time) and Google stuff during the interview and pull up my notes. If they say something I responded with "well I will always have a laptop at work anyways".

Noumenon72 7y ago
Even though I was embarrassed when I couldn't state what inversion of control was because I didn't have my notes to remind me of the "shopping cart vs government form" metaphor, I think having me look it up and read it to them would have been worse. Do you mostly use it for syntax, not stuff like "how do you deal with a deadlock"? https://www.quora.com/How-will-you-explain-Inversion-of-Control-in-laymans-terms/answer/Vladimir-Cvejanovic https://www.quora.com/How-will-you-explain-Inversion-of-Cont...