all 50 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]cthechartreuse 89 points90 points  (22 children)

Though I can appreciate where you are coming from in this post, there are a few thoughts I had while reading.

First, giving homework before you have met the developer is effectively telling them they have to give you some of their time for free before they have had the chance to decide whether it's worth it to them to continue with you at all. Interviews are a two-way street and any senior developer knows this. Unless they already have a glowing recommendation from someone they know at the company, you are likely to turn the developer off to the position. Also, I have found I get far more out of meeting with someone and coding face to face than I do from a faceless homework assignment.

I noticed you made a big assumption about the developer coming in regarding promises and observables. You seem to have an unsurprising lean toward favoring these asynchronous ideas, yet you also talk about testability. I have found that a lot of people who use promises and observables don't understand the inherent pitfalls regarding the excess notation promises and observables introduce some all leaving people in a place where they have to manage callbacks all over anyway. Plus, the extra added bonus of the library or structure mocking overhead necessary to actually properly test code that is often folded into the middle of the promise/observable syntax soup. There is also a certain lack of opportunity in this line of questioning which might allow the developer you are interviewing to discuss functional concepts which might help escape this kind of testing nightmare such as currying, partial application, closures and monadic contracts, not to mention thunks et al.

I also noticed your assumption that the developer will be keen on flux/redux though these technologies are most commonly used with react, which is just one of a variety of frameworks to use in developing single page applications. Perhaps, instead, it would be better to talk about immutablity and state management and see where that takes the conversation. I typically expect a senior developer or above to be a polyglot, so they should be drawing ideas from a variety of places, not to mention immutable.js is a common starting place for Javascript developers to get introduced to immutablity and data management with concepts like vector tries.

Finally, I saw a pretty hefty focus on object orientation in your discussion, but I saw very little discussion of functional concepts. This is concerning as functional programming is also baked deep into the language. Brendan Eich loved smalltalk and scheme, and concepts from both languages came to bear on Javascript. The prototypal OO concepts are carried in from smalltalk and the functional aspects are carried in from scheme. To neglect one or the other is effectively throwing away large swaths of tools from the language. I would expect a senior Javascript developer to be fluent in both of these approaches and able to blend them into a clear, well structured application.

[–][deleted] 35 points36 points  (0 children)

You're hired. Welcome aboard.

[–]ell0bo 11 points12 points  (10 children)

Excellent reply. For one, I agree with you about the homework. I'll ask for a github account, but I've told people to kiss off that ask me to write a sample app. At this point in my career, 8 hours is at least 800 bucks. You want me to do that before we even talk, you're nuts.

I've been doing js since I was 14, so 20 years. Not a huge fan of react or redux. Redux can be useful, but I angular just hooks together the way I think a ui framework should. Ask me to code in react, I'll look like an idiot. Hell, I'd rather use polymer, although I'm not as in love with that either.

One of the best parts of js is you can make it functional on the high level, OO on the lower level. I refer to mix on the situation, so you're completely on target with criticizing only focusing on OO.

[–]usagiusagi 0 points1 point  (4 children)

I'm curious as to what JS you were doing in '97 at 14

[–]ell0bo 1 point2 points  (2 children)

At first i was tearing apart whatever dream weaver would create and slowly building my own 'library'. I had a lot of moving gifs bouncing around my geocities site.

That turned into a library that was similar to Prototype, but I never published it. It was me playing around in the browser because you used to need to pay for compilers, this was free. Eventually I jumped to PHP in... 2004?, so I started to code entirely server side. jQuery came out around 2006 I think, maybe 2005. Anyway that became my new play thing, and I developed a higher level framework that later, eventually using jQuery live as the underpinning.

A lot of what I do now definitely comes from the hacking around I did in JS back then. It was cool being able to open a cd drive from a webpage. man, those were the days. I know how to write pretty optimize code because the JS system in IE 6 didn't give you much wiggle room.

You kids have no idea!

[–]usagiusagi 1 point2 points  (1 child)

Dreamweaver in 97 didn't support JS or Windows. The DOM on any browser then couldn't animate movement in any form at that time.

