DEV Community

Kristian Ivanov
Kristian Ivanov

Posted on • Originally published at hackernoon.com on

Why most Front End Dev interviews (#JavaScript #Typescript) are Shit

image used from http://blog.debugme.eu

I am sorry I din’t censored shit, but shit pretty much === s**t and everyone would know what I mean either way.

First of all a bit of a back story

I am changing my job ( wohoo for me and ohno for my team). I was dev, I became a TL, we were a dev team, then we became game team (dev, interface and animation) a while ago, then I decided to quit (if you want to know why, feel free to ask, it is npt the point of the article). A friend of mine, works in a company that works the same field as my current company and wouldn’t stop bothering me until I gave their company a shot. His company however was looking for a senior game/front end dev. Considering that I have worked at my current company for nearly 6 years, I decided to give a shot, if only to see firsthand how the current market for developers was, outside of my company.

Second

both companies should, in my opinion, stay unnamed. Just assume they are generic companies.

Third

Lets call them interview problems, seen from TL and dev perspective, when a TL tries a dev interview. It may sound weird or strange, but it is a nice perspective of a guy that has made interviews with devs in a company and the same guy trying an interview as a dev in another company.

Fourth

I will split this into two parts. You will know why in a bit.

Fourth point one – human parts

The interview was first conducted with the person, which represents the dev team and their manager. Their manager, of course focused on my career, what I have done, how much (as a percentage) did my job as a TL allowed me to write code, with what IDEs did I write my code, what were my side projects, why did I wrote them in those programming languages and so on. It was pretty understandable. However, I expected more of their dev TL. He had two questions, for about of an hour of interview. Question one – have you used Gulp; and question two – what is your approach in learning new technology or new API or new framework, etc.

Apparently I did good enough impression to be asked to make a test at the company. I wasn’t sure whether or not it was the psychological test, the test to be sure how much info I will be allowed to know and not leek outside, or the tech test. I went there, talk with their manager. He was a pretty nice guy with understanding, reasonable motives and so on. I found out it was the technical test that I was about to do. Which was OK, it isn’t like I was going to study for it anyway. The following are my impressions of the test.

Fourth point two – test

Disappointment one

It is only the test. You don’t talk with devs, their team lead, an architect or anyone else. It. Is. Just. The. Test.

Disappointment two – the test itself

These aren’t typos or writing mistakes. Everything is written as it was in the test.

The test is a three pages piece. It is spitted in Java Script, Node.js & Gulp, TypeScript.

Now to the questions. Some are omitted in order to avoid repetition.

Questions about JavasScript

  1. What is a potential pitfall with using typeof bar === ‘object’ to determine if bar is an object? how can this pitfall be avoided? Answer: Welcome to 2015–6 questions on forums. It is a reliable way, but typeof bar === ‘object’ returns true. Keep it in mind. You will rarely (never) use it a t work, but it is apparently a very common JS question for interview and tests.
  2. What is NaN? What is its type? How can you reliably test if a value is equal to NaN? Answer: Again with the obvious old questions. NaN stand for Not A Number.It’s type however is number, because JavaScript is JavaScript. If you want to test if something is NaN, JavaScript has isNan method to do so. It is not intuitive or very common to use it, but it exists.
  3. In what order will the numbers 1–4 be logged to the console when the code below is executed? why?
(function(){
    console.log(1);
    setTimeout( function(){ console.log(2)}, 1000);
    setTimeout( function(){ console.log(3)}, 0 );
    console.log( 4 );
})();
Enter fullscreen mode Exit fullscreen mode

The answer again is old. A variant of it can be found here with nice explanations.

Basically – the browser interpreting the function will go like this:

I have to write 1

I have to write 2 in a while

I have to write 3 in while. The fact the timeout is set with 0ms doesn’t matter. If you have used JS event base management with setTimeout(0) you will know when to use this tremendously ugly fix (don’t ever use it!).

I have to write 4

The function does not return anything so the browser will output “undefined”

I had to write 3 in 0ms, so the “3” is logged

I had to write 2 in a 1000ms, so the “2” is logged.

Your whole answer is – 1,4 undefined, 3, 2

  1. What will the code bellow output? Explain your answer.
console.log( 0.1 + 0.2 );
console.log( 0.1 + 0.2 == 0.3 );
Enter fullscreen mode Exit fullscreen mode

What do you think 0.1 + 0.2 results in JavaScript? 0.3? Hell no! JS is famous for its float arithmetic problems. 0.1 = 0.2 results in 0.30000000000000004 (with more or less zeroes here and there).

So, your answers are: 0.30000000000000004 and  false

  1. What will be the output of the following code:
for( var i = 0; i < 5; i++){
    setTimeout( function(){ console.log( i ); }, i * 1000 );
}
Enter fullscreen mode Exit fullscreen mode

Well, welcome to 2016–7 generic question about JS, setTimeouts and closures. It is the first question in this article. Yes, there are other articles, that summarize what people get asked on JS interview, this one is just a bit more detailed and written from the perspective on someone who made dev interviews, and someone who just went to a dev interview.

I have seen this in so many articles it literally hurts. If anyone has read something about the language at any point he/she can answer without understanding it at all. A lot better question, in my opinion, is this – Explain what a closure is and why would you use it. Give at least 2 examples (one can be a lucky guess)

  1. What would the following code output in the console?
console.log( "0 || 1 = " + (0 || 1 ));
console.log( "1 || 2 = " + (1 || 2 ));
console.log( " 0 && 1 = " + ( 0 && 1 ));
Enter fullscreen mode Exit fullscreen mode

Pretty obvious… I am including it because it didn’t had the usual “please explain why”. If it had it, I would probably write – 1, 1, 0, because that is how || and && work.

  1. What will the following output in the console:
console.log((function f(n){return ((n > 1) ? n * f(n-1) : n)})(10));
Enter fullscreen mode Exit fullscreen mode

Answer: It is pretty obvious function with recursion that calls itself with a simple ternary → 10 * 9 * 8 * 7 * 6 * 5 *4 *3 * 2 *1

I was honestly getting bored at this point.

  1. Make a function ‘sum’ that returns a sum of two values. this function should be called as these examples: console.log( sum( 5, 3 )); //returns 8 console.log( sum(5)(3));// returns 8

Yupee!!! A challenge has come before us! This is awesome! Especially after 8 generic JavaScript questions that people should be able to answer even if they are half brain dead.

Unfortunately it is both a challenge and it is not.

At first glance it is intimidating and it is weird, and I quite actually like it. Unfortunately I have recently read on Medium several articles about currying written by Joel Thomas. They can be seen as a working use here in “Challenge: Program without variables #javascript” and as an explanations here in “Currying in JavaScript ES6”. So the question itself wasn’t very challenging. Of course there are very few people that I know, that are familiar with currying and I know even fewer (0) that have actually used it. Joel Thomas examples and description are tremendously useful and you should read them.

  1. What is “callback hell” and how can it be avoided? Answer: there is a whole websitecallbackhell.com dedicated to this term. To put it in layman’s terms it is when developers write in JavaScript and create a bunch of functions that are triggered by one callback after another. This creates a pretty difficult environment to test and debug the product. If you want to fix it you can do the following things: Keep your code shallow – meaning, keep it small and clean(KISS) Modularize Handle every single error – there is a concept in Node.js called the error first callback. You can read more about it here. This will be mentioned later on as well.

Questions about Node.js & Gulp

Those somehow manage to be even more generic. I don’t know how.

  1. What is Gulp? Anwer: (copied from their webpage) – gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something. Personal answer: I have mainly seen it use as a build base.
  2. Is Gulp base on node.js? Answer: I actually wasn’t quite sure. Is there Gulp in Node.js – Yes. Is there Gulp in other environments – Yes. According to their website – Integrations are built into all major IDEs and people are using gulp with PHP, .NET, Node.js, Java, and other platforms. I will, however, be forced to say yes, because the people that made Gulp explain it as – Use npm modules to do anything you want + over 2000 curated plugins for streaming file transformations. I haven’t actually seen it used for anything JS as well.
  3. What are modules in Node.js?
  4. What is the purpose of the packaje.json file? (Yes, they have written it with a typo like that)
  5. Explain npm in Node.js I will answer the above three as the same question, since they are. First of all what are modules in Node? – they are basically the way libraries, “classes” and so on are represented in Node. Some articles for the topic – w3schools. They (modules) can be written as AMD components and CommonJS components. Amd according to wikipedia. Amd and CommonJS modules comparison from RequireJS can be found in a few sections here. Secondly the packaGe.json file – its documentation can be found here. Roughly, the package.json allows you to specify which libraries a project needs, which libraries versions the project needs and it makes your build/install easily reproducable. As for what npm is, the abbreviation stands for Nodule Package Manager. Is it self explanatory? I believe it is. It is the thing that allows you to publish and use external libraries, update them, save them and manage them for a given project. if you use Node you should take look at the npm list of commands –  install , uninstall , update , ls and its flags – -g, – save, and so on. The npm docs can be found here however the difference between global install or install with – save can be found and memorized mainly trough using it.
  6. What is error-first callback? Answer: I have mentioned it across the callbackhell earlier. It basically means put the error as the first argument of the function, success second.

Questions about TypeScript

  1. How Do You Implement Inheritance in TypeScript? Answer: using the extend keyword. TypeScript has it, JavaScript does as well.
  2. How to Call Base Class Constructor from Child Class in TypeScript? Answer: super() or super( arghs )
  3. What are Modules in TypeScript? Are you bored? I am. The questions are generic and are seen throughout similar articles and questions in StackOverflow and etc. Anwer: A somehow thorough description can be found here. Roughly – they (the modules) are an extended version of the node ones. You can use external and internal modules, effectively creating namespaces.
  4. Which Object Oriented Terms are Supported by TypeScript? Answer: Read it like – what OOP keywords and principles does TypeScript has that JavaScript does not? (classes, interfaces, extending, types, public/private/protected variables) Of course all of those things can be emulated in JS by using object.defineProperty() (of which I am a huge fan), js .extend, jQuery or Zepto extend and fn.extend.
  5. What is tsconfig.json file? Answer: Read it as – have you ever used TypeScript? If not here is your summary – The presence of a tsconfig. json file in a directory indicates that the directory is the root of a TypeScript project. The tsconfig. json file specifies the rootfiles and the compiler options required to compile the project.

Summary

That was it. I realize that there are several articles out there, Medium included, that discuss JS related questions for job interviews. I just decided to share my own recent experience, which is a bit different, since it is from the perspective of both a guy that had interviewed developers and that has been just interviewed as a developer himself.

All of those questions are generic to the point that the whole test took me roughly 20 minutes (reading and writing, by hand on a piece of paper included). If you ask me, I would strongly recommend that companies and TLs and tech guys take those kind of tests, smash them and throw them not in the nearest garbage can, but the one a few blocks away, so there is no chance for someone to see them and connect them to their authors. Putting your company header on the top of each page isn’t necessary as well…

Don’t get me wrong, you can use this test to get someone’s understating tested. But it is in a very narrow way and the questions being generic enough, that I have seen literally 80% of the questions in the last week either on Medium, StakOverflow or another forum, means that someone can answer them quickly without actually understanding them.

So, instead I would prefer to be both interviewed by, and to interview an actual human being, instead of doing a test or read a test. It is a lot easier to talk with someone and ask him some of those questions, followed by clarifying follow up questions which you can use to test if someone actually knows what he or she talks about or he or she has just memorized it after reading it a gazillion times. It is also a nice way to find a person that has gotten an answer wrong because of some pitfall, but is a good enough developer to learn it in the future and the only reason he or she hasn’t answered correctly on the first try is because they haven’t actually used it. You can also see how the people you interview think when you ask them those questions yourself and discuss the questions with them. Even if their answer is wrong, cause by something, if their thought process is correct I am willing to give them a shot and help them out.

Most of those questions fall into two categories – you have either come across it and it was a painful enough experience to remember it (because it seemed really illogical and strange at the time or just because you weren’t familiar with JS well enough at the time (0.1 + 0.2 = 0.300000004 being a pretty good example of JS weirdness, or the fact that NaN is a number)) or things that are abstract enough that you have not yet encounter. Both of those categories can be memorized for tests. Memorizing them for tests does not mean an understanding of JavaScript ant does not mean the person can apply them correctly in his work. Which is again why I prefer human to human interaction or making a project/task and discussing it, instead of writing answers on a piece of paper, that is rated a week after.

By the way – the test discussed above didn’t discussed any design patterns or anything more deep than understanding basic principles of the language which in my opinion is a bit strange, considering the fact that it was designed for senior developers.

This is just my opinion of course. If anyone thinks otherwise on anything I have said/written or any of my answers or explanations seem incorrect in any way I am open for discussion in the comments :)

