4 ms·

Imagine you are talking about an Amazon SDE (software development engineer) or similar role, and not just the warehouse workers, the latter of which I would ser

Imagine you are talking about an Amazon SDE (software development engineer) or similar role, and not just the warehouse workers, the latter of which I would seriously hope could care less about your advanced education. My experience with Amazon's SDE hiring process has been pretty disappointing. It's a lot like Google's, where they bring in a bunch of devs and managers to tech-screen you, with nothing more than a "raising the bar" afternoon course in interviewing experience under their belt. If they can see themselves in you, maybe a younger version, then it's a pretty good bet you'll get an offer. If not, they're perfectly happy to waste your afternoon, and maybe get back to you with a no. Ask yourself: "How you could tell if someone, who's a more experienced developer than you are, is more qualified than you are?" If you don't have a good answer, that's ok, but realize the ones making that decision are in exactly the same boat. The problem with Amazon's "bar raiser" approach is that it ignores that your average rank-and-file employee does not know how to value a candidate. When you hire only the best, and you have no idea what that actually means (the best are who work here already?), then it becomes a self-fulfilling tautology. Lots of false negatives, and probably some false positives as well. If you follow history, Sears was probably like this at some point in time. TLDR: No.

halfnibble 8y ago
Thank you for the response. That's good to know. I don't understand why interviewing isn't just, "Did you work yesterday? Great. Open up your laptop and show me the code you wrote yesterday."
- mchannon 8y ago
  A few reasons it's not like that: 1. The person interviewing you is often less experienced and skilled than they let on. They can't make sense of your code, not because it's not any good, but because they don't code at your skill level in that language. 2. Showing off code, while making for a better interview than the behavioral stuff that passes for interviewing at the bigs, still isn't all that great a tool. There are a lot of people who might show it off, and might even talk the talk, but who didn't write all of it and might not even understand it. 3. The code is secondary to the job. How you come up with the code is primary to the job, and showing off code doesn't show off how you came up with it. Even the best code ever would be a bad hire if it took you six months to come up with it or annoyed your fellow devs for months in coming up with it. 4. The way you're used to coding will be different than the culture of the new firm. It just is. If hired, you're going to adapt to it, not the other way around.
  - halfnibble 8y ago
    Ok. How about, "Show me your personal git commit log from yesterday?" That deals with most of 2 and 3—granted not all of the scenarios. As for 1, there are many languages and frameworks that I wouldn't be able to say if they used best practices for, but I think I could generally recognize good vs. bad code with no prior knowledge of the language.
    - gamblor956 8y ago
      Most people don't make commits to their "personal git" every day. Or even every week. Or hell, ever.
- QuinnyPig 8y ago
  Because "show me what you wrote for your employer" gets you blacklisted and theoretically sued?

halfnibble 8y ago

Thank you for the response. That's good to know. I don't understand why interviewing isn't just, "Did you work yesterday? Great. Open up your laptop and show me the code you wrote yesterday."

mchannon 8y ago
A few reasons it's not like that: 1. The person interviewing you is often less experienced and skilled than they let on. They can't make sense of your code, not because it's not any good, but because they don't code at your skill level in that language. 2. Showing off code, while making for a better interview than the behavioral stuff that passes for interviewing at the bigs, still isn't all that great a tool. There are a lot of people who might show it off, and might even talk the talk, but who didn't write all of it and might not even understand it. 3. The code is secondary to the job. How you come up with the code is primary to the job, and showing off code doesn't show off how you came up with it. Even the best code ever would be a bad hire if it took you six months to come up with it or annoyed your fellow devs for months in coming up with it. 4. The way you're used to coding will be different than the culture of the new firm. It just is. If hired, you're going to adapt to it, not the other way around.
- halfnibble 8y ago
  Ok. How about, "Show me your personal git commit log from yesterday?" That deals with most of 2 and 3—granted not all of the scenarios. As for 1, there are many languages and frameworks that I wouldn't be able to say if they used best practices for, but I think I could generally recognize good vs. bad code with no prior knowledge of the language.
  - gamblor956 8y ago
    Most people don't make commits to their "personal git" every day. Or even every week. Or hell, ever.
QuinnyPig 8y ago
Because "show me what you wrote for your employer" gets you blacklisted and theoretically sued?