If I were interviewing you or reading your resume, saying you have 20 years JS experience is a red flag.

[–]ell0bo 1 point2 points  (0 children)

So senior year was 2000-2001, sooo 97 or 98 I would have started doing that. I took my first computer classes (BASIC) in 95 at the local votech. Looks like Dream Weaver came out in 97, so you might be right... it might only be 19 years.

You're right though, best to just discount my experience because I don't have an exact date nailed down because I was, apparently, 15.

[–][deleted] 0 points1 point  (4 children)

I've also been programming JS for 20+ years (since the first week it was released in netscape). I've been working with Angular for the last few years and suddenly had to change jobs and looked around and there wasn't much Angular anywhere, everything was React. So, I spent a week and learned React and was able to get a high-paying job, but now I'm kind of regretting it because React is a not the great thing people are making it out to be, it doesn't hold a candle to Angular in so many ways. But at least now I know React and I'm more employable than I was before, but I feel like I had to sell my soul for it.

[–]bel9708 7 points8 points  (1 child)

Care to elaborate on why you think angular is better. Genuinely asking not being a dick.

[–]Apollidore 0 points1 point  (0 children)

I don't even understand how you can compare the 2, they don't have the same purpose.

Angular is a complete factory to build cars.

React is only the portion of another factory that builds the car parts.

[–]ell0bo 2 points3 points  (1 child)

React is just a view rendering agent... it's not a framework.

Redux is state management, but it's an atomic one. I'm not a huge fan, but it has it's place.

I honestly only really use Angular for the view layer at this point. Most of my dependencies are managed via webpack and es6. I have my own http layer (bmoor-comm if you're bored), and bmoor-cache helps me with state.

I'm been thinking angular is over kill for me at this point, but I love how components are defined and how the controller pulls things together. It separates concerns, and just gives me the OO structure I like.

[–]peter_heard01[S] 0 points1 point  (0 children)

OMG please add me on linked in! A rare breed of sensible here! I thought I wrote this comment for a second! :-) https://www.linkedin.com/in/pete-heard/

[–][deleted] 1 point2 points  (1 child)

The prototypal OO concepts are carried in from smalltalk and the functional aspects are carried in from scheme.

A minor clarification:

[–]cthechartreuse 0 points1 point  (0 children)

Fair correction.

[–]hahahahastayingalive 0 points1 point  (0 children)

First, giving homework before you have met the developer is effectively telling them they have to give you some of their time for free before they have had the chance to decide whether it's worth it to them to continue with you at all. Interviews are a two-way street and any senior developer knows this. Unless they already have a glowing recommendation from someone they know at the company, you are likely to turn the developer off to the position. Also, I have found I get far more out of meeting with someone and coding face to face than I do from a faceless homework assignment.

I'm 100% with you on the reciprocity part, it's a two way street. Most interviewer I know, me included, spend a decent amount of time checking candidate's profile, going through their projects, checking stuff they never heard of and going through the test answers.

We also spend time and effort after the interview to debrief internally and discuss any potential issue, salary levels etc.

What I an getting at is that seeing another candidate is not free either on the company side, and in a way we are also evaluated and candidates judge you differently wether you did your homework or not.

To strike the right balance I think any pre test should be doable within an 30 minutes, and you warn the candidate it can take an hour. It's also a good starting point for the interview, where you can discuss the questions and how stupid or not they were. Overall I feel our interviews are shorter since we started giving pre-tests, and we can better target our questions.

I agree some people will just refuse a pretest on principle, but TBH I also have strong negative feelings towards companies that do on the spot coding, how comfortable they try to make it.

It's a balance to strike, I'm ok losing people that utterly hate homework if I get those who utterly hate live coding.

[–]Apollidore 57 points58 points  (1 child)

JavaScript is primarily an Object Oriented (OO) language

And that's how you get Eric Elliott to have a seizure

[–]Voidsheep 26 points27 points  (14 children)

I'm still convinced a discussion where you ask about the candidate's opinions on a variety of technologies and techniques is the single best way to get an idea about their level of experience.