I hope this was useful for anyone or at least made anyone think about those things.

And I really hope that some TL, instead of inviting them, giving them a couple sheets of paper, leaving them in a conference room (in which you can open, laptop, computer or phone and just copy answers and don’t think about it. I actually know people that have passed tests like that and have gotten decent jobs because of it) will start making interviews with people and actually talk with them to see how well they are quipped to be able to work in the team.


Top comments (8)

Collapse
 
erebos-manannan profile image
Erebos Manannán

Technical interviews that focus on having a bullshit paper test are useless, I would personally refuse to take part in any and would walk out if insisted as they serve no purpose and focus on something like that tells me the people I'm interviewing for are not very serious.

Any sensible person generally should answer to the idiotic trivia bs questionnaires with the words "I don't give a fuck, and if I really need to find out I'll either run the code or google".

It's good to know about the common issues of the language you're working in, but to focus on those more than just by asking the question "are you familiar with how bad the typeof operator, floating point operations etc. are in JavaScript?" or "have you heard of the good parts of JavaScript" is ridiculous..

What interviews should focus on is practical experience, trying to find out if you get along, interest and experience in RELEVANT areas around the work they'll be doing.

Basically what a technical interview should consist of is more along the lines of:

  • "Tell me of your favorite project in the last few years" - to find out what they like to work with
  • "Can you describe it's architecture to me on a drawing?" - to test communications skills a bit
  • "Is there any specific code you've made recently that you're very proud of and want to show to me?" - to see what kind of code you think is good code
  • "Describe your routine for getting around blockers, issues that you just can't seem to solve?" - to see how resourceful they are, if they know to depend on the team to support them, etc.
  • "How many programming languages have you programmed significant amounts in?" - if the answer is very low (like 1-2) they likely don't have a lot of experience in different ways to solve problems

