Hacker News Reader

Comment by abalone | Hacker News Reader

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.)

View on HN

> 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.

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.

I’ve asked pre-internet programmers and they said they used to keep reference books at their desk or even a small library/book room at their employers.

I’ve heard some government contractors can’t google because they work on non-internet connected computers. They probably keep a lot of books.

Starting around 8th grade, I would walk to the recently opened Barnes and Noble with a pen and notepad and hand copy material from programming books I couldn't afford, then walk back home and try the stuff out in Turbo C. Rinse, repeat.

Fun times.

I haven't looked anything up in a book on programming in a long time, but I'm not really a software engineer presently. While I rely on Google in general and stack overflow in particular, I don't believe everything is on the Internet. I went through a period where I started to think everything was, but in recent years I realized it isn't.

And just making the decision to type things into Google is far from the ability to search effectively. Increasingly search engines will converge on a bad answer for a given question because it's the most popular. You just cannot assume that the correct solution is going to be prominent, because once another one has critical mass, it cannot be dethroned. The result that sounds just barely plausible enough to fool the average person making the search (not the average programmer) wins, and often it's terribly wrong.

A friend works at a military contractor doing (effectively) windows GUIs for power system controls. His only access to an internet-connected computer is on his breaks, where he has to wait in line to use one of a very small number of computers in a special room to google things.

I don't think he has books, but he has an enormous amount of documentation (something like the whole MSDN library, a bunch of internal documentation and reference info, and other documentation) installed on his computer.

I hope they can get a StackOverflow offline archive https://archive.org/details/stackexchange

I've never worked pre-internet. In fact, I've had internet access in all of my jobs, but I've definitely worked pre-"internet was a useful source for searching for answers to programming questions". I mean, we had Usenet, and you could ask a question, but we didn't have search engines that were useful in that capacity.

I definitely had a lot of books, but actually the vast majority of my information came from man pages, RFCs and specs. I actually learned C++ by reading the spec -- I've never read any C++ book in my life, even though I was a professional C++ programmer for at least 10 years. For learning the STL, I did it by reading the source code!

Probably the biggest thing I miss in the age of Google is that offline documentation is getting hard to find. One of the reasons I chose Rust for my latest side project is that it's extremely easy to install offline information for virtually everything.

I like doing web searches searches and Stack Overflow is really stupendously awesome. Especially when I'm working in a new language or framework, I can find idiomatic solutions to problems without having to read through thousands of lines of source code. However, I do think that newer programmers today are missing out when they don't learn how to search primary sources to get their answers.

If you have a question about how the language works, it really does pay off to look at the spec. In doing so, you learn about things in a larger context. I'm always grateful for SO answers that have links to primary sources like specs in their answers, but I've noticed that my younger colleagues almost never click on those links. When they have the answer they want, they are back to their own code. Often they miss important nuances because they are too focused on getting the answer.

Similarly, I have found that there is often a huge reluctance to read source code. A colleague once joked that he used dependencies so that he didn't have to read the source code. It's funny because it's true ;-) However, if you at least try to answer your questions first by looking at the source code for a dependency, then it will tell you a lot about that dependency (mostly: OMG! We need to ditch this ASAP! ;-) )

I used to have a collection of hundreds of RFCs on my computer. Really, anything that is about the internet has an RFC (or did back in the day, anyway). These days, even I'm lazy and don't bother to maintain offline collections of this information. However, it is worrying that I often run into developers who build very complex internet applications and don't even know what an RFC is let alone use them to learn how they should build their systems. They will have very ingrained opinions on how build things, but they have no idea how the HTTP protocol works, for example. Discussions on the topic of how to design something usually results in snippets of blog posts obtained through Google searches, rather than pointing to the relevant RFC and saying, "It works like X so we need to do Y". Negotiation of how to proceed often involves considerable heated discussion about which notable internet pundit we should trust the most.

Yeah, this is an "old programmer rant" ;-) However, if I could wave a magic wand and get younger programmers to all add something to their arsenal of tricks it would be to read primary sources early and often.

> we didn't have search engines that were useful in that capacity.

