Coding Interview Preparation in JavaScript

https://www.educative.io/collection/page/6630002/190001/270001

by fahimulhaq • 10 years ago

159 88 10 years ago

educative.io

belzebub2• 10 years ago

Site is down unfortunately.

Edit: In safari, javascript error in web inspector ironically.

fahimulhaq4• 10 years ago

Hi belzebub, Co-founder here. Can you send me more details at fahim {-at-} educative.io?

softawre2• 10 years ago

Down for me too, just run the app in mobile safari. Works on Firefox OSX.

jlas• 10 years ago

Turns out getting a production site up and working has little to do with finding the k-th permutation...

polishninja• 10 years ago

I laughed out loud at this one after reading all the serious, in-depth posts above.

mycroft-holmes2• 10 years ago

The sample problems are...well let's just say if every dev I work with had to solve those problems on the spot right now, there'd be no developers in the office tomorrow. And guess what? We still push code. Our application is still being built.

It's problems like that which terrify newbies.

jordache2• 10 years ago

agreed.. hate these algorithmic questions... very applicable if you just finished taking a comp sci midterm.

I would venture to say there are a small set of positions where you'd use these exact skills on a fairly frequent basis.

mycroft-holmes2• 10 years ago

Exactly. I can't tell you the number of positions I've interviewed for with very challenging questions when their entire app is a basic CRUD app. Many views, basic CRUD. Everyone thinks they need the best.

belzebub2• 10 years ago

Which one are you referring to specifically?

softawre2• 10 years ago

Agreed. I have a spot open now and have done ~10 interviews in the past couple months. We do something much easier - "write a function to return whether a string has a balanced number of parenthesis". Essentially a number, +1 for (, -1 for ), return false if <0, return true if 0 at end of loop.

20% of our applicants pass this, and they all go through a phone screen first..

make3• 10 years ago

20%!!!??!?! wtf!

gcheong• 10 years ago

Shouldn't that be return false if != 0?

FilterSweep• 10 years ago

balanced number, or balanced syntactically?

I think it's a fair question..... but "())))(((" would fail in the second condition

throwawayinterv2• 10 years ago

20% is a very suprising number...

Would something like this pass (maybe with some comments and test cases)?

    1 @tailrec
    2 def hasBalancedParens(s:String, open:Int):Boolean = {                                               
    3   if(s.length == 0)           open==0
    4   else if(s.charAt(0) == '(') hasBalancedParens(s.tail, open+1)
    5   else if(s.charAt(0) == ')') open>0 && hasBalancedParens(s.tail, open-1)
    6   else                        hasBalancedParens(s.tail, open)
    7 };

Or should line 5 halt the loop? What if line 4 did not contain open>0 at all?

If this answer fails (modulo any stupid mistakes; idk if it even compiles), you might consider being much more specific about the desired average runtime complexity.

If this answer passes but would fail if line 4 was modified, you might consider re-writing your problem text to include either "Feel free to ask for clarifications" or "A string has balanced parentheses only if every closing parenthesis is preceded by an opening parenthesis". People tend to not treat interviews like normal interactions, and interview questions don't have a surrounding context so it's hard to determine what it means for an answer to be correct.

aiokos• 10 years ago

Is it 20% to generate something like this, which balances parentheses without syntax? If so that is seriously surprising.

  function getBalance (parenStr) {
      var count = 0;
      for (var i = 0; i < parenStr.length; i++) {
          if (parenStr[i] === '(') { count++; }
          else if (parenStr[i] === ')') { count--; }
      }
      return count === 0;
  }

Chefkoochooloo• 10 years ago

This is what is so intriguing to me about education. We all go to school and learn about problems like these, but we retain so little information without brushing the dust off of our old Comp classes and review the material.

jordache2• 10 years ago

maybe we learned how painful those were and solution our ways around to needing them? :)

nawitus• 10 years ago

I would love to implement more algorithms at my job, but it's a really rare occurrence. Mostly it's just CRUD, gluing stuff together and making tech choices.

GoToRO• 10 years ago

it's quite simple actually: football players train by doing all kinds of crazy exercises, none of which you will see in an actual match. But this is what training is. You won't hear a football player say "why do I have to do push-ups? I've played 1000 matches and never, not even once, did I need to do a push-up!". School is training too, it makes your brain stronger.

School is also a filter for future scientists.

