Comment by geuis | Hacker News Reader

Comment by geuis | Hacker News Reader

It may just be me, but I don't see this "war for talent". I live in San Francisco and have worked for 3 companies since moving here. I am a damned good frontend engineer, like learning and playing with new tech, very opinionated and dedicated to good product design, and sure I would be an asset to any company that wanted to hire me. I've also had experience with trying my own startup (failed) and even been part of a team that got a YC interview.

Despite all of this, any time I have interviewed with some of these companies that claim to be in a war for talent, that's not the impression I get. I always end up meeting and talking to people that are looking for CS students who happen to know HTML.

Some random Facebook engineer wasted a half an hour of my time trying to get me to write a function to calculate a square root approximation method. Another interview asks me how to figure out which one of 100 bottles of wine has poison in it using 10 mice. Seriously, WTF?

At no point have these people who say they desperately want a frontend engineer actually asked anything remotely touching the job skills I possess. Want super efficient pages? Well constructed js? An innovative solution to a hard frontend problem? A high performance html5 app that looks native on a phone? Apparently not. These guys just want more CS engineers like themselves and not people that have acquired the best knowledge by years of working in the field.

I work at a big name media company now. When they interviewed me a couple years ago, they got it. They knew what they were looking for and what they actually needed. I work with some awesome people. Sometimes we butt heads because I care a lot about what I build and sometimes big corporate decisions are bullshit, but that's ok. The team I work with is smart and capable and we get shit done.

And guess what? We aren't all CS graduates. We taught ourselves and built careers for ourselves. We learned everything we know the hard way, by actually doing it.

One of the biggest problems with development at FB, Twitter, Google, etc is that frontend engineers may not know "serious CS" and/or have some distributed systems "common sense."

It's remarkably easy for an apparently simple commit to dramatically increase load on some backend server, causing site stability issues and/or cost increases.

Your big-name media company probably doesn't care as much about getting every last penny out of its hardware, and its users probably aren't growing at a breakneck pace.

The questions you mentioned were designed to test if you know basic math and CS. If you don't know binary search, you probably also don't know asymptotic complexity, which means there's a chance you'll sneak in an O(n3) (expensive) loop in your javascript somewhere.

And this is exactly the problem I am describing. If the position is for someone who is only going to write js, then I agree. Those are important questions. But then that is for an engineering position who writes in js, not a frontend engineer.

If you want a good example of what happens when strict CS people write javascript without thought or knowledge of frontend best practices, look at YUI. Ugh.

So my argument boils down to making a clear distinction between a programmer and s frontend engineer. You describe the first, I the latter.

I've recently been on the other side, trying to interview and hire people. It's difficult.

My primary concerns are: Is the candidate going to be competent and capable of solving difficult problems and contributing to the team? Are they going to work efficiently and be productive? And perhaps most importantly, are they going to be enjoyable to work with?

It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code.

To that end, I try to get candidates to code with me, usually by asking a challenging problem and then sitting down next to him or her to work it out. The whole process has been more difficult than I anticipated though. I find many candidates unwilling or unable to write code in an interview.

I'd love to hear some suggestions on hiring tactics and questions to help me better find my next co-worker.

This is the principle problem: "It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code."

No, they can't be easily learned by people fresh out of college. I'm 31 and have been doing this stuff since I was a teenager. It takes years of hard won experience to really know the ins and outs all the various facets of frontend engineering. This particular sub-field isn't one programming language. It's knowing what html, css, and javascript do across at least 11 different browser platforms. It's knowing what kinds of interfaces work for different devices. It's knowing javascript as a true language and not a copy/paste thing. It's being able to know know to translate a 2 dimensional design into the correct underlying structure, in real-time.

So that's just my answer to your "any good programmer" statement. That just means you don't really know what you actually need to be hiring for.

I agree 100% about being about to get along with people. But problem solving is directly related to the field you're in. Ask a programmer to be a heart surgeon, I'm sure any smart programmer can easily learn those skills. The intuition will be there if the interview is about what the person should know.

Suppose your database queries are running extremely long and slow because you're a startup and you and your cofounder are generalists. Your company starts getting traction and now that database is becoming a problem. You're a frontend dev that knows python, and your partner is more of a biz guy that does some coding. Now you both identify that you need someone who really knows how to scale databases. Do you ask candidates random CS questions to see if they have some ill-defined "intuition", or do you find out if they know how to scale databases?

It's no different for frontend engineers.

I also agree about the coding part. But you have to do it in the context of the requirements. For a frontend, look at their previous work. Identify some area of your own product that you think can be improved, or was improved. Have the frontend candidate work through how they would improve the js/HTML/CSS etc. This should involve coding, and the person interviewing should have at least enough base knowledge themselves to know if the candidate is worth their salt or not.

You're right, a lot of things take years of experience to learn, which is why solving a difficult problem is not the only way I evaluate a candidate. I definitely look at their previous experiences.

But someone who is so specialized that they can't solve problems outside their area of expertise would worry me. I don't expect a programmer to learn heart surgery, but if you've been doing C++ for years, I'd expect you to pick up Javascript in a month or two.

