A small team of A+ players can run circles
around a giant team of B and C players.
- Steve Jobs

Interview process is more of an art than a science.

There are as many opinions on how to properly conduct interview, as there are people out there.

Everyone will have techniques which work for them. Here I will share my personal approach to the interview process and what I'm trying to pursue when talking to developers.

My goal is not to test particular set of skills. After all, I'm only a hiring manager, and I should expect people working on my team to know more than I do. Developers know better what questions will let them shine during the interview. As such, the most important question to ask is -- "tell me what should I ask you"?

Common Sense rule requires us to diversify.

Whether we talk about financial portfolio or team of individuals tasked with solving tough challenges -- everyone will benefit from diversification. People of different races, genders, religious believes, musical preferences, cultural backgrounds working together on the same team will produce much better outcome than the team of individuals who are exactly alike. It's time-tested and proven by science -- there is no better way to build resiliency in your organization than to diversify.

The interview is a two way street.

It's just as important for me, as a hiring manager, to sell the job to the candidate, as to the developers to sell what they bring on a table.

The goal of the interviewer (me) is to spark an excitement. And it's not easy to fake the excitement.

You don't want to hire a developer who is in this occupation only because it pays well. Money is a nice supplement that most A+ players get by default anyways. The A+ geeks are looking for their next cool project just as badly as the hiring manager is looking for the A+ engineer.

Software engineering is a lifestyle.

This life style is not suited for everyone -- A+ developer is the one who makes a conscious decision to live this way. You want to hire a developers who treat their job as a hobby. Motivation does not matter but boredom is the worse thing that can happen to an organization. If you end up with the team of B's and C's -- boredom will destroy your company. The goal is to filter A+ engineers from the crowd of "copy paste design pattern" practitioners that are in this job only for the money.

Most questions are open-ended -- there is no right or wrong answer.

There are no specific coding or algorithm questions. These types of questions prove little. A+ developer should be able to figure it out on a job in no time -- give an A+ developer Google search, team of other geeks who respect each other based on what they do (not their titles), and miracles will start to happen.

The best outcome

is, when I (the hiring manager), learn something new from the candidate. Honestly, I do not always understand what exactly the interviewee is talking about, which is totally cool -- I will google for the answers later. Often I will go "Wow" few days after the interview. We expect the candidate to come prepared and, sometimes, ask to follow up on some questions. Why shouldn't candidate expect the same in return?

Java Script is in high demand these days. This specific article is sharing thoughts on how to filter A+ JS developer from the pool of B's and C's. Hoverer similar techniques can apply to any language.

Spoiler alert.

If you ever apply for a job on my team, in this article I will give you some hints about what I expect to hear during the interview, but, I'm going to warn you -- if you are a true A+ type, you have nothing to worry about :) However, the B's and the C's most likely will not pass the BS filter, because this is how this process is designed to work. But hey, no worries, the job market is really hot these days -- you will find some other place were you will be earning lots of cash and will be happy.

And finally, here is the list of questions:

Common performance issues of react apps. Common techniques for react and react native optimization?

Java Script is old, clunky, sometimes convoluted, but -- it's still the most used computer language in the world today and for good reason. React is as well one of the most influential presentation frameworks built in JS.

If you are passionate about Java Script, and if you position yourself as an A+ dev -- you could not escape hearing about React. Just like JavaScript language, React framework is not perfect. Tell me what you love/hate about React. Tell me how do you work around these challenges. What makes you excited or frustrated -- I want to know about your personal experience and opinion. Tell me what was the last challenge you were able to overcome in React, brag about how elegant your solution was, what kind of performance boost you were able to achieve in numbers. This is perfect timing to share some code samples if you have any, or feel free to grab a marker and go wild on the white board.

Higher order components (HOC) vs Hooks? What's your preference? Why?

If you've been around for a while, you must have heard that React core team has changed approach to component composition 3 times in the past 5 years. Hooks are the most recent change, which replace HOC's. Do you know what was React using for composition prior to HOC?

Expo managed life cycle benefits? Do you think the managed workflow is preferred and why?

The same logic applies here as to the last couple of questions. If you've established yourself as an A+ kind, you had to get curious about Mobile development, since mobile user engagement is on a trajectory to overtake web apps. For a JS developer, looking to build Mobile apps, React-Native should be high on the list. In addition to this, Expo is very cool, I think it's no brainer, every React-Native developer will prefer to use expo. If you like Expo, please explain why? There is no right or wrong answer. My personal preference is to always use Expo managed life cycle, but hey, perhaps this is because I'm not a developer any more. Please teach me what should I use and why? If there is something better than Expo for building Mobile apps -- please tell me why is it preferred option for you.