In my country school was always about learning the fundamentals. What you will actually do on the job you will learn... on the job. Nowadays there are more and more voices asking for more practical classes but I feel this is risky: if you know the fundamentals you can quickly adapt. If you only learn how to do one practical thing you will have to retrain when that thing becomes obsolete.

csallen• 10 years ago

That assumes that the fundamentals you're learning are relevant to your job. Pushups are relevant to football players, because they help build and maintain the same muscles that players use in matches. Could you say the same about a UX engineer learning how to clone a directed graph? I think not.

The problem is that we tend to lump all programmers together by assuming they should all know the same things. The reality, however, is that there are different kinds of programmers who need to be proficient at different skills. Wide receivers, quarterbacks, kickers, and linebackers all have different coaches, diets, and training regimens for a reason.

Companies who realize this and incorporate this into their hiring will be at an advantage. Companies who don't will be at a disadvantage (unless they are so hot that they get 100s of resumes from over-qualified applicants every day, in which case it doesn't particularly matter what they do).

jbob2000• 10 years ago

So today I had to implement the XDomainRequest API to support IE9 for one of our features. Yesterday I worked on a branch to upgrade our front end framework to a newer version. The day before that I was refactoring out our old API from an older module. Last week I was working through a specification document from our product team to implement a new interface.

Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers? or clone a directed graph? If someone presented me with these questions in an interview, I would be tempted to leave.

And in reflecting on my job as a coder, I find that most of the work I do is janitorial; clean this up, add support for this, fix this, talk with product about this, break this up into smaller pieces... Never once have I had to implement a feature that would require these types of algorithms. Like 98% of my challenges are "this needs to work this way, but that needs to work that way, how can we make them work together?".

I'm not picking at educative.io per se, they're just a symptom. It just really sucks that there are some companies out that believe that if you can rattle off an algorithm, then you must be a good coder.

nothrabannosir• 10 years ago

Not defending the interview, but:

It just really sucks that there are some companies out that believe that if you can rattle off an algorithm, then you must be a good coder.

The implication is (not able to do X) → (not a good coder), not the other way around.

They imply: "Doing this esoteric mathematical stuff is a requirement for being a good coder. And there are more requirements."

EDIT: strictly speaking, they don't even imply that. It may be they just consider this one of the many possible signals. Maybe they only count it if you pass.

Again, most cases may actually well be as you describe. But some might not be.

marsinvasion• 10 years ago

I remember an interview where I was asked to solve an algorithm from my college days. In the 10 years out of college, I've never needed it and to remember how to solve it during a timed interview seems completely unreasonable.

krapp• 10 years ago

I'm pretty sure filters like this exist in part to implicitly reject candidates old enough to have forgotten their CS curriculum.

jamespitts• 10 years ago

It is true, the algorithms may not seem critical day-to-day.

Barriers to entry like the coding interview or ivyness of education often fail to identify the best candidates, reinforce monoculture, and could even indirectly support ageism, racism, and classism. But they persist because arbitrary barriers serve an important purpose in the minds of interviewers.

For example, many organizations may be hiring largely on experience and instinct, with the coding interview serving as confirmation or as a premise to reject.

dexwiz3• 10 years ago

I am a self taught developer in my first real job doing it. There seems to be two types of programming: magic algorithm programming, and API programming.

Most job prep seems to focus on algorithms. The algorithms are easy to test, because there are clean metrics (does it work or not, efficiency, etc). Also they make people feel clever. Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell (sorry fanboys, its esoteric when its less than 1% on TIOBE). But most programs/apps/services may only implement one of these at their core. If you are building a database or search engine, you will run into these more often, but its limited for most people. CS seems to focus much more on this side of programming.

The second form of programming is API programming, and I use this every day. This includes both finding the right function to use (or close enough) or creating API functions with sane parameters and results. This is much less glamorous, and is theoretically covered by "read the manual." But it is much more nuanced than that. Parameters may not be named the same thing or have the same form between APIs. Handling sync for async function calls are important. Hell, even defining the problem before finding a function for it can be difficult. APIs are the meat of programming. Designing and using them is definitely a required skill.

Being self taught, I learned much more about APIs than algorithms. I am not bad at Math, got a minor in it, but some of the algorithms blow my mind. But I am glad I learned APIs, as I use them every day. If I need to deep copy a map, I use a function.

whorleater• 10 years ago

