Hacker News Reader

This idea that you have repeated several times...

> A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm.

> In my 12 years as a developer thus far I have never needed to ... write an algorithm to markup some HTML

> A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever.

> Only a developer working with data or writing an algorithm to sort it should need to know that stuff.

This is either a spectacularly narrow view of what an algorithm is or it is totally wrong.

I've done both front-end and back-end/data for years. I frequently write "algorithms" on the front-end. Several of these were recent:

- Retry method for AJAX form submission

- Distribute assorted icons evenly among primary keys in a table.

- Dependency chain to check and execute asynchronously fetched scripts in the right order

- Even CSS can be somewhat algorithmic, as when I optimized by about 100X the hiding and showing of a huge amount of table rows with cascading style rules instead of JS

I don't think I need to go on, but the point is that if you think front-end developers don't need algorithms, then you are doing something wrong. I would check your assumptions about whether hiring for this is actually helpful. The companies you are talking about are leaders in both front-end and back-end technology. How do you think that came to be?

You know the saying, "If you have a hammer, everything looks like a nail"? I think the corollary to that is "If you don't have a hammer, nothing looks like a nail".

If you have little knowledge of graph theory, algorithms, and other such "esoteric nonsense", you wouldn't recognize situations where those will be helpful, which then reinforces your belief that algorithms are useless. I have seen too many times a person saying that algorithms are useless, who then gets stuck wondering why his naive O(n!) program is running so slow.

This so much. I don't get how people can think that something so simply and straightforward as the time complexity of an algorithm is something superfluous that only belongs to some boring classes they took in university, and it has nothing to do with "real world problems".

Those people complaining about Google caring so much about their engineers being able to deal with basic algorithmic, instead, should wonder why every Google service is so fast.

> Those people complaining about Google caring so much about their engineers being able to deal with basic algorithmic, instead, should wonder why every Google service is so fast.

I imagine it has little to do with algorithms and everything to do with infrastructure. Most Google services (and even outside of Google - most services, websites, mobile applications, etc) are simple store data/retrieve data services. When it comes down to the source, fast data access is thanks to the database, and very few developers develop database systems.

Data in the magnitude that Google, Amazon, and Facebook handle doesn't work in standard databases. They have to develop their own data stores to manage it. Check out AWS's offerings, there's a lot of special-purpose services there.

That's great, but we're talking about a very small fraction of engineers who write DB systems. I have used some of AWS's DB offerings, and I didn't have to write complex algorithms to do it.

A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever.

I'd only partially agree with this.

One of these things is not like the others: HTML and CSS are not programming languages; JavaScript is, and we're treating it like one now. As we move into a world of "client side applications" rather than "dynamic HTML," JS can be an order of magnitude more complex than it was just a few years ago. If you're going to use Angular or Backbone well, you're going to need to have a solid understanding of at least a few design patterns. You're probably going to need to know the difference between a queue and a stack and when you'd use one or the other (or neither), and you're going to need to be able to look at a problem and say "this is something I need recursion for." There's an awful lot of people who could make a good living as a web developer in 2004 who couldn't in 2014.

Having said all that, I think the current hiring process, particularly among Facebooks and Googles and startups that emulate them, is pretty heavily biased toward things one only learns in computer science degree programs (or when one is desperately floundering around trying to solve a "take home" interview puzzle). I don't want to claim that it's bad to know how to do directed graph cycle detection in your language of choice, but the need to do that is only going to come up in fairly specific circumstances -- and it's more important to know that someone you're hiring can find the information necessary to solve a problem and apply it than it is to know whether or not they have that information memorized.

(I'd also argue that demonstrating they can write readable, well-documented code that other people can actually work on is really important, but I almost never see that tested, oddly enough.)

>> However, what does not make sense to me is the asinine requirement that a web developer needs to know or understand algorithms. A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm. In my 12 years as a developer thus far I have never needed to solve a complex math problem or write an algorithm to markup some HTML, the closest I get to math problems is simplistic operations in Javascript like calculating the scroll distance from the top of a page or mathematically moving an element around the page in a particular way and I generally use a calculator for these problems.

Perhaps some folks want to automate your job. That's not to say you're obsolete, just that some people want the machine to do absolutely everything automatically and that often means algorithmically. That's probably more effort than its worth in many cases, but sometimes it's well worth it.

A facebook feed or Google news have a fairly consistent layout, but what content goes into it is definitely chosen by an algorithm (IMHO a poor one at facebook) and the layout is probably tweaked by algorithms.

New web frameworks are making web development a more difficult problem, and Google's biasing of their hiring process towards "puzzle-solvers" has given birth to the poster-child of such complexity: AngularJS. AngularJS takes web development from something inelegant but simple into something inelegant and convoluted. I miss the days when web developers didn't need to add "transclusion," "directives", and "providers" into their vocabulary.

The only problem is companies who think web frameworks are obligatory. (And that sites not using them are somehow not as desirable.)

RegEx is just ludicrous a general requirement to "program" as anything else. I've never particularly wanted it to write the mathematical models I work with. I can think of just a single instance where I've used one in the last year and that was to display integers as ordinal numbers (hardly a sizeable task).

Every job needs a spec. Every spec should inform the interviewer and the interviewee of the skills and competencies expected by the role, and therefore what will be brought up in the interview. Adding "everyone should be able to criteria unrelated to role" is madness

Agreed. I can write a regex the (very) few times I need one, but it generally entails me looking up a cheat sheet to get the appropriate character classes. If you were to put me in front of a whiteboard I would flub the most simple of tasks (from the original post, "{(.*)}", I think? Did we mean to include whitespace, and does . translate properly? Because that's partly language dependent when it comes to white space, newlines, etc, and how the regex parser works. Did we mean to capture empty cases? Did we intend for it to be greedy?).

Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.

Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.

EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.

Start using regex in your text searches while programming. It will make you more productive (especially when you start using it with search-and-replace) and you'll learn regex properly. Please don't parrot that Jeff-Atwood-nonsense.

EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor.

For example, suppose I want to write a bit of repetitive code like this:

    x = x + vx * t + ax * t * t / 2;
    y = y + vy * t + ay * t * t / 2;
    z = z + vz * t + az * t * t / 2;

If you just copy-paste the first line and change all of the x's to y's and z's, you're extremely likely to make a mistake. There has been study in this and it's one of the most common classes of logic error.

However, with regex search and replace, I first type

    x
    y
    z

Search with the pattern: (\w)

And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;

And now that I've been doing it for a little while, it's second nature. It's how I write lots of code.

I do, if it will actually save me something. Usually, I don't need anything that actually requires me looking up or constructing a super complicated regular expression.

Per your example, I code in a functional language. I'm even less likely to make a mistake if I just reuse the function, than I am to apply a regex.

You don't have to look up how to use regex if you know how to use regex. If you just learn how to use the tool already--which isn't very hard, the syntax is quite limited and the salient points are nearly universal between all regex engines--then the stuff isn't "complex". It's as complex as C or Javascript or Scheme was on your first day of learning it. Less so, because there is less to learn.

The example is arbitrary. The point is, sometimes you end up writing repetitive code. Yes, even in functional languages.

Clarification: I know how they work. What I -don't- bother keep in my head, is every metacharacter, character class (POSIX especially), assertions, string replacement options, etc, because I can just look those up. The example mentioned above is actually a really good case of why I don't worry about remembering all the specifics; because it's really easy to screw it up. Oh, I forgot {} were special characters, because I have -never- used them (any time I needed repetition it was always so few times, and for a single character class, I just repeated the character in the pattern), so I forgot to escape them.

And let's not forget the implementation different specifics (the need to specify multiline matching as a separate parameter into the parser, \ vs $ for string replacement, etc)

In general, if I'm writing a regex more complicated then "Hey, does this string match this literal?" I'm going to pull up a cheat sheet, because it avoids issues like that. But the number of times it makes sense to do that is really, really low.

It makes as much sense to me to say you should remember all ASCII character codes. Why? If you know how they work, and you're not using them enough to remember all of them automatically, it's not really a problem to just look them up if/when you need them.

I would agree that the minimum requirement should only include relevant data. However, you never know when a skill might be handy (especially if you don't have that skill), and having a broad base seems like it would be beneficial as well. Perhaps allow for people to demonstrate their bonus competencies, and strive for a diversity of auxiliary skills across teams?

Interestingly, my father, who is an applied mathematician, recently requested my help to understand regex and their relation to NFAs to help him with a mathematically related programming task.

I'd argue that being able to think laterally across multiple parts of the web browser is much more important for front-end development than having the typical CS background (algos, data structures, etc).

But the CS background certainly doesn't hurt. Especially when it comes to stepping back and figuring out how to do the same stuff with less code (i.e. making good architectural decisions and finding the right frameworks for the job), instead of diving straight in and producing a giant mess of code, which is quite easy to do on the front-end if you're not careful. (Especially if you throw JQuery in the mix -- at that point you have a hearty soup of DOM manipulation code.)

Normal companies shouldn't hire this way. They're trying to find the one in ten thousand genius. Most companies don't need to.

If I were hiring a developer I'd ask them to write a simple app. Then I'd ask them to explain in as much detail as possible as to what happens when you type www.google.com in your address bar and the google homepage showing up.

I expect them to mention DNS lookups , IP Addresses , HTTP Requests , HTML parsing , HTTP methods etc

A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm.

For the kind of frontend work you're used to doing: perhaps they won't.

For the kind of frontend work Google does -- you know, things like Gmail, Google Maps -- they most definitely will.

That's why Google asks those questions.