I remember that. I think it was a combination of there not being good reference websites in some cases, not good question sites in others, and search engines generally being both less good and having less of those sites to index.

I specifically remember finding sites that were goldmines for certain topics, and hoarding them in my bookmark list of useful resources.

RFCs are great and definitely under utilized. I was working on some stuff with CORS and Cookies at my last job and reading through portions of some RFCs really helped me solve my problems and understand how CORS works.

I have a friend who used to work for the defence civil service and one time he was out in the desert in the USA with no proper internet connection just email - he emailed his techie friends to ask how you did some arcane vbscript stuff as we could look it up.

Reminds me of the days of paper datasheets for electronics. God am I glad I missed out on that.

I worked for a few months without an internet connection, I'd go to public wifi spots and load up on all the documentation and packages I needed. I wouldn't recommend it but it definitely teaches you to be resourceful.

The first programming language I learned was BASIC, using the (quite obscure) Z-BASIC environment. I put a lot of wear on the reference manual, and had many page numbers memorized.

That's what I did at the time. I only got rid of my series of Java 2, Motif, Xlib/Xt, etc programming books when I moved a few years back.

But what if you need them again?

Why not Yahoo?

Because Yahoo isn't a search engine; the results are powered by another search engine (at this time, Bing)

The definition of what is a search engine doesn’t change based of its internal implementation (here, Bing).

Sure, maybe a better term is "virtual search engine" (in the sense the Mobile Virtual Network Operators are just mobile service resellers)

I’ve tried Bing. Many of the result were unrelated to my question.

Google does such a good job with personalized results, that we have have forgotten how to search. Remember the old days when using a search engine effectively was a specialized skill? Search engines have gotten a lot better since then, but a lot of the improvements have been due to personalized results. It’s not easy to transition from Google to Bing or DuckDuckGo.

That being said, Google is also a good search engine, so it’s difficult to compete with them regardless of personalized results.

Using a search engine is a more specialized skill than ever.

What "Google getting better" actually means is that it is more likely to return what most people want as the first page hits. That is a tradeoff, because it obscures everything else whenever what most people want is wrong.

As a programmer, you're only going to be doing searches for things that are non-obvious, so there is a vastly higher chance of Google giving you the wrong answer than for the average search.

There is a fundamental contradiction between a search engine that tries to show you only what it thinks you want, and the fact that you don't know exactly what you want when you search, until you see some results.

I think there's something like a conservation law, that the more you make it easy to find some things on the Internet, the harder you make it to find others. Kind of like the proof that you can't compress all strings.

Bing has issues with not scraping dynamic content very well if at all. We had to eliminate libraries that render important content after page load with javascript because they'd show up on Google but not Bing.

Bing gets their results from other search engines too. 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.

Perhaps, though I suspect much has changed in the 8+ years since that article was written.

It really does. I've been a professional developer/programmer for a few years - since I was 18 - and I'm only just going back to college (at the behest of my employer).

Really enjoy taking advantage of it and reassuring the younger kids (only two or three years younger than me) that they're more than capable of this shit. And it helps me be more confident when I'm at work - at school they see me as the guy with all the answers (ha, I wish - but it's a good reminder that we're all our own worst critics).

Not just younger devs, I've been a professional coder for 24 years now and I still have imposter syndrome.

I saw Scott Hanselman speak, and he said he has impostor syndrome. I thought to myself, great, if Hanselman has impostor syndrome, I'm not even qualified. I must be an impostor-syndrome impostor.

Maybe that's Hanselman's ploy. Run mind games on you to make your imposter syndrome worse. Muahahaha.

I have this all the time, but to counter it I think about this time last year and it wouldn't have worked at all, now it works but it may be ugly, even better I almost understand why it works.

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)

IMO it's not. I've never given or taken a whiteboard interview where the I (or the candidate) was not allowed to either google things or to make assumptions about how certain things worked.

For example, if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it. We might come back to this later in the interview, but I'm generally uninterested in whether you memorized an algorithm for it or remembered how to call the standard library function that does it.

That said, if you make up the black box function, I might dig into why you designed the function signature the way you did, and I'd do that to see whether you can talk about code design from a "other people will read and use and debug your code" perspective.

