4 ms·

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

by geuis 16y ago

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.

JoshCole 16y ago
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.
- sgrove 16y ago
  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."
  - geuis 16y ago
    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.
    - sgrove 16y ago
      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.
      - geuis 16y ago
        Yeah I met up with them a month or two ago. Great guys, and they seem to be doing well
  - nostrademons 16y ago
    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.
bballant 16y ago
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.
- geuis 16y ago
  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.
fizx 16y ago
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.
- geuis 16y ago
  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.

by geuis 16y ago

JoshCole 16y ago

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.

sgrove 16y ago
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."
- geuis 16y ago
  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.
  - sgrove 16y ago
    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.
    - geuis 16y ago
      Yeah I met up with them a month or two ago. Great guys, and they seem to be doing well
- nostrademons 16y ago
  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.

bballant 16y ago

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.

geuis 16y ago
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.

fizx 16y ago

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.

geuis 16y ago
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.