What dev environment do you use and why?

Mac/Pc? Brew? IDE? Perhaps it's VIM, could be Emacs or Atom, Visual Studio or WebStorm? There is no right or wrong answer. Tell me why your Editor is the best choice for JS development. Why your dev environment makes you A+ developer?

It's also cool to talk about NPMjs ecosystem here.

What was the last book/article you've read about JS?

Books are a way of the past. No one reads books to obtain technical knowledge any more. Perhaps I'm completely wrong. Tell me the book I should read about JS.

Are you subscribed to any JS mailing lists from which you are learning to improve your JS skills daily? medium.com? dev.io?

How do you keep your JS skills sharp and up to date?

Do you attend local or online meetups regularly? Which ones should I join?

JS evolution? Common JS? Es6/7? Typescript? Personal preference?

Let's talk about JS evolution. This is where "copy paste design pattern" will fail -- in JS you must understand how some of the latest cool trends like TypeScript and Es6/7 transpile down to Common JS. Why do we have such things as Polyfill and Babel?

What is spread operator? How it works?

Most likely, if you are truly the A+ type, you will already have answered this question when we were talking about JS evolution. Just a friendly reminder, it's OK to be more specific about Es6/7 features you are passionate about.

Async/Await in JS, how it works? Promises? Callbacks?

The same as for the previous question. If you really love JS -- here is the great opportunity for you to rave about callback hell, what it is and how to address it elegantly in JS.

Preferred Database?

Variety of options are available these days. Let's share our passionate view points about what is the best DB to be used in a JS project and why? What are different types of DB's that are better suited for specific use cases?

You personal approach to Object Relational mapping in JS?

Restful API? Basic principles?

Even if you are not going to be tasked with building back-end API's, you still have to know basic RestFull principles. What framework first popularized use of Rest? (Ruby on Rails). What are the other principles which made Rails popular back in the days? Have you heard of "Do not Repeat Your Self" (DRY) and "Convention over Configuration"?

AWS Lambda limitations?

The only reason I'm asking about AWS Lambda, because I've used it myself.

In this question I want to make sure that we agree -- there is no such thing as unlimited computing resources. Even in AWS, there are boundaries and constraints which, if you know what they are, will help you to better design your function as a service.

No need to give precise numbers, but what should we be aware of and pay attention to when designing FAAS ?

Does not have to be AWS Lambda, could be Google Cloud or Microsoft Azure, or somethings else. I bet they all have similar limitations around payload size, memory availability, length of execution and concurrent execution limits.

What do you know about CDN's and Edge network?

What makes node scale for the back-end?

Why backend built in node can out-scale Java based server? You must have already talked about it when we were discussing callbacks and promises. Just another friendly reminder to talk about it -- it's important.

What was the coolest challenge you solved recently

This is my most favorite question. If I had only one question to ask -- this would be it.

As I already hinted you -- you should not expect a coding assignment during my interview.

If I was to give you a coding assignment, it would be more of a demonstration of my superiority as a coder, because you will never know exactly how I would prefer you to code the challenge.

This should be all about you, so, don't hesitate to go wild -- impress me. Could be a framework that you published as npmjs, or a 3 lines function that you wrote which makes your friends go "wow". I promise -- I will appreciate anything that makes you proud of your achievements.

Here are some bonus questions

Most likely, by now, we've talked about a lot of different things, and you are as excited about joining my team as I am excited about you coming aboard. Just in case we still have time left, here are some extra stuff to chat about. The chance is we already touched upon some or most of it. If not -- see the list below.

Graph QL?

What's so cool about graph QL? Where did it come from? What challenges is it trying to solve. How does it compare to Rest? Any good/bad GraphQL frameworks you'd recommend to use or stay away from?

Basic principles of functional programming? What makes it different/better than OOP? FP languages you've used, liked, disliked?

Ideally the answers will revolve around JS. However, totally appropriate to talk about high level concepts in any language, such as pure functions, state manipulation, closures, functions composition and currying etc...

Name few JS FP libraries? Pros and Cons?

If you are passionate about functional programming in JS, you've got to know about some history of libraries.

What are the commonly used functional libraries in JS, what are they trying to solve and how:

lodash, ramda, sanctuary?

And that's all folks.

Hope you've had fun during the interview. Perhaps you found some of my questions a bit controversial, perhaps you were able to spot some mistakes. But hey, I never said I know everything better than you do. Please let me know if I should make any corrections -- this is just one more thing that may potentially gain you a spot on my team.

The article is reposted from here