... and so on.

When you ask someone e.g. "how well do you know SQL" and the answer is "quite well" you should feel secure that you can hire them without giving them a quiz about it, as you can always fire them if it turns out they lied.

Also the question of knowledge of a specific topic rarely even matters when dealing with suitable people as they can learn the things they don't know. You generally build a team so people with varying levels of experience and different kinds of backgrounds can help each other out, and not so everyone knows the details of all the tools you are using. More diversity is better in this as well.

Collapse
 
erebos-manannan profile image
Erebos Manannán

Oh btw the test:

Make a function ‘sum’ that returns a sum of two values.
this function should be called as these examples:

console.log(sum(5, 3)); // returns 8
console.log(sum(5)(3)); // returns 8

Is also an immediate red flag that should tell you "NEVER WORK HERE" - no sane person would ever write a function with such obviously differing return values depending a bit on the number of arguments. Holy hell that would make life working with their codebase a pain in the ass, and JavaScript is already a big enough pain in the ass without artificially making it worse.

Collapse
 
k_ivanow profile image
Kristian Ivanov

IMO they just wanted to see if anyone knows what currying is. This being said there are two things

  • I haven't seen anyone use currying in my past 6 years as a developer, neither at work or at code examples of finished products. I have recently seen it as part of articles, to which there are links in my article.
  • If they are actually using it - WHY? being able to support handling arguments that way is weird and is a step away from also handling sum([5,3]), or sum ([5,[[3]]]) or something weirder, that I can't think of right now.