> if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it

But sometimes, the interview question is generating all the permutations :(

True... but that does mean they're not expecting that you can remember the algorithm. :)

Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc.

In any case, there's a lot of strategies to show that you understand a concept without relying on exact memorization. For example, a common answer I give if I can't remember something might be something like: "The language has a sort function that can accept a list, I don't remember the exact API or the underlying implementation but let's assume it's n log(n) as that's a common runtime complexity for sorting--I'm going to define that as 'sort(listArg)'." I don't remember the exact function, so I'll just define and explain how it might work myself. If you're expected to be able to compile the code you're writing, simply ask the interviewer and explain the API you're looking for, I've had great success with that as well and prefer when an interviewee asks me over staring at the screen or board.

If it's a problem where you're expected to produce some algorithm, if you can't come up with any solution, explain to your interviewer what you're stuck on. They may provide a hint that will get you rolling. I had this happen during an interview at Microsoft (spoiler, I got the job) where I forgot how to determine the length of the hypotenuse of a triangle haha. The interviewer wrote the formula on the board and we moved on. Interviewer later told me I seemed nervous and he chalked it up to a brain fart--good call, I was really nervous! The point of that problem wasn't to see if I knew the Pythagorean theorem--it was just a small piece of the puzzle I was stumped on. Similarly start from a simple, naive solution, and interatively optimize rather than trying to recall a perfectly optimal solution. If time is running low, explain your intended optimization or ones you think might be meaningful, making note of any uncertainties in that explanation.

I've worked at Microsoft, Amazon, some other notables and interviewed at many others. I am speaking from that experience. Others may have better ideas. Of course, not all places approach this in a reasonable fashion and some are just missing the point entirely with their interview and they do expect you to somehow memorize everything.

I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and built multiple large scale production systems and i've also simultaneously forgotten whether it should be += or =+ during a whiteboard interview because of a phenomenon I can't quite describe. Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot.

The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.

> Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot.

This 100% happened to me (apart from being laughed at) only it was even more of a meltdown. Also 10 years experience and a problem I could do in my sleep. It was my first interview after a long time and it triggered performance anxiety and nervousness.

The solution is you need to practice live interviews, not just leetcode solo.

If the system is so poorly evaluating people that they have to train an irrelevant set of skills to succeed in it, what does that say about the system?

I am a big fan of the take-home problem. For example, Symantec once asked applicants to design a simple virus detector with wildcards (similar to grep) and then they gave interview spots to people with the best performance. During the actual interview, however, there wasn't much whiteboard coding only designing or "how would you do X" sort of questions.

There's a small list of companies I'd do a, "Take home test," for. In my experience, most companies that ask for it are looking for free labor.

I've never done a take home test that produced anything that could have been vaguely useful for the interviewing company. Usually the problems are pretty artificial.

They absolutely should be artificial problems. If they're not carefully designed to test what the hiring company cares about, it's a bad test

Well if they are good enough for you to put their code into your program then shouldn't they be good enough to be offered a job? Seems like it works exactly as intended in terms of trying to find someone who can do the job

I've had multiple take home tests result in changes to the products that company offers. I've never received a job offer from those companies. Maybe your experience differs, but I've had a sour taste left by such practice.

I wouldn't say coding algorithms is "irrelevant". It's sort of like saying the SAT is irrelevant. It's a general aptitude test. It's not about the "relevancy" of trigonometry to your day to day work.

You could argue it's stupid and colleges should only look at personal essays and GPAs and extracurriculars. But then there's problems with that too (lack of standardization for one).

You could argue that high schools shouldn't teach trig or calc because they're largely irrelevant to most tasks in most fields and "what does that say about the system". But actually they do come into play once and awhile and lay a conceptual foundation, so they're still sort of useful to learn. And thus they form a good common foundation to test aptitude inside an hour or so, or at least no one's thought of a better one.

I knew when the interviewer pulled out his phone to snap a picture of only that part of the whiteboard that I didn’t get the job lol

Whiteboard interviews exist because without them companies wouldn't have a metric to artificially restrict hiring. Passing a whiteboard interview makes both the company and interviewee feel special and maintains the bubble of software engineering salaries.

Companies don't care about artificially restricting hiring: they want developers to be as cheap as possible.

The truth is, software engineering really quite hard, but that whiteboard interviews just happen to be a rather poor way of evaluating candidates.

A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process.

> A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process.

I'm not sure what any of these mean in concrete terms. Is an IQ test like those "why are manhole covers round" Microsoft questions of yore? Yuck. Is a work sample a homework test? That takes more time for both parties. It's not a good substitute for a 1 hour first round screen. And what's a "structured" interview??

You should probably look up what an IQ test involves instead of just guessingly blindly, getting it wrong and then writing off the suggestion based on a wrong assumption.

Is stratifying income based off of IQ any more than we already have something that would benefit society?

in sofar as IQ helps predict actual job performance, I'd say yes.

Now I'm not saying the situation isn't complicated. In the mid-20th century, IQ testing was a great driver of social mobility. However, as was pointed out in _The Bell Curve_, it's becoming the opposite. From what I understand, the heritability of IQ and assortative mating (i.e. people marrying other people of similar IQ/educational attainment) are the main drivers of this.

I don't think the formation of an entrenched class system is necessarily a good thing, but I think in the local context of our industry there's still a lot of good that could be done by improving our hiring process. I mean, would you rather hire people who only sound smart, or who are smart?

You have questions, and I have answers!

https://www.wired.com/2015/04/hire-like-google/

If you have more questions after reading that, then ask away.

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?

A couple personal observations here.

I think there's a serious disdain for interviewing in general. The whole process sucks from end to end. Often it's because the interviewers just aren't good at it. But when it comes down to whiteboard interviewing, I think it's about your value system.

More specifically, I think every interviewer has an opinion on the practical <--> theoretical spectrum, and the problem is when the candidate disagrees with the interviewer's opinion on where on the spectrum the interview should be.

The upside of a practical interview is that you are testing whether they can do the work. The downside of a practical interview is that it indexes heavily on experience and lightly on the ability to cross disciplines. Theoretical interviews are the reverse.

So the important question is: what does your team care about? Google will care much more about the ability for their engineers to move around than your startup will. In general large companies will care much more about portability. They have deeper pockets and are therefore more willing to train you on the job, so generally speaking if they think you can ramp up (even for senior hires), they're happy. As much as startups will say they see things this way, it's not really true. Startups in general care that their senior hires come with substantial domain expertise.

I'm not sure HN is representative of anything, especially if you only look at what's upvoted. If I had to guess, I'd say that this sentiment is posted by people with 10 years of experience who feel like they should be talking about something else during interviews, but that it's being upvoted by college students or recent grads (no matter what you're asked to learn, a large fraction of the group will be frustrated by it)

They are hiring a bunch of people who have a serious disdain for the way they are interviewed. A better question might be, "who are these companies putting in charge of their interview process?". I think the answer there is largely, "people who have a serious disdain for this kind of interview, but still need to interview people and don't have any better ideas for how to do it".

Every student I’ve ever met seems to have a serious disdain for exams, but for some reason universities keep giving them.

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.

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.

I let candidates use their phone to Google or ask me to Google on their behalf. What they're Googling for never matters in the context of the interview and it's mostly to make them feel more comfortable.

It's a whiteboard, I'm looking out for far more important things than whether the method is named `size` or `length`.

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).

I think whiteboard interviews are fine, so long as the candidate is told ahead of time what the subject the whiteboard test will be about and has time to study for it (perhaps even given a take-home coding assignment about the same subject) and where the subject is actually relevant to code that has been written at the company.

But I do think that Computer Science Jeopardy on a whiteboard is a bad idea.

A good interviewer will not care about syntactic things, but rather try to sniff out your workflow and thoughts / processing when breaking down a process. It should be a proper two-way interaction.

A shitty interviewer will follow a rigid script and "ding" you on trivial errors.

> 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.

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.

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!

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.

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.

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.

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".

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-Cont...

> 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.

> the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do

The process for successful interviewing at places that use whiteboard testing for interviewing involves digging in and putting in a lot of hard work studying previously unknown concepts-- work that most people don't consider very fun.

To me, this sounds like exactly the kind of thing that a person will need to do to be successful in their first few months in a big company. Learning about their particular systems, authentication and authorization methods, security audit procedures, deployment methods, how they do dependency injection, logging, diagnostics, troubleshooting...

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.

...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.

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

Are you hiring?

No, but I hope other organizations can adopt my approach.

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.

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.

> 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.

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.

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.

I don't typically have to google much but I recently attempted to update webpack/babel at work and I must have made over 100 searches of error messages in build tool packages I didn't even know existed.

Exhibit A showing why I consider these tools fundamentally broken by design.

> 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.

> 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?

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?

Prefix tree is the right answer here right? From an interview standpoint.

But my question is: why would you want to roll your own here? Wouldn’t the appropriate move be to look for solutions for your specific use case that’ve already been made? Ie if you’re talking web, I see no reason why a standard database index would work. MySQL’s index, a b-tree, is perfectly serviceable for the question, no? I’m having trouble imaging a situation where an out of the box solution wouldn’t work...

I don’t think I have a deep understanding of efficient data structures. I couldn’t re-implement a red black tree for example without looking it up. I wonder: is it enough to have a cursory understanding of things like runtime complexity, space complexity; understand the different basic data structures and how they have trade offs that can help or hinder different operations, and how that connects to real world work. Especially how different actual solutions use different data structures internally. What I don’t understand is the value from going from cursory understanding of data structures to deep understanding.

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

> 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.

I would start by asking the question without mentioning scaling at all, and see how they respond.

If they immediately jump to using a fancy data structure like a suffix array, but they don't ask any questions about how critical performance and scaling are, then it shows they know a lot of stuff about CS, but they may be lacking in more practical experience.

If they tell you they would just use an array or a map (which would be extremely inefficient with large amounts of data), then you ask a follow-up question about scaling, and see how they respond. If they can't answer that question, then they lack practical experience and fundamental knowledge of advanced data structures.

Do you agree with that approach?

I totally agree with asking the basic question and then adding scale and complexity.

I don't know if I agree that using a trie at the outset reflects poorly on a candidate. They might see where you are going with the question, even though "you didn't mention scale." Good candidates are going to think about scale at least a little bit. That's not necessarily "lacking practical experience." It's not like basic tries or linked lists are super complex "fancy" data structures.

I think the key is for both parties to communicate thought process. If you're concerned about overengineering then prompt them to explain why they didn't choose an array.

Outside of special cases you would be doing lookup in some data store so this has fairly minimal chance of mattering in a real world project.

Load it all into Elasticsearch and just do an API call.

Network latency is an issue then. The word list is going to lag behind keystrokes. Also, doesn't work offline.

If you assume your corpus fits in the same instance (since you mention offline), you can run a single node elasticsearch on the same instance as well.

No, you can't run elasticsearch offline on a web client.

Look, we can keep going back and forth and maybe you'll dig up some javascript library that implements a search. And that's fine, I believe there are "maker" roles that largely are about gluing things together and translating requirements into code and shouldn't require screening for CS fundamentals. But at some point it gets a little hacky and suboptimal if you lack a good practical grasp of computer science.

Ha, yeah, I might say something similar, except that I would say, "mostly just arrays and maps".

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

> 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/

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

> 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.

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

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...

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.

I would think the engineers take algorithm and data structure courses so that’s not quite the distinction we’re talking about here.

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.

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.

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.

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.

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.

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-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.

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.

> 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.

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).

“Code Practitioner” :-)

Free-range artisan software enabler.

I would say there are many kinds of computer scientists, and not all programmers are computer scientists and vice versa.

BS in CS versus PhD in CS?

Or "IT guy" versus "computer scientist".

IT person. And that’s different. We’re talking about a code heavy role, just without a strong command of C.S. fundamentals.

Or even IT, CS, and SE as three distinct degrees/career tracks.

Well searching such basic stuff may mean you are not.

Reply on news.ycombinator.com