carc

Everyone I know who works in AWS (several engineers, either closely or as acquaintances) say their experience was nothing like what the article described. My evidence is anecdotal, but so is NYT's.

I'm not saying who's right here, but I don't think you can say an assertion is considered corroborated because you can find anecdotes supporting it..

Well known, top tier tech companies. I won't get into more than that they're senior engineers (partially because I don't know that I can answer that with more specificity). They all have 10+ years of experience and are typically tech leads on their teams.

Equity is almost always worth close to zero? You realize at publicly traded companies, it might as well be a cash bonus because you can instantly cash it out the second it vests, right?

FWIW, I know senior engineers that chose the technical route rather than manager route, who make absolutely ridiculous amounts of money. Like close to 1,000,000/year including equity. I don't know any non VP level people making anywhere close to that.

Obviously this is anecdotal though.

Maybe his/her experience in the US is so very different than mine, but I feel like he/she's grossly over exaggerating. I've lived in 4 cities in the midwest and west coast and would not hesitate to call the police for that reason.

The insecurity is strong with this one. You're projecting that the person's literary references are "name dropping things in largely irrelevant contexts". There is no basis for this assumption, other than your obvious bias to jump to the conclusion that this person is elitist and goes out of their way to seem elitist. Why? Are you sensitive that you didn't get into a school like MIT? Neither did I, but nothing he is saying comes across as even remotely elitist to me.

You're really just coming across as a jerk.

Not necessarily disagreeing, but I'd like to point out that you your logic is based largely off of survivor bias. You've never seen an entire startup fail because of bad engineering probably because they never get to the point of relevance necessary for you to have heard of them.

To use your example of yelp - it might not be a feat of engineering, but it's well engineered enough to not get in the way of the problem it solves.

No one is claiming that makes you a bad programmer. However, if you got this as a problem to solve and your response is "I don't know" and you stop there, then you are a bad programmer. As I've commented elsewhere, the interviewers want you to ask clarifying questions. Those are often just as important as the code itself. Once you've nailed down the definition of inverting a binary tree (maybe it's just switching left and right node pointers), coding will be trivial. It's much like getting sufficient detail on a feature request before starting to work on the feature.

The question is definitely not described in sufficient detail. That's usually on purpose. The interviewer WANTS the candidate to realize that too and ask the questions necessary to actually understand what they are trying to solve. It's very analogous to nailing down specifications on a new feature or something like that.

Well one of the points of an interview is to see how (or if) the person goes about understanding problems the context of a given problem. So presumably it's unclear to inverse a binary tree to you - that's why you ask clarifying questions. Perhaps you draw what you think it means and ask if that's correct. What will be considered the root if it's just a matter of reversing the direction of the pointers? Stuff like that. Google isn't dumb, and I'd be willing to bet that it's questions like those that are just as important than coding the solution (since it won't be that hard once you clarify the problem).

Here's an example to think about: You're asked to write a method that, given a word and a book, will return the number of times that word appears in the book. A logical way to continue would be to (after clarifying what a book is represented as and things like that) write a simple method that iterates over the book and counts how many occurrences of the words there are, and returns that. Is that a good answer? No, because you failed to ask questions like whether the method might be called many times for the same book (in which case it'd be better to build a map of words to occurrences). Or maybe the interviewer would say that it'd only be called once per book, in which your solution is perfect. The bottom line is that coding isn't as important as the way you approach the problem to the interviewer.

The best analogy I've heard for this: If you wanted to judge whether a person was a good chess or card player by seeing just a couple moves or hands - you wouldn't just look at the couple moves/hands played - it'd give you very little information. But if you asked the player to explain their whole thought process for the moves/hands, you'd get a much better indication of how good or mediocre that player was.

To be fair, inverting a binary tree is a pretty easy question. Google also tells you BEFORE you start the interview process that it'll be very data structure/algorithm oriented and asks that you please prepare (and take as much time as you want doing so). They even say that they want you to prepare because they know a bad candidate that prepares can look better than a good candidate that doesn't prepare - then want all candidates on a level playing field so they can make accurate judgements. All that being said, I still think that there is lots of room for improvement in the process.

edit: really good english skills

I think you're a bit off base about the implementation level not making much of a difference compared to the strategy level. Have you never seen engineers essentially fail at building a spec because they couldn't implement something well enough? I've seen a team of full stack developers build an ambitious web UI with lots of complicated data visualizations/animations/interactions/etc. There were tons of performance issues because they did not understand the browser/javascript/css well enough to optimize things. A front end pro needed to go in and salvage the whole thing because it was not usable.

Another anecdote I personally have is a friend who is obsessed with being an entrepreneur. He keeps coming up with these ideas that are actually pretty decent, but he tries to build them himself (he's self taught but still doesn't really know what he's doing) and what he ends up with are things no one would ever, ever use twice.

Strategy is nothing without good implementation, and implementation is nothing without good strategy.

Completely agree. I switched out of the finance/accounting industry to be a software developer because I fell in love with coding. I would not have been able to learn the skills to make that switch (while already working full time) without MOOCs and other awesome online resources to guide me along the way.

MOOCs help us reach the goal that any motivated, bright individual can learn the skills necessary to reach their potential. Obviously we're still far away from that - but free online courses are certainly one step in the right direction.

This is fantastic. I switched careers a couple year ago (used to be a CPA) and am now a very happy software engineer at a tech company. These sorts of resources are great.

I want to iterate, though, for people without CS degrees that doing something like this will NOT make it easier for you to get a software engineer position in and of itself. The skills you learn from things like this will though - so use this to be able to learn what you need to know to build cool side proects. In my experience, companies will usually ignore your lack of CS degree if you have projects that demonstrate your knowledge. I personally have many projects using some high level languages doing things like web apps or visualizations, and I'm also working on an emulator just to teach myself more about computer architecture. It helps that even though my job has me working very far from the hardware, I still find all this stuff fascinating.

I've also had a bad experience with hired. Seems like they do not run a tight ship at all.

Getting unnecessary tests can do more harm then good. Please don't try to get every test 'just because'. Here is a good resource that recommends what preventative measures are recommended for people of different age groups and such (recommended by my MD girlfriend):

http://epss.ahrq.gov/PDA/index.jsp

Here's what she pointed me to:

http://www.uspreventiveservicestaskforce.org/Page/Topic/reco...

Some of these aren't even up to date. Lets stop acting like we're health experts here. If your doctor is still making you do "turn and cough", then your doctor is using out of date practices (source: my GF is a doctor). Similar to another person's post above, she cringes at posts like this. You SHOULD go to the doctor to get check up each year, but you should not just go get every test under the sun just in case. There's a reason when you go in for your yearly check up, the doctor does what they do. Perhaps it's more important in this discussion to say that there's a reason your doctor doesn't do every test under the sun on these checkups.

Which is what perpetuates these types of things to continue to happen.

I find it interesting that some people have a problem seeing the difference between willingly and knowingly giving data to a corporation in return for a service and a law-enforcing organization using that data without permission

As someone who is self-taught/switched careers into a job as a software developer but mostly works very far from the machine/OS, I found this interesting and really educational. Since I rarely need to do system work, I accumulate most of my knowledge of how the OS does its jobs from articles like this. Thanks!

Sure stack overflow isn't perfect, but shit... Do you know how much productivity would be lost on a global scale if the site suddenly disappeared? I still use it in some capacity almost every day. Sure some of the rules might be nit picky and can be obnoxious sometimes, but nothing is perfect.