Collapse
 
k_ivanow profile image
Kristian Ivanov

Yes to all of your points!

I would a few more points about asking them to show me some code samples from their project, which they believe to be good because they have found an interesting solution to an interesting problem. And briefly discuss it with them, to get a glimpse of how they think and how they approach problems.

I stayed for the test, because it is the first time somebody handed me a test for technical interview. I did it way too fast, took pictures of it and decided to write the above rant. If even on TL or someone in charge change its ways from this to something better it's worth it.

Collapse
 
joaovkg profile image
João Kosciuszko

About the sum function one, what is the best way of doing that in ES5? I did like this, but I don't know if it would be the most appropriate way.

function sum(x) {
if (arguments[1] == null) {
return (function(y) {
return 'With currying: ' + (x + y);
})
} else {
return 'Without currying: ' + (arguments[0] + arguments[1]);
}
}

Btw, nice article!

Collapse
 
k_ivanow profile image
Kristian Ivanov

Thanks! I like that you found it useful.

Your solution is pretty straightforward and descriptive. I like it.

Collapse
 
prestongarno profile image
Preston

I think you're right about having to painfully learn those concepts if you've been programming seriously for at most year. Anything JS-specific on the test can be solved with a few Google searches.

Senior positions should require skills in more abstract domains such as scalability and iteration. Code exams don't really quantify things like that. I would be skeptical going anywhere with a company which spends time asking you about floating point!

P.S. Questions about currying & "callbacks"? It's about continuations/futures and function literals these days IMO;)

Collapse
 
k_ivanow profile image
Kristian Ivanov

I couldn't agree more. I don't think anyone who is invited as for a senior developer position and get asked about a floating point problem will go to work there.

I expected at the very least some design patterns, some better stuff that come from the "new" standard or literally anything more complicated than this. If I was give a more large code example and get asked to identify potential performance issues, or to find other problems, it would have been better in my opinion.

I agree with your P.S as well ;)