
Coding Interview Preparation in JavaScript - fahimulhaq
https://www.educative.io/collection/page/6630002/190001/270001
======
jbob2000
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.

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

~~~
ubernostrum
_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](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".

~~~
pkaye
I'd like to hear how you interview candidates and what has been your success?
The process could certainly be improved since we have very little time to
really know the candidates.

~~~
abustamam
Not parent but my current employer has an interview process that I find fairly
efficient.

During the hour-and-a-half or so of interview, I was asked to do a few things:

1\. explain my technical background, projects I've worked on 2\. explain one
project in depth, from entry-point to client 3\. discuss future features of
that project 4\. let me implement one feature in that list while they go have
some coffee 5\. show off my new feature!

Even though the technology I used was not the technology they use, I think my
employer wanted to see how well I communicate technically, how well I
understand, and how fast I can put things together. He seemed to like the fact
that I had a lot of failed iterations and Googled to get through snags.

Another interview process I was quite fond of had me working on one of _their_
pet projects; looking through their code base, identifying possible
improvements/features, and implementing those improvements in a new git
branch.

Of course, that process may not work with EVERY technical interview, but my
bet is that practical interviews like these are more likely to show an
employee's technical prowess than a person simply memorizing algorithms. While
I agree that there is a place for algorithms, it should not be the focus of an
interview.

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

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

~~~
FilterSweep
balanced number, or balanced syntactically?

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

~~~
wdmeldon
I think merely asking this question would be qualification enough.

~~~
throwawayinterv
As I suggested in another comment, it might be in general bad advice to try to
get people to ask clairfying questions about non-contextual interview
problems. If you want to measure social adeptness / willingness to ask for
clarification -- which are important! -- consider interview questions that
have a "role playing" component or actively invite the interviewee to ask
questions.

~~~
cema
In my experience, clarifying questions are important. In this case, for
instance, we have two different problems (well, not too different, but still).

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

~~~
fapjacks
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
What do you mean you interview for fun as a habit?

~~~
fapjacks
I started "practicing" my interview skills a few years ago by... interviewing
with companies. Interviewing is great for keeping your skills fresh, for
learning new things, and for meeting cool people working on cool projects.
It's a lot of fun! And it has the added benefit of giving you opportunities at
new companies, if you end up finding a better position than the one you're in.
Just keep it on the DL from management at your current company. For some
reason, they don't like it when employees do that.

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

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

------
joeax
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
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!

------
belzebub
Site is down unfortunately.

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

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

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