You're treating CS like its composed of two different divides ("algorithm programming" and "API programming"), when in fact I think you're forgetting that algorithms can be used as the proper foundation for API programming. Handeling asynchronous calls in the proper manner (as per your example) is extremely similar to the consesus algorithm I learned in my distributed computing class. I doubt I'll explicitly be asked to implement a meldable priority queue like my professor assigned in algorithms class, but is the process of designing an algorithm and its implementation to conform to a specific requirement any different from "defining the problem before finding a function"?

vijayr• 10 years ago

There is also a third type - "find what this code does (sorry no documentation or comments), then fix this specific bug (or make this specific change), without breaking anything else" programming. A lot of people who work in well established product/websites etc do this type of work most of the time. Few lucky ones get to build something from scratch, which would fall under API programming I suppose.

tome• 10 years ago

Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell

Actually I'd say Lisp and Haskell programmers are much more likely to be "find the right function" programmers.

agumonkey• 10 years ago

Interesting insight. I'm stuck in an abstraction learning phase because I feel unemployable if I cannot do the kind of algorithms you mentioned. A large misalignment it seems.

_greim_• 10 years ago

Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers?

People who don't know algorithms and data structures tend not to see them where they exist, so it becomes a subjectively self-fulfilling prophecy. You may not need to clone a graph in your day to day work, but seeing graphs where graphs exist can lead you to better solutions in a way that might seem "magical" to others. Even if it isn't too significant, that small edge can make a difference sometimes. Employers rightly want that.

bmj• 10 years ago

I don't know what your experience is, but given what other folks have shared here, it seems that those with 10+ years of experience in the industry, doing mostly "API programming," have said "I don't use this sort of knowledge day-to-day." I have nearly fifteen years in the industry. I am also entirely self-taught, and have never done any in-depth study on algorithms and data structures. There have been a few times that my lack of knowledge was limiting (and most of those times involved complex queries), but those times are few and far between.

But, you are correct: "a small edge can make a difference sometimes." To some employers that matters. To others? Maybe not so much. Maybe they are happy with a few folks that can deal with the algorithm issues, while the rest of team cranks out APIs and fixes bugs and supports old products.

foobaz1982731• 10 years ago

Posting this under a throwaway so that people at my existing job do not recognize the account.

Completely agree, and you might even learn something during the interview, especially if you were previously the "API" programmer group. I'm entirely self-taught, so I will readily admit that my algorithms and data-structures knowledge is not where I feel it should be.

I did an interview somewhat recently where we talked about a problem that required the use of a data-structure that I had literally read about in preparation for said interview two days earlier, but did not really understand a solid use case for it. As we discussed the problem that was presented, I ended up arriving at the correct solution and everything was happy, but that's not the cool part. The cool part was that as a result of that conversation, all of the sudden the use for that data-structure "clicked", and an entire class of problems suddenly became obvious in how to optimally solve. I will actually be using that exact solution in a side project that's in the planning phase

I haven't done the on-site interview yet, but regardless of whether or not I get an offer (or even accept the offer if one is made), I know that I'm going to walk away from this interview a better engineer for having learned about these algorithms and data-structures just to interview.

Looking back at that phone interview, I wonder just how many other problems I've encountered and solved that would've been better served if I knew more about algorithms and data structures.

ubernostrum2• 10 years ago

Employers rightly want that.

No they don't. Employers heard that Google asks questions like these, and Google is worth eleventy skrillion dollars, so if we ask the questions Google asks we'll be worth eleventy skrillion dollars too!

In much the same way, last decade everybody knew Microsoft asked riddles, and Microsoft was worth more money than anyone could imagine, so obviously asking riddles is the way to end up worth more money than anyone can imagine.

It's basically this comic, but implemented in tech interviews instead of in schooling:

http://smbc-comics.com/index.php?id=3978

Meanwhile the only reason these things seem to "work" for Google et al. is that they get so many applicants they can afford to turn down huge numbers of perfectly intelligent, perfectly-qualified people who might not do so well on an algorithms pop quiz. And at the same time they've made the process easy to game: you can literally get books of Google-style interview questions, study them, and then pass tech interviews without the underlying knowledge/experience the questions are allegedly selecting for.

I just wonder which company will be the next big breakout hit and what irrelevant thing they'll do in interviews that everyone will hurry to nod their heads and sagely agree with as a great indicator of the kinds of things "employers want".