Now, in terms of "knowing who we actually need to be hiring for," I know exactly. I want someone who can do their thing well but shift and learn as technologies change and as the business grows, and potentially do things they've never done before well. It's integral to have people like this in any start-up (any of USV's portfolio companies) or a fast-growing company like FB.

The trick for me is, how do I evaluate this?

Lastly, here's a real-life example that hope illustrates what I'm looking for. At an old job we had built a web app that monitored an embedded device via ajax polling. The client liked the solution, but found it impractical to always have a browser window open. None of the engineering team had any experience w/ XMPP, but our research and discussions with the client led to an XMPP-based solution. We didn't have time or money to hire an XMPP specialist and we didn't want to lose the client. We had to learn and adjust.

I've already brought my partner on that project aboard my new company. But every time I step into an interview, I am wondering how I can find someone like her.

The question about mice seemed sort of neat to me at first. I figured the desired solution was splitting the wine into two groups, taking the group that turns out to be poisoned, and then recursing.

Then I came up with an alternative solution.

Step 1: Kill 9 mice.

Step 2: Have the mouse drink from a wine bottle.

Step 3: Wait to see if he dies. If he dies you found the right bottle. If he doesn't take the next bottle and go to step 2.

He left out that there's a time limit. You have a party with guests coming over in 10 minutes, and it takes 5 minutes for the wine to kill the rat (in any dosage amount). Given those constraints, how do you do it?

It's a fun question, but the best response I've heard to this is, "Move. You're never going to get laid with rats at your place during a party."

Yeah, the answer is actually bit math if I can remember. And I'm sure these kinds of questions are right for some kinds of positions, but they aren't appropriate for frontend engineers. It was fun to try and figure out though. If the question was "you have 10 mice, 10 bottles of wine, and a house full of people that you want to leave, what's the most efficient way?" then that's something that has merit. That involves thinking about compression methods and shoving people (data) through limited exits as quickly as possible. That's a relevant question.

Yup, it's bitmath. I happen to know which company's asking that variation of the question right now. Interesting to see good companies miss the mark in interviewing so widely.

I think it comes down to most people (myself included) having a hard time recognizing competency and skill outside their own experience.

Yeah I met up with them a month or two ago. Great guys, and they seem to be doing well

He's testing if you can think in binary. Label the bottles of wine with binary numbers, 0000001 to 1100100. Give the first mouse every other bottle of wine, the second mouse every bottle of wine with a 1 in the 2's place, the second mouse every bottle with a 1 in the 4's place, etc. If a mouse dies, the poison lies in one of the bottles it was given. If a mouse survives, there is no poison in any of the bottles it was given. Since every combination of mice is associated with a unique bottle, you can read off the digits formed by the dead and live mice to determine which bottle it was.

And then hope none of your guests call the SPCA.

Given the constraints (10 minutes total, 5 minutes for poison to kill), you can also divide the wine into 10 groups and assign each group to each of the 10 mice. The mice then drink samples from every bottle in his group, and after 5 minutes, the one that dies has the group with poison in it. You then assign each of the rats a bottle from this group, and then see which one of them dies. If they all live, then the remaining bottle is poisoned.

Granted, your solution is better, but you can solve this problem without binary tricks.

Thanks for this additional information. Now I finally see what geuis is talking about.

This is a great puzzle but IMHO a terrible interview question, even if you're looking for C programmers. Interviews are about talking. I might be able to solve this puzzle (though not necessarily under pressure) but I'm quite sure this isn't a puzzle I could talk my way through out loud. At best, I'd sit around for minutes muttering under my breath and staring at the walls and pacing, and then state something approximating the answer. A waste of good interviewing time.

Remove the time limit and the puzzle isn't so bad. There's a nice stupid answer (the "99 bottles of wine on the wall" algorithm) and a progressive series of potential improvements (the "10-bottles-of-wine-on-the-wall played in parallel ten times" algorithm; the "mix the first N/2 together, mix the second N/2 together, feed the first batch to a mouse, iterate" algorithm, and finally you kind of parallelize that and get the ultimate answer). But you shouldn't expect to get all the way through that discussion in an interview -- and, if you state the time limit up front, you just scare the wits out of the candidate.

Split it into ten groups of ten with a mouse per group. One mouse dies. Split that mouse's group into ten groups of one with one mouse for each group. There is a leftover group since one of your mice died, but it doesn't matter. If none of the other mice die you can deduce that the untested bottle contains the poison.

Two poison applications to find the right answer, so it only takes ten minutes. Lock the door and tell the guests who arrive you will be there in a minute so you have a bit of breathing room in which to prepare your bottles.

A fine opening, because not only is it the stupidest algorithm that could possibly work, but it also tees up the obvious follow-up questions: "How efficient is your method? How much time will it take in the worst case? How much in the best case? How much in the average case? Can you improve on this?"

These follow-up questions, and the fluency with which the candidate navigates them, are actually the point of the exercise. Well, that and to learn whether or not you're talking to someone who can't properly state any algorithm, and to help gauge your candidate's level of primadonnatude. [1]

[EDIT: Okay, I typed this up before people stated the version of the question with the 2-mouse-lifetime time limit. That version is, IMHO, an awesome puzzle but too damn hard for an interview question.]

---

[1] There is no one ideal level of primadonnatude. It depends on the business, the role, and the company culture. Steve Jobs is, arguably, the prima donna assoluta of computing, and that seems quite appropriate for his job. On the other hand, a good second grade teacher, the sort of person who enthusiastically spends every day for fifty years instructing students in the subtraction of single-digit numbers, probably has very little primadonnatude.

The thing I loved about the second solution is that it actually performs better at scale. I love the irony of the function with the higher growth rate being the better function as the number of wine bottles increases.

a better way to illustrate it..

one deck of cards..

1 have 28 cards dealt out and ask victim to pick their card

2 Deal out 4 card stacks, cards face up staggered stacked so that victim sees every card. & cards in each stack

3 have victim tell which stack their card is in..

How many more deals before you get their card in the first card position in a stack?

Answer, counting the first deal its 3 or less..

I used this example in a RealNetworks interview, they really did not get it..

Reply on news.ycombinator.com