Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to prepare for a Front-end Developer interview?

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 146 posts

Re: Ask HN: How to prepare for a Front-end Developer interview?

#101

Post by dwaltrip »

andy_ppp wrote: post #98

Closures, specificity, home made getElementsBySelector, DOM traversal stuff, weird IE things, coding standards, an understanding of how jquery works, how to protect against npm poisoning/leftpad issues, lodash, semantic naming strategies, being opinionated (why is BEM shit/great?), box model, floats, flex box, centering techniques, an understanding of how plane old js works, cross origin/same origin stuff, basic desi…

xhr, promises, a modern build tool (webpack? browserify?), prototypal inheritance, virtual dom, object oriented programming, when to add more abstractions and when to tear them down, front-end performance & memory profiling, browser dev tools, canvas, svg, service workers, browser caching, cookies, websockets, SASS, Ecmascript 6, API design principles, data modeling, when to use a hash and when to use an array, basic concepts of UX, and of course, most importantly, box shadows

Re: Ask HN: How to prepare for a Front-end Developer interview?

#102

Post by alexbanks »

In my experience interviewing candidates and being interviewed, the experience is wildly inconsistent. Most times, if it's a Front-End specific position, I wouldn't (and haven't been) asked about algorithms or data structures. I think the most important thing is to be able to talk intelligently about a bunch of subjects. Some examples:

- Do you know a client side MVC? Do you know why the internet thinks this client side MVC is bad? What are some alternatives? When should you use what?

- Why is SASS valuable?

- In javascript, describe the this keyword. What is the difference between Call and Apply? Bind?

- What is prototypal inheritance? How do you feel about it (no right or wrong answer, just a thing to talk about).

- Typical web security vulnerabilities.

If I whiteboard a candidate usually it'll be something very basic, something like write a palindrome function in JS, then write it a different way, then tell me when to use which. Also, I ask a lot about a candidate's interests. Why do you think Elm is cool? What've you written with D3 that was nifty? Talk about the problems you've solved, how you solved them, and why it was interesting.

Most importantly: be passionate about learning and doing.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#103

Post by andy_ppp »

dwaltrip wrote: post #101
andy_ppp wrote: post #98

Closures, specificity, home made getElementsBySelector, DOM traversal stuff, weird IE things, coding standards, an understanding of how jquery works, how to protect against npm poisoning/leftpad issues, lodash, semantic naming strategies, being opinionated (why is BEM shit/great?), box model, floats, flex box, centering techniques, an understanding of how plane old js works, cross origin/same origin stuff, basic desi…

xhr, promises, a modern build tool (webpack? browserify?), prototypal inheritance, virtual dom, object oriented programming, when to add more abstractions and when to tear them down, front-end performance & memory profiling, browser dev tools, canvas, svg, service workers, browser caching, cookies, websockets, SASS, Ecmascript 6, API design principles, data modeling, when to use a hash and when to use an array, basic…

All correct! Babel, Redux/data flow and immutable data structures. Basic software design principles. Anything else?

Re: Ask HN: How to prepare for a Front-end Developer interview?

#104

Post by nilkn »

cageface wrote: post #100
nilkn wrote: post #93

Earlier quoted context omitted.

I'm confused. You've never even seen a hash table come up before? What sort of front-end work are you doing? I just find this extremely unlikely if not borderline impossible. Hash tables are one of the most universal data structures in practical software development. This is just as true in JavaScript for front-end work as it is anywhere else.

Expecting somebody to know what a hash table is and understand the time complexity of inserting and looking up elements is fair. Expecting them to build one from scratch on a whiteboard is just ritualized hazing.

I don't see anyone mentioning requiring one to build all these data structures from scratch. I'd agree with you that this is a less useful exercise for interviews, in particular front-end interviews, but I don't think it's fair to assume that this is what the poster above meant. Only "basic knowledge" was mentioned.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#105

Post by ry_ry »

minikomi wrote: post #88
corecoder wrote: post #18

Before Babel, I often used to ask about code organization/modularization, mostly to filter out candidates who haven't been on a big project and have only copied and pasted jQuery snippets together; today I'd ask if you use Babel modules and why/why not. As other people have said, closures will surely come out. A favorite of mine is array functions: map, forEach, filter. Also, promises, callbacks, workers. Finally, xh…

Can you clarify what you mean by xhr throttling? Implementing something like _.throttle to wrap requests?

Hopefully not! Surely _.debounce would be more appropriate to avoid locking out your UI - or worse, returning out of date responses - but even then you would potentially want to handle the responses more robustly.

Not to mention needing to handle .fetch()s lack of abort if you're not using xhr.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#106

Post by ShellfishMeme »

danyim wrote: post #58
ShellfishMeme wrote: post #37

Earlier quoted context omitted.

I agree. We always put the little 'for loop that creates a list of functions that spit out the current number of the iteration' exercise first in all of our interviews. Generally, when people solved that one fast, they also did well in the rest of the interview and if they struggled there, they also had a hard time coming up with an elegant solution for most of the other tasks. What I also like about it is that a clo…

Would that exercise be the following? I'm not sure I understand what's being tested. const f = (k) => { const funcs = []; for(let i = 0; i i); } return funcs; } const test = f(4); console.log(test[0]()); // 0 console.log(test[1]()); // 1 console.log(test[2]()); // 2 console.log(test[3]()); // 3