dclowd99013• 10 years ago

Fucking bullshit.

I will freely admit my algo knowledge isn't where it needs to be. But I know an algorithm's need where I see one, and consistently. The problems always contain a very specific problem space:

1) sorting

2) Large tables of information

3) categorizing

In nearly every case, the appropriate, well researched, proofed, Ph.D approved answer is a quick google away. If you're asking algorithm questions in your interviews, all you're looking for is someone's ability to conjure from memory an appropriate approach. Congratulations, you hired a flash card.

You know who I want to hire? Someone who shows creativity and drive through their experience (usually surfaces as having their hands in a lot of disciplines both CS and non), and someone who learns quickly. If they can implement an algorithm (not needing to conjure it on the spot), that's all I need. By the way, no self respecting algo researcher/analyst sits down for 45 minutes to come to a correct and efficient solution to an algorithm problem.

Enjoy your grad students. I'll take a maker any day.

skwosh• 10 years ago

Where, in any of my day-to-day job duties, ...

Off the top of my head, or at least where I've used them recently:

kth permutation of a set of numbers?

Producing all pairs of a collection, e.g. for computing the minimum distance between elements (via map/reduce).

clone a directed graph

Any object in an OO language (like JavaScript) is essentially a directed graph, so, cloning one of those.

vegabook• 10 years ago

earth to JS junkies: the gold rush is over. The new no-growth market is going to parse the coder community with much greater scrutiny in the future. Graphic designers passing themselves off as front end coders, game over. From here forward, people who do not have deep algorithmic skills are not going to be able to find work. The lift-all-boats game is over.

cema2• 10 years ago

Oh don't be so gloom, there is still work for everyone, it seems. Whether it's the kind of work one seeks is another matter, but there is plenty of work as long as the standards are set low enough. Which is not bad btw -- imho, if a person starts at a "low" level they have a good chance of growing, versus if they start at a level when they cannot really perform, and as a result can hardly learn. (I am talking about software engineering; other disciplines may be different. And I may be wrong about software engineering too, this is just speculation based on personal observations.)

mrrrgn• 10 years ago

While you can put processes in place to improve code quality (version control, reviews, style guides/linters), there's no simple way to help a person who doesn't understand the underlying structure of software. APIs are great tools, but don't let them lull you into becoming a cargo-cult coder.

barrkel• 10 years ago

Last week I had to implement part of a database archiving mechanism - taking data out of our expensive SAN and putting it onto inexpensive RAID. To make it more maintainable and reduce the risk of forgetting to archive things, it's fairly generic.

It knows what it needs to extract, but when it's done, it needs to delete rows from the DB. Naturally, we use foreign keys; and we're not turning those off, because we don't want to risk losing data. That means we need to walk the foreign key graph of the schema for all tables who have rows scheduled for deletion, determining a partial order for the graph so we can delete in the correct order.

Graph walking, partial orders - basic discrete math - and practical tasks in everyday programming.

Last month, I was implementing a filtering mechanism for our result tables. That involved converting a predicate created by auto-filter style dropdowns into SQL, in an efficient way, analyzing the predicate to determine which tables needed to be joined to solve the problem. Recursive parsing of JSON, expression tree walking, elementary code generation - basic compiler theory, and not that unusal a task in everyday programming.

Seems like every bit of work I do beyond a very basic level of functionality involves a bunch of computer science fundamentals. Why shouldn't I screen for this in interviews?

a-saleh2• 10 years ago

or clone a directed graph?

I have had some need for this, while implementing tool for populating our database with test data :) But I have to admit that I went out of my way to snag that task, because I really wanted to utilize a non-trivial graphing algorithm one-day at my work.

ignoramous• 10 years ago

In the immortal words of Niklaus Wirth, "Algorthims + Data Structures = Programs".

I agree to an extent that programming interviews are bad at filtering out candidates, but to an extent knowledge of data structures and algorithms go a long way in defining an ability of a programmer to solve the problems (often faced when dealing with systems like Databases, Operating Systems, Build Tools, Compilers) at hand in a reasonable way. One might not realise but knowing CS Fundamentals helps in orthogonal ways. Of course, coding is just a small part of software engineering-- there's design, planning, team work, testing, infrastructure and seemingly endless list of things to care about.