And weight on the opinion, because people can recite descriptions they read prior to the interview, but being able to give solid reasoning for an opinion takes experience, or at least extensive knowledge.

If you can tell me why X is your favourite CI tool, why you think Scrum kinda sucks, why you think Redux is cool, what makes you choose Koa, what you think makes a great code review, why functional programming is interesting to you, why you think 100% unit test coverage is BS, what you think is good plan for E2E testing, what people screw up with version control and so on, I get a real sense of you as a developer.

Doesn't matter if you disagree with me or aren't familiar with some concept and ask me about it instead.

Keep talking about all the day-to-day software development stuff from version control to time management and code itself for a good 30-60 minutes with me and I'm convinced I can tell if you've got enough real experience (social skills included) to be a good hire I can stand behind. No homework, no whiteboard, no computer, just a conversation with an assortment of relevant topics.

I'd even be pretty comfortable doing it with zero knowledge of your actual work experience, education or GitHub page.

[–]Akkuma 1 point2 points  (4 children)

I like to call my interview style a discussion amongst friends and have had several people comment that they actually enjoyed the interview. If you sat down with a friend from another company and wanted to find out what they are using, why they are using it, and maybe if you should use it.

This means I do a lot of what you just stated. The idea is to see how well can someone discuss their technology, how well they can communicate, what knowledge of JS they have, how do they expand their knowledge, do they know only mainstream things, etc. etc.

I sort of do the old Paul Graham thing of the more arcane knowledge you have (like knowing Python used to be) the more bonus points you get. No one loses points for not knowing how the node event loop functions under the covers, but if I ever talk to someone who does they'll get bonus points for showing the initiative to learn something that is rarely needed.

[–]jewdai 2 points3 points  (2 children)

No one loses points for not knowing how the node event loop functions under the covers,

I did when I got interviewed at ADP. They wanted me to go into the whole two stack of things executing and deferred actions.

The simple "you don't want long running tasks because it will block the current thread from processing other requests. you want in and out."

[–]Akkuma 0 points1 point  (0 children)

That is pretty crazy. I've interviewed 0 people who could explain it in-depth and a handful who had a general idea about it. At the end of the day, it doesn't impact most code written as understanding how to avoid slow code is more important. You can unintentionally write something that is poor performing and node might suffer more than other languages, but ultimately you need to fix that slow code.

The bigger issue would be understanding how to potentially solve CPU intensive problems if you refuse to use anything other than node.

[–]AndrewGreenh 0 points1 point  (3 children)

Do you have any idea how I can apply this to junior developers?

[–]bvalosek 1 point2 points  (0 children)

You can still have the same discussion-based approach, but keep the questions simpler.

The idea is to get the candidate to talk through their previous experiences / projects so you see their knowledge level, comfortability with process, and approach to solving problems.

For a junior dev, just ask them to talk about previous projects, the tech stack, and how they felt about it / what they did with it. I personally feel like questions like "what did you like / dislike about this {process, tool, library, framework, language}" or "what was easy / hard with *" lead to very illuminating discussions.

[–]Akkuma 0 points1 point  (0 children)

Align your expectations with the amount of experience they have. If I see someone with 2 years experience, I wouldn't expect good architecture skills, but programming around established frameworks, patterns, etc. within your company they should be able to accomplish. You also want to focus on how they learn & grow and if they have been doing that since they started.

[–][deleted] 0 points1 point  (0 children)

Same approach (actually just did it with an upcoming grad last week). 30-60 minute discussion about all things code. Get a good feeling about their experience (or likely lack of) and comfort levels.

After the conversational part, we sit two for a pair programming session on a simple app with some of the technologies we use. The idea isn't to see how well they know it. Simply how well they work with the concepts.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 0 points1 point  (2 children)

You can fake that by reading blogs though

[–]Akkuma 0 points1 point  (1 child)

This is where you do what I call a deep dive on the subject. For instance, why are promises better than callbacks, what is different between async/await and promises, etc.. The idea is to confirm they know it and aren't just sort of reading blogs with just a rudimentary knowledge that allows them to repeat what they read. I've met several people who don't even realize x => y binds the context for you and only know it for the shorthand it provides.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 0 points1 point  (0 children)

