Ask HN: Does the valley really have Engineer shortage?
For the past few months I have been interviewing at various big tech firms in the bay area. Ones that start with F, G, U, A.
Have a CS degree, > 5 years experience. Full stack engineer and have a good paying job. I want to interview to basically test the waters and see if something good comes up.
It seems the tech companies will spend calling you, paying for your flights and meals, spending entire days interviewing you but at the end say "sorry we will not go ahead with you, we don't give feedback"
May be the more time you spend writing code on an editor, the worse you get at writing code on a whiteboard.
I can't quite figure it out. Anyone else feel the same. May be the valley has shortage of "cheap" engineers.
64 comments
[ 3.5 ms ] story [ 146 ms ] threadThe companies you did interview at do have a high standard for hiring but generally speaking at the very least you should have an idea how well you did during the interview without them spelling it out for you.
If you couldn't answer the questions or write the code they asked you to write then that's why they didn't hire you.
If you think that you did brilliantly then maybe you're not coming across as someone the interviewer would like to work with.
Even more so, if they were worried about cheap engineers, I assure you that they wouldn't be spending money to fly you around the country, buying you flights and meals (and often drinks and hotels and taxi/uber rides and sending you away with swag). The companies you listed pay the best amongst those in SV. I don't think price was the issue
Solve half of the problems there (500 from 1000). It will take couple of months, but you learn a lot from the experience and get to understand what the interviewers look for.
For more absurd, ask them to dictate their code.
All my anger here is not pointed to you as interviewer, although I see some try to defend this style of interviewing with argument about "internal langs". Google invest a lot into IDE support of their home-made langs (Go, Dart), so I doubt it's a valid point.
What is meant by "full potential" here? You are not expected to write a hundred lines of code, or get something working end-to-end. The goal is to see if you can see to the core of something more complex than a for loop. If you can, you ought to be able to explain that to a colleague in a person-to-person manner, including some syntactically-passable code. Believe it or not, a whiteboard is pretty much to most efficient way to do that.
Also I think that you asking for working code, not a general description of the algorithm, right?
As much as I've been frustrated by someone asking me to write FizzBuzz, I greatly sympathize with the people who end up asking it or some variant of a very, very simple coding problem. I hope that at some point, there really will be a better way.
Which is not to say it is easy, but putting it at only 4 successes makes it much more intimidating.
http://uva.onlinejudge.org/index.php?option=com_onlinejudge&...
http://uva.onlinejudge.org/index.php?option=com_onlinejudge&...
Don't get me wrong, I love that kind of puzzles, but only for a while.
They don't seem to be too hard either. I randomly found this: http://uva.onlinejudge.org/index.php?option=com_onlinejudge&... which is literally just translating the given algorithm into a programming language of your choice and adding a counter.
> simple editor
> simple
> vim
> emacs
> vim
Recently I needed to develop tool to optimse some PPC I did not know the Algorithms But i knew how to research and building the tool took me less than 2 days to implement.
Rob Pike: sorry, but he was the ,,distinguish engineer'' guy making our lives hard with his half-baked languages that were full of as many inconsistencies as possible. I never liked the Pike language and maybe go is a lot better, but still it doesn't even have a generic type system.
Chris Lattner: I would rather bet on him than Rob Pike. Putting together a modern language with modern infrastructure is hard. Putting together a half-baked language is easy (especially if you have engineers working under your management).
Still what's more important: if you understand the speed of basic data structures, you can reason about performance of more specialized data structures (like memory management in the linux kernel) as well.
I solved more than 100 of them, and there's absolutely no way it will take "couple of months" to solve 500, unless you're one of the best programmers on the planet and are working on solving them full time.
0. The companies the OP interviewed at, can afford to not give a benefit of doubt. If they hire a few less engineers, their revenues are not going to see a significant dip. Not true of startups. e.g. If an e-commerce startup misses a holiday season, they are done forever. They'd hence be more forgiving.
1. Valley thinks it is a meritocracy, but it is not. Valley is full of biases when it comes to engineering talent. (It's true for all meritocratic systems). They want certain kinds of engineers.
2. Regardless of the hiring market, the companies OP interviewed at, are not forgiving in their interview processes. e.g. use of substring() instead of passing indices in a string recursion will kill an interview with most interviewers. So will use of pow() in atoi(). And you won't know ever.
3. Interviewing is not a test. Interviewing is closer to a date, than it's to a test. There are no "failures" on a date. It's about whether that relationship clicks. "Hiring market" has little bearing on a date.
4. Even if the interviewing panel and hiring committee knows that there is a shortage of engineers, they cannot knowingly give a benefit of doubt to a candidate, or that starts to affect morale in the company.
5. They cannot afford to give a lot of time in interviewing. e.g. they cannot spend a week working with you and knowing you better. If they do that, they will never be able to hire enough engineers. They need them in hundreds a month. They hence have to have an interview process that's short. And short interview processes are bound to be imperfect.
One way to start: using "maybe" instead of "may be", "a shortage" instead of "shortage" and "Valley" instead of "valley."
If you can only hire qualified software engineers at $250k, then there is reasonably some sort of shortage. That's not the same as suggesting that very rich firms shouldn't pay up (and they are), but let's not rob perfectly good words of their meaning just to make a point.
It's artificially generated.
I don't really agree with you about the $250k, depending on what you mean by qualified. Keep in mind, the median salary for a lawyer in silicon valley is just shy of 200k a year (check US News Best Jobs for salary info). For a physician, it's typically much higher.
Those are tough jobs. But does your definition of "qualified" include a graduate degree from an elite school? Keep in mind, the majors required even to apply have high attrition rates and lower GPAs than most other majors on campus. To get into an elite graduate engineering or CS school, you still need to get very high standardized test scores and have a strong GPA, and elite engineering or science programs typically have vastly higher attrition rates than law or med school (no joke, elite PhD programs have attrition rates between 35%-50%, whereas elite MD or JD programs have attrition rates below 0.5% (yes, one half of one percent). It's harder to get info on MS program attrition rates, the only one I found was behind a paywall and the summary didn't distinguish between elite and non-elite programs, but MS attrition rates overall were about 30%. MS programs are a bit shorter than Law school, for instance, but I consider the coursework to be considerably more rigorous (I actually did attend an elite law and an elite graduate engineering program, mine is only one data point, but I'd say law is like running 70 minutes at a 7mm, whereas engineering BS+MS is like running 50 minutes at a sub 6 mm. The first is pretty tough no doubt. But while the second is shorter, it is probably harder).
Then add in the really difficult interview process at elite software companies (to me, this is like taking a subset of the bar exam every time you change jobs), and overall?
Honestly, 250K is probably about where mid-career salaries would need to be for graduate degrees from strong programs in engineering to be competitive with the options available to students academically talented enough to do it.
Ironic, trying to leave a job because you're blue makes it harder to get another.
This holds especially true with startups that don't have the time or money to spend 6+ months getting you up to speed from zero on whatever they're working on. Hiring people based mostly on intelligence (what big firms like Google try to do) works when you have the capital to spend 6 months training them towards being productive.
With HN as the only sample, companies don't seem to be very interested right now in taking good engineers and molding them into great ones, or in building a business structure that can benefit from good engineers.
Instead, they're all competing for the top 1% of the top 1% of the top 1% -- and complaining that there aren't enough of those to go around, so the visa program needs to be restructured to draw that talent from the rest of the world.
shrug Honestly, I think the best thing you can do in that kind of environment is focus on looking outside the Valley, or do some freelancing if you think that would be a good fit, or start your own business if you think you can and maybe see about hiring the good talent that nobody else wants right now.
There's a few reasons why this is. The first is that startups are often, if not always, extremely bandwidth limited. It's hard to spend time doing the training, allowing a person to experiment, and giving the freedom and mentorship that is needed to take a good engineer to a great one, or even a mediocre engineer into a good one, when you have only a limited amount of time and limited amount of funds to do so with. Molding engineers is a very long term investment, which suits companies like Google well, but doesn't fit as well into much of the rest of SV.
The second is that even where you want to do such molding, you need the base set of great engineers to help with that. Harder still is finding the set of great engineers you know how to teach and train, and are interested in doing so. While there are some people who enjoy teaching as well as engineering, a lot of people in engineering don't like to or want to spend their time training someone else.
But -- again, with HN as my only sample these days -- this hiring strategy seems to be spreading beyond the relatively small number of startups working on technically challenging problems.
I have no interest in working for a company not willing to do this.
Also, you really think you're that good an actor interviewers can't figure out you're just testing the waters and aren't really motivated?
Since you also don't have a clue as to why you've been rejected, I suggest you're not very good picking up communication signals that aren't very explicit and verbal. Hell, that might actually be the reason why you get rejected in some cases.
Stumped me at first, too...not used to seeing it in this list but I guess I should get used to it :)
0. The companies the OP interviewed at, can afford to not give a benefit of doubt. If they hire a few less engineers, their revenues are not going to see a significant dip. Not true of startups. e.g. If an e-commerce startup misses a holiday season, they are done forever. They'd hence be more forgiving.
1. Valley thinks it is a meritocracy, but it is not. Valley is full of biases when it comes to engineering talent. (It's true for all meritocratic systems). They want certain kinds of engineers.
2. Regardless of the hiring market, the companies OP interviewed at, are not forgiving in their interview processes. e.g. use of substring() instead of passing indices in a string recursion will kill an interview with most interviewers. So will use of pow() in atoi(). And you won't know ever.
3. Interviewing is not a test. Interviewing is closer to a date, than it's to a test. There are no "failures" on a date. It's about whether that relationship clicks. "Hiring market" has little bearing on a date.
4. Even if the interviewing panel and hiring committee knows that there is a shortage of engineers, they cannot knowingly give a benefit of doubt to a candidate, or that starts to affect morale in the company.
5. They cannot afford to give a lot of time in interviewing. e.g. they cannot spend a week working with you and knowing you better. If they do that, they will never be able to hire enough engineers. They need them in hundreds a month. They hence have to have an interview process that's short. And short interview processes are bound to be imperfect.