3 ms·

I've worked as a JavaScript developer for several years, and not once have I had need to write functions checking for palindromes, asserting prime-ness or other

I've worked as a JavaScript developer for several years, and not once have I had need to write functions checking for palindromes, asserting prime-ness or other such efforts in rewriting lodash. I guess I must just be missing the job adverts for all those businesses writing JavaScript utility libraries.

esaym 9y ago
> palindromes, But...tacocat!
xkcd-sucks 9y ago
If such jobs exist, they beat the pants off of the "glue together some half working modules" js jobs
bcherny 9y ago
The specific functions you're implementing aren't important. What's important is that you can reason through a question, suggest possible algorithms, reason about their tradeoffs, write some code, and communicate all of that to the interviewer. What sort of questions do you ask instead?
- jbreckmckye 9y ago
  "What happens when I point my browser at $CANDIDATE'S_LAST_PROJECT?" "What's your strategy for avoiding bugs?" "How do you choose technologies?" These three questions will prove - that the developer understands the technology they work with (they know about networking, infrastructure, the server tech and are curious enough to learn about the runtimes their apps actually live on); - that the developer has a mature opinion on testing (she knows what is and isn't worth automating, and that E2E automation often has a poor ROI) - that the developer uses due dilligence and smart heuristics to choose technologies ('write a prototype!', 'eyeball the open source community!') rather than trends and groupthink ('everyone uses React!', 'someone on Medium said it was "curated"!') These are the real competencies to filter by. The actual programming part, in most jobs, is easy. 80% of the roles I've interviewed candidates for have just been extravagant excuses to move around strings and shuffle integers between databases and browsers. I see no reason to believe this will soon change. The last time I did anything vaguely 'algorithmic' was when I needed to sort a few thousand items without killing IE8's UI thread, and I solved it fairly trivially by writing a quicksort that used the recursion calls as an opportunity to yield the event loop. That's it. That is as far as most JS jobs go. I think anyone insisting otherwise is just being self-important.

esaym 9y ago

> palindromes, But...tacocat!

xkcd-sucks 9y ago

If such jobs exist, they beat the pants off of the "glue together some half working modules" js jobs

bcherny 9y ago

The specific functions you're implementing aren't important. What's important is that you can reason through a question, suggest possible algorithms, reason about their tradeoffs, write some code, and communicate all of that to the interviewer. What sort of questions do you ask instead?

jbreckmckye 9y ago
"What happens when I point my browser at $CANDIDATE'S_LAST_PROJECT?" "What's your strategy for avoiding bugs?" "How do you choose technologies?" These three questions will prove - that the developer understands the technology they work with (they know about networking, infrastructure, the server tech and are curious enough to learn about the runtimes their apps actually live on); - that the developer has a mature opinion on testing (she knows what is and isn't worth automating, and that E2E automation often has a poor ROI) - that the developer uses due dilligence and smart heuristics to choose technologies ('write a prototype!', 'eyeball the open source community!') rather than trends and groupthink ('everyone uses React!', 'someone on Medium said it was "curated"!') These are the real competencies to filter by. The actual programming part, in most jobs, is easy. 80% of the roles I've interviewed candidates for have just been extravagant excuses to move around strings and shuffle integers between databases and browsers. I see no reason to believe this will soon change. The last time I did anything vaguely 'algorithmic' was when I needed to sort a few thousand items without killing IE8's UI thread, and I solved it fairly trivially by writing a quicksort that used the recursion calls as an opportunity to yield the event loop. That's it. That is as far as most JS jobs go. I think anyone insisting otherwise is just being self-important.