The War For Talent
avc.com
avc.com
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.
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.
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.
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.
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.
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.
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.
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."
And then hope none of your guests call the SPCA.
Granted, your solution is better, but you can solve this problem without binary tricks.
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.
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.
I think it comes down to most people (myself included) having a hard time recognizing competency and skill outside their own experience.
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.
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..
http://www.jwz.org/images/hipster-trap-560x795.jpg
New Jersey has guido traps:
http://www.thehighdefinite.com/wp-content/uploads/2011/03/je...
And now Silicon Valley has developer traps:
http://www.avc.com/.a/6a00d83451b2c969e2014e5ff76eed970c-500...
- Money (I have a family to care about)
- 'Interestingness' of the job: does it require creativity? Do I have ownership? Can I start things from scratch, or do I have to maintain an ugly overcomplicated buggy code full of EntrpriseEntiytyManagerConfigurationFactoryFacadeIntefaceBean-s created without any philosophy behind?
Hardware setup is not that important for me. Never was.
Also there is no war for talent yet. Firms in Silicon Valley did not realize yet that there is talent in other parts of the world for much cheaper than in Sillicon Valley. When the real war will begin, I hope we will gain access to better opportunities here in the east than now. (Now they mostly resort to the east if some noncreative work should be done. (So called 'offshoring'.))
Maybe that's because you've always had a decent hardware setup. I once worked for a company where the clueless management decided to save money by having fewer workstations than developers, and our department had to make sure they all looked in use, otherwise a management snap inspection might take even more away.
1. Money (to not have to worry about it)
2. A challenge
3. A great team
1. Money (to not have to worry about surviving with basic treats from time to time)
2. A challenge
3. A great team
4. Equity (to make the sacrifice of #1 be a bet that pays off over time to more than offset the choosing of the harder path with a tighter belt)
http://research.microsoft.com/en-us/news/features/vibe.aspxI once had a two-monitor setup, and I dind't like it. Way too much clutter and information overload on the desktop. Managing that wide screen real estate is cumbersome. The view angle is too wide. You never know where the focus is, etc.
I peronally would prefer just one display with really good resosution.
> The first study revealed that the users' productivity increased by 9 percent. Further studies showed even greater increases - at times up to 50 percent for tasks such as cutting and pasting.
What a great productivity boost for a programmer! Yeah, copy-pasting is what we do all day long.
Try two vertical monitors. It's awesome. (FYI: vertical monitors are sold as rotatable widescreen monitors; Dell sells them for sure).
But I have reverted to one widescreen monitor, and I like it--I like the focus.
Don't be fooled by cheap gimmicks. You can buy your own Dr Pepper.
You don't have to be a great dev to be worth north of $150 an hour. Step 1: get inserted into the part of the company that makes money. Step 2: adjust any knob available such that they make more money. Step 3: get in the habit of citing Step 2 when you aggressively negotiate salary.
If you feel you are underpaid, then apply for one of those positions on USV's portfolio jobs page. All of their NYC companies are awesome.
Seriously, how can you call it a war when the territory is so poorly delineated. Searching for "talent" is like capturing neutrinos. So shouldn't it be termed a "Crapshoot for Talent" or "Gold Rush for Talent" or such? Add to that the interaction problem (an excellent worker in one environment may wither in another).
Metaphors matter! Choose your weapons carefully. Oops, sorry, it isn't a war! Choose your garden shrubs carefully.
That's the war. For most industry engineers, its a crapshoot.
Outside Silicon Valley, and outside the US, there is also a lot of talent, which would dream of earning even half of what a Silicon Valley developer does, but cannot move there for some reason.
Ample opportunity here for smart companies.
The market is moving in this way, but slowly. There is a certain threshold above which it just isn't worth to pay multiple times the salary just for someone that lives closer.
It might also be that better collaboration tools need to be developed, or improved, to support this. Or that good tools exist but they are not well-known enough.
And there is one more problem: some of startups struggling to hire very good engineers are not aiming big - the prevalent business model is: we hope to be acquired by Google/Apple/Facebook/Intuit etc. Stories of Digg, Reddit, and Delicous don't inspire a lot confidence for engineers to join these companies.
I didn't buy it because it cost $100, I bought it because they are JUST ENOUGH desk to make an excellent workspace and they are height adjustable. I will never use a non-height adjustable desk again, full stop, and there aren't many other options for height adjustable desks that are anywhere near reasonable in price (and that is coming from someone who didn't blink when buying a $700 chair).
A $20k pimped out setup or two is still less than a recruiter would charge, and hopefully about the same as the value of a developer's work to the company in 1 week.
I think Asana has the right idea, just letting people pick whatever they want within a $10k or so budget. There is some value in having commonality (spare parts, support, chargers), and I'd be surprised if anyone wanted anything except Apple or Lenovo laptops and high-end desktops with big monitors.
We're currently doing our development in WA (one founder), NH (lead developer, almost founder), and IL. If we get into one of the Bay Area programs, I'll move to CA for the program, and probably then some.
The reason for the move isn't for development talent, it is for networking opportunities and mentoring opportunities.
I think 37signals gets it (more) right. A company credit card with which you can buy any training or educational materials you need to become better at what you do or to help you with your work. Now that's a perk. (Though a personal secretary/PA to handle all of the non dev BS would be even better..)
There's a huge difference between engineers and developers.
Engineering is the negotiation of constraints. Developers write code. You need to be both.