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

Interviewing as a Front-End Engineer in San Francisco

css-tricks.com

Post reply on HN
Print view View original

181–188 of 188 posts

Re: Interviewing as a Front-End Engineer in San Francisco

#181

Post by mcintyre1994 »

llimllib wrote: post #125
mcintyre1994 wrote: post #86

I know it's a bit off-topic, but I'm a student so anything about interviews interests me a lot. For the Bacon Number question, I'm struggling a bit to get my head around a good way to do it. My immediate idea is to derive a graph where nodes are actors and an edge between 2 actors means they've been in 1 or more films together. I believe the shortest path between them and Bacon could then be found by breadth-first se…

A simple upgrade to your algorithm would be bidirectional search: https://en.wikipedia.org/wiki/Bidirectional_search This image from Norvig's AI may help explain it better than the wiki page: http://www.massey.ac.nz/~a159302/lesson3/fig03_17.gif

That seems like an interesting alternative to BFS, thanks.

Re: Interviewing as a Front-End Engineer in San Francisco

#182

Post by mcintyre1994 »

lostdog wrote: post #139
mcintyre1994 wrote: post #86

I know it's a bit off-topic, but I'm a student so anything about interviews interests me a lot. For the Bacon Number question, I'm struggling a bit to get my head around a good way to do it. My immediate idea is to derive a graph where nodes are actors and an edge between 2 actors means they've been in 1 or more films together. I believe the shortest path between them and Bacon could then be found by breadth-first se…

There's no need to construct the graph. The dictionary already is a graph.

I appreciate that, but I don't see a way to efficiently do a breadth first search or some similar search routine that will find the Bacon number on it. I mean, surely you need at some point to be able to follow edges from an actor - and that's really inefficient in this format?

Re: Interviewing as a Front-End Engineer in San Francisco

#183

Post by nhangen »

hackinsack wrote: post #69
sigsergv wrote: post #36

Earlier quoted context omitted.

Software engineers make product, not code. I'd prefer talented developer with good practical experience in “releasing products” rather than an algo-geek who can only solve stupid hiring quizes. Slow buggy ugly WORKING RELEASED product is a much-much better than ideal clean and effective thing not yet ready for release for a few years in row.

Not saying I disagree with that, except for releasing slow buggy code. Why not accept either of those people? There are efficient ways, as described in the article, to interview for people that are great at releasing quality code in a productive time frame. I was simply pointing out that releasing code daily doesn't mean you know what you're doing. If you can't answer at least some of the questions that were in this…

You're right that shipping !== good code, but I wouldn't be able to keep shipping the same product if it weren't somewhat valuable to my customers.

The point isn't that I'm a unicorn, but that good developers can exist outside of code challenges.

People like me, that are self-taught and work super hard in order to improve our craft...we're not appreciated enough.

Everyone wants a rockstar, forgetting that drummers and bass players add a lot of value.

Re: Interviewing as a Front-End Engineer in San Francisco

#184

Post by nhangen »

hackinsack wrote: post #26
nhangen wrote: post #2

I'm a PHP/WordPress dev shipping product every single day, but I think I'd probably fail questions like these if I was asked in an interview setting. I don't really worry about functions like these until a need arises, and when it does (and I don't know how to do it), I learn until I do. This is an absurd way to recruit front-end talent and partially explains the so-called talent crunch.

Nothing against you, as I don't know you or your work, but "shipping product" does not equal doing good work. People ship crappy, buggy code every day. Just because one "ships daily" doesn't mean that what they're shipping is worth anything or means they know what they're doing. I've seen people that have no clue how to write code copy and paste crap they find all over the internet into a file and ship it. It's a slo…

Just want to mention also that knowing the answers to these questions does not mean that you'll write bug-free code. Bugs are a product of shipping, and occur regardless of talent or ability to answer said questions.

Re: Interviewing as a Front-End Engineer in San Francisco

#185

Post by gibbitz »

nairteashop wrote: post #159
onedev wrote: post #155

Earlier quoted context omitted.

If I hear the words "get things done" one more time, I might just flip out.... Sorry this isn't directed at you, but I view that phrase on the same level as "changing the world".

No offense taken, but I'm curious as to why you hate that phrase. "Getting work done" is essentially what we're hiring people for right? As long as you can get done what you were hired to do, it shouldn't matter whether you suck at algorithms, are not a "ninja", don't fit "culturally", and whatever other weird things companies look for in candidates. It's as prosaic as it gets, and IMO it's the absolute correct metri…

It's important to make a distinction between two different types of "get things done" here. There is one type where the candidate figures out what needs to be done to complete a feature in an application and does it. Then there's the type where the candidate figures out what is the least work (ie fastest way) and does that without trying to understand the potential outcomes. Given that the slapdash candidate is great at patching bugs I would maybe consider him/her, but frankly I prefer people who measure twice and cut once. I know that sounds like a separate concern --it is-- but some business cultures confuse work ethic and results along the lines of "gets things done".
Post reply on HN