We usually start out with a non working version, using `var` and just returning `i` from the function and then ask what that would print out and why.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#107

Post by corecoder »

smnplk wrote: post #82
corecoder wrote: post #18

Before Babel, I often used to ask about code organization/modularization, mostly to filter out candidates who haven't been on a big project and have only copied and pasted jQuery snippets together; today I'd ask if you use Babel modules and why/why not. As other people have said, closures will surely come out. A favorite of mine is array functions: map, forEach, filter. Also, promises, callbacks, workers. Finally, xh…

are JS closures already fixed ? var a = 10; var fn = function (x) { return x + a}; fn(10); ==> 20 var a = 1; fn(10) ==> 11 //WAT ?? Is the above fixed with ES2015 ? Closures need to enclose values and not references.

I don't think javascript will ever be "fixed": it is as it is, if you change how hoisting works, you break everything. But:

1. You can solve that already in ES6, by returning fn from a function, also avoiding the global variable;

2. Your ES3 linter should warn you about the redefined variable.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#108

Post by jon-wood »

eschutte2 wrote: post #30
jonahx wrote: post #24

Earlier quoted context omitted.

> Where's the disconnect here - are we talking about different kinds of front-end work? Yeah I would assume so. Of course if know the job requires such knowledge, you should interview for it. But I'm thinking of more average front-end work, where you'd be building forms or dashboards or ordinary websites. It sounds like you're building a complex application that just happens to be hosted in a browser. Although even t…

We may be on the same page here. I don't like the way dev interviews are run and I think the focus on textbook algorithms is misplaced. I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things. I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. Bu…

> I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.

I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#109

Post by pluma »

ricardobeat wrote: post #61
danyim wrote: post #58

Earlier quoted context omitted.

Would that exercise be the following? I'm not sure I understand what's being tested. const f = (k) => { const funcs = []; for(let i = 0; i i); } return funcs; } const test = f(4); console.log(test[0]()); // 0 console.log(test[1]()); // 1 console.log(test[2]()); // 2 console.log(test[3]()); // 3

Try writing that same thing without ES6.

Try writing the same thing without a computer why don't ya.

As an interviewer I can see why you would want to force someone to jump through arbitrary hoops like that but if someone can show me `() => i` and explain why that works, that would be good enough for me.

Re: Ask HN: How to prepare for a Front-end Developer interview?

#110

Post by Rapzid »

When I worked at Rackspace I recall the same sentiment as the majority of the comments here.. Testing for specific things the interviewer(s) happens to have fresh on their mind at the time. I've fallen into this trap myself and recall a particularly harsh interview we put an internal candidate through. It was almost a joke in this case and we wanted him anyway(incidentally he did surprisingly well regardless), but these were par for the course at the time. I doubt I could answer the questions I asked as well as he did if I had to today.
Post reply on HN