I think a better judge of a programmer is really in "projects" they've accomplished. The ability to get done is so much important, I cannot emphasize more. Some companies, like Google, do try to identify and hire people based on their contributions to open-source and participation in projects of interest. Whereas, others, such as Stripe, have a very different kind of an interview process altogether (take home assignments, pair programming, presentations etc).

hibikir2• 10 years ago

Good programmers don't need to have 300 algorithms memorized: They need to know if what they are running is computationally expensive, and to e able to go look up an algorithm that might optimize the problem. I don't need to be able to whip up a red black tree implementation: But if I know I could use a tree, and the tree is going to be modified enough that self balancing is important, I can go look for a self balancing tree.

A realistic example was when we were working on speeding up some chart rendering, and we realized that we were wasting a lot of time attempting to render things that were not visible on the screen. We saw it was too slow, and then thought: Is there something out there for occlusion culling? We looked at videogame literature, found quadtrees, and wrote our implementation. But would it make any sense to ask any interviewee about their knowledge of quadtrees? It'd be unfair, as none of us would have passed that interview in the first place.

ChemicalWarfare• 10 years ago

I've been in IT for about 20 years - all kinds of roles with the lowest common denominator being is that I stayed "hands on".

Never in my career did I have to do any of the things some of the "interview prep" material out there is geared towards (even though I understand this is supply and demand as some companies are notorious for this CS exam type line of questioning).

That's not to say that I didn't have to deal with algorithms - things like strategies for cache cold starting and invalidation, custom encryption, high volume batch tokenization of sensitive information etc etc.

The thing is - every time I faced a task that would require a reasonably involved algorithmic approach I would do research, prototype the solution, functional/perf test different approaches etc etc.

For that reason I would take someone who can outline these steps for me preferably with the tools/frameworks involved over someone who happened to remember a specific CS algorithm I asked them about. And if they can tell me how they would go about automating their testing, how they would react to unexpected events like message delivery mechanism failures that would be even better :)

MaybiusStrip• 10 years ago

A tech screen is a just that. It's not meant to accurately reflect the problems you work on, it's meant to see whether you can actually write code, whether you can explain your reasoning, and just generally how you react to a problem that requires some level of abstract reasoning. It's a way of filtering out candidates. At most companies, that's 30 minutes out of the 5 hours of interviews you're going to go through.

Cloning a directed graph seems like a perfectly reasonable interview question. It requires no specialized knowledge, just being able to navigate a fairly common data structure. I can't imagine a competent programmer not being to solve that problem on a whiteboard, which is precisely the point.

iamflimflam1• 10 years ago

I don't think I'd ever ask these algorithm questions in an interview. Much better to sit down with a candidate and do some pair programmer. Add some unit tests to some code, add some small new features. Can they grok an existing code base easily. Do they understand why we are writing unit tests. Etc..

fapjacks2• 10 years ago

I interview for fun as a habit, and pair programming is definitely my favorite kind of interviewing. Like I still get nervous even for interviews I have no intention of following up on, but a lot of those butterflies go away when they mention there will be pair programming. It's just more fun, I get to meet a specific engineer at their company, and I feel like they get their answer way better than if they'd used another technique. Answer as in "is this dude who we're looking for?".

reledi• 10 years ago

What do you mean you interview for fun as a habit?

truncate• 10 years ago

I would love these kind of interviews to happen, but it comes to this question - does the interviewer or the candidate is willing to spend this much time? I'm in university, and it would be hectic to give every interview this way.

I see this work better with non-entry level positions, assuming candidates apply to fewer companies and companies have fewer candidates to interview.

joeax• 10 years ago

My two cents, but for these algorithmic questions the language shouldn't matter. Are you hiring someone deeply proficient in data structures and algorithmic programming? Then let them solve it in their language of choice.

If the role is JavaScript-centric, how about a question specific to the language like Describe the difference between var and let, and when you would use one over the other?

z3t4• 10 years ago

Permutations are more a IQ test. The closest we have in JS is implementing a "marquee tag".

Traversing JSON, or cloning an object or array is actually somewhat common. But I find it funny that the solution is to make a Class, having a "for in" loop, and variable declarations in a loop. It's clear that the one who made that solution has never done any serious JS coding silly smile

I could make another rant about making a new Class for each problem. You want to write code that is easily removed, not complexed!

Coding Interview Preparation in JavaScript

Related Stories