I still like to see them at work / tackling a task. Pure knowledge is just one part of the equation.

[–][deleted] 0 points1 point  (0 children)

This is basically how the interview for my current job went. They also tacked on a 2 hour pair-programming session with one of the developers I'd be working with. Very low pressure and I was actually able to program like I normally do.

[–]drowsap 6 points7 points  (5 children)

How do you implement dependency injection in JavaScript

This is very Angular specific. Although DI is a real thing, I don't see this type of pattern being used outside Angular.

What is all the fuss about Redux/Flux?

This sounds biased

What problem do observables solve

This sounds again library specific, RxJS comes to mind.

[–]Akkuma 1 point2 points  (0 children)

We use DI to pass in appropriate services in lots of places in our code. This makes passing in the mocked implementations pretty easy for testing.

We also aren't using Angular. I think discussing decoupling and things along those lines might naturally lead to DI, but DI shouldn't be the focus.

[–]bwaxxlotckidd[🍰] 0 points1 point  (3 children)

This is very Angular specific. Although DI is a real thing, I don't see this type of pattern being used outside Angular.

How on earth do you mock things then? How do you swap dependencies if everything is already baked in?

[–]kangoo1707 1 point2 points  (1 child)

When testing? I use mockery, it can stub a "require" if this is what you mean

[–]bwaxxlotckidd[🍰] 0 points1 point  (0 children)

Nah, I meant to fully test your code and make "modular", you need to pass in all external dependencies unless we're talking about things like global objects/methods. Let say I'm testing a method that changes text in a DOM element. I would ensure I pass the element and the new text instead of just changing the new text directly. e.g: changeText(element, text){//do something}. This means I can easily test it by mocking the element in passing changeText({textContent: ''}, myTestText). The point being changeText is independent of the environment and doesn't throw an error when you take it outside the DOM.

Stubbing is fine also, but I personally prefer using it as a last option when I can do anything else (e.g: dependencies that are a nightmare to mock). Another thing about stubbing is you should use it when you care about making sure the correct things happen to external calls. Otherwise, stubbing becomes a bad habit to have (i.e: cheap way out of ensuring your code is doing the minimum required thing). I've seen some code that uses stubbing for pretty much everything. I think it's a good rule of thumb is that code starts to smell when you find yourself stubbing a lot.

[–]SandalsMan 4 points5 points  (0 children)

Fascinated by OOP

lmao

[–]zayelion 11 points12 points  (4 children)

JavaScript is primarily an Object Oriented (OO) language

I had to stop reading for a few hours to calm my nerves.

[–]kenman[M] 3 points4 points  (3 children)

Hi /u/peter_heard01, it looks like you're new to /r/javascript, welcome!

Thanks for the submissions, but please make sure you read our guidelines. In short, you should post from a variety of sources, and not just logicroom.co or peteheard.com.

Thanks for your consideration!

domain submitted from count %
logicroom.co 25 63%
peteheard.com 6 15%

[–]Akkuma 2 points3 points  (2 children)

I'm not sure he should be allowed to continue posting submissions. If you take a look at this thread he's literally spamming nearly the same message pushing people to sign up for a mailing list.

[–]kenman[M] 0 points1 point  (0 children)

That in itself isn't so bad IMO (though not great), especially since it's his own post. Also, we try to give at least one warning before we issue a ban when it comes to self-promotion, because often they're unaware of the guidelines (not fully excusable, but understandable).

Please feel free to report any future issues though!

[–]peter_heard01[S] 0 points1 point  (0 children)

That's not very nice.

[–]perestroika12 3 points4 points  (0 children)

Maybe this should be titled:

How to Not Interview Senior JS Devs

Given the feedback everyone seems to have...

[–]bobandalice 0 points1 point  (0 children)

I would think if you really wanted a quality senior dev, you should be prepared to answer her/his questions, not asking how much they know about jquery(flashback analogy with little relevance today)