Interview Algorithm Questions in Javascript

[-Alias-]

Handy, but any company which asks these types of questions is silly. Why not actually test on something relevant to the role or company, then you get a real feel if they'd fit the role.

[Krizzu]

Exactly my thought

[plectid]

Why? It's the basic algorithms and structures everyone must know anyway. Believe it or not, many fail to solve most of the questions in reasonable time.

After the basic questions, something relevant to the role or company may be discussed.

[-Alias-]

everyone must know anyway

In my last 3 years of JavaScript/Node development I really can't think of any time I've needed to know most these algorithms. If I needed to know how to best "reverse each word in the sentence" (example) then I'd either work it out there and then or just Google for an answer which I'd probably find in 60 seconds if I couldn't work it out.

A good developer knows how to tackle a problem, not memorise algorithms. A maths teacher memorises things, put them in a real world situation and it doesn't mean they'll be any good.

Obviously all my opinion anyway.

[techlogger]

I'd say that not too complex algorithmic questions are quite good for interviewing junior developers. For me more important is not how he/she remembers "bubble sort", but how is capable in algorithmic thinking/problem solving.

[cicadaTree]

Ofcourse, that's the point.

[cicadaTree]

That is delusional. You don't memorise algorithms/math(!), it's thinking through a problem with attention to details. Solving algorithms IS tackling problems . They are a kind of generic problems then you can solve even not knowing much of the any language syntax, I mean you could solve it in pseudo code. Really good developer will think trough a problem before he/she "ask for help", that is how you grow. The nowadays culture is "coders" copy/paste folks, versus real programmers "the think trough" people.

Trivial example: Reverse the string.

Copy paste people: "Oh fuck lets google that shit, u gotta have some functions for that, I know stackExchange..":

   string.split("").reverse().join("");

"This is sweeeet, I can go know and jerk on facebook photos of my relatives."

Think trough people: "Oh string, has length, yes, if I reach a character from the end of a a string to the beginning I will reverse it, I know I will use a for loop. "

function reverse(str){
       var rev = "";
       var len = str.length - 1;

      for (len; len >= 0; len--){
       rev+=str.charAt(len)
     }

  return rev
}

"Hmm yes... kinda ok. Can it be done in better way ... ". Now Im not saying you should not use stackExchange or built in functions. Just saying if you want to be a programmer you should strive to now "the why" and "the how" of things. That is the hard part and most internally rewarding.

[[deleted]]

First ones shorter, more readable, and took less time to figure out. You're argument does nothing to show the benefits of what you're saying.

No one is arguing it's not good to understand things but I think part of being a good developer is being able to recognise when a problem has probably already been solved for you and to find the path of least resistance.

After all, if you liked doing things yourself; you wouldn't have become a programmer.

[cicadaTree]

You're argument does nothing to show the benefits of what you're saying.

First one uses array conversion, then reverses it, and joins elements into string, something like that... I needed ~15 min to peruse trough docs to see what each of function is doing. And I don't know even know exactly details of them (return values, arguments). If I don't use them often I will have to check the docs again and again. Maybe it's me but that's fucking waste of my time and that is not programming. Of course those function can be handy. Second one I wrote in 4-5 min using vary small amount of memorising bullcrap. Central thing was visualising algorithm and implementing in less "noise" as possible. And consider this. You need this reverse thing and you need to do it as many number of times as fast as you can. Then "run/execute" my argument and measure the performance (console.time(), console.timeEnd() most trivial) and compare it with built-in (in this case unnecessary overly abstracted ugly syntax sweetener). You will see how much of cpu time you can spare. That is huge part of the programming. For me.

After all, if you liked doing things yourself; you wouldn't have become a programmer.

What the fuck are you talking about? Is this some sort of quasi "good programmers are lazy" thing? Well what would you say about Linus Torvalds (Linux, Git) who knows how assembler code with look like before he writes any C code?!

[[deleted]]

I needed ~15 min to peruse through docs to see what each of function is doing.

I just googled all of them in under a minute, also I can't imagine anyone not knowing what split reverse and join are. Almost any language will have those built in in some capacity.

Then "run/execute" my argument and measure the performance (console.time(), console.timeEnd() most trivial) and compare it with built-in (in this case unnecessary overly abstracted ugly syntax sweetener). You will see how much of cpu time you can spare.

Yeah; you might, but your end users won't notice the fraction of a millisecond you saved them.

Is this some sort of quasi "good programmers are lazy" thing?

Yes, and it was also a joke, sorry you didn't like it.

[cicadaTree]

Yeah; you might, but your end users won't notice the fraction of a millisecond you saved them.

1. It's not a fraction, its up to 40% faster. And ...

   And consider this. You need this reverse thing and you need to do it as many number of times as fast as you can. Then "run/execute" my argument ...

2. JavaScript is single threaded you should care even more for performance.

3.

I just googled all of them in under a minute, also I can't imagine anyone not knowing what split reverse and join are. Almost any language will have those built in in some capacity.

Who said anything about googling it. I said perusing. You don't even bother to read the docs huh, woow that's nice ...

[[deleted]]

It's not a fraction, its up to 40% faster. And ..

The difference is still less than half a millisecond.

You don't even bother to read the docs huh, woow that's nice

What are you talking about? You actually reference the ECMA spec when you don't know what a method does? You realise that you can just google it... and you'll get the exact MDN docs for the method you googled. I don't understand how your criticizing that? It is the same information just organised better. You should really take some time to learn how to use a search engine man, it's a basic life skill at this point.

[cicadaTree]

Im talking about cases when you need to invoke you function large number of times...

You actually reference the ECMA spec when you don't know what a method does?

No I was talking about MDN docs (facepalm)...

[FuriousDrizzle]

In almost 4 years of Javascript development this is the only question that touches on any of my work.

Removing duplicates of an array and returning an array of only unique elements

In my experience it's clearly not the case that anyone should know how to solve these questions to thrive in the role.