Hacker News Reader

Bezos set a mandate to HR a few years ago that he wanted them to be able to hire a new grad without ever needing to speak to a human engineer. That is, he wants the entire interview process automated (specifically for new grads, at least for now).

What you experienced is part of their experiment in figuring out how to make this work. They've got a number of variations of interviews going on right now. I believe this is so that they can scale up as rapidly as they need to.

Apologies for the lack of citation but I don't believe this is something Amazon has spoken publicly about.

Oh that is great, robots hiring staff.

Not defending it, but when you and your fellow engineers are spending a majority of the time interviewing instead of programming, such a system is certainly tempting.

Oh I agree. I think if an engineer has to spend over 2-4h a week interviewing long term you are spending too much time on hiring.

A little break to talk to humans is good. Shouldn't be your main job, unless you work in HR or something...

Maybe that problem only impacts productivity significantly when attrition is high (suggesting that the problem might be with talent retention and not engineering effort spent on interviewing)?

Perhaps Amazon has an attrition problem - at the company I'm talking about, it's just extremely rapid growth.

The attrition problem is well known.

Have you tried hiring dev's lately? It's a employee's market. We've made offers to a half dozen people in the last 4mo only to be beaten out by other firms. One guy who turned us down had 12 offers.

Sure, you can compromise and take lower quality people, or pay more than anyone in your city, but if you want great people for top 20% of the market pay, it's a lot of work on the hiring side.

Pay more or work remote. You are likely limiting yourself to a tiny Geo area. No reason in 2016 we all need to sit in traffic to commute to work.

People already set up pre-filter "tasks" to qualify the competence of Amazon Mechanical Turk workers for their real work. There's probably some good data there that Amazon could use to do this pretty well, if they wanted.

Maybe they are starting a new service to spin up engineers on demand as part of AWS.

Ex amazonian here. About 5 years ago I was invited to beta test an online automated coding system, the stated goal of which was that upon passing, you would be given an offer for an SDE1 position. No webcam stuff, just checking your coding solutions. I don't believe that ever rolled out in that state.

As a proponent of work-sample tests over whiteboards, that would've been a positive step, honestly. Too often the actual coding project is just another hurdle to weed people out before the real test (whiteboarding); actually making offers on the basis of work-samples is pretty progressive.

Anecdotal evidence: I know some new grads who took this test when Amazon rolled out this automated form of hiring 2 years back. There were several crazy things with this process.. the questions in the test were changed only once a week and they did actually make offers to new grads after just the 3 hour online test. In dorm rooms where a bunch of students are applying for jobs at the same time, news travels fast. In short, there are a whole bunch of people working at Amazon who got their jobs by just typing out answers to questions they memorized.

This seems nuts, but it would explain some things.

Somehow I saw "fully automated hiring" and couldn't believe it - I just assumed it would be automated until the onsite part. If you're hiring 100% automated, I can definitely see why you'd be paranoid about cheating, but you'd better have an answer to memorization!

Do they talk to a human anybody other than the recruiter? Interviews aren't just for the company to evaluate the engineer, it's vice versa as well.

> without ever needing to speak to a human engineer

That would be one way to remove bias from the process.

I've often thought college admissions should be done in a blind manner. Applications go to a subcommittee that removes all race/gender clues from it, then the scrubbed applications go to the admissions committee.

Although I understand the desire to scrub race from applications, if a candidate has overcome some form of discrimination, that isn't something we should necessarily just write off or actively ignore. Acknowledging the unfair treatment they may have received in life helps level the playing field.

I applied to amazon last month, they asked me to do interviewstreet coding for 2 hrs. After that Recruiter didn't even have the minimum courtesy to let me know what happened. He simply stopped all communications with me.

Reflects their attitude of treating ppl as mere 'resources' , I would work for amazon if I have no self-respect.

After that Recruiter didn't even have the minimum courtesy to let me know what happened.

That's pretty common recently for companies. I'm not sure why.

Some claim it's them covering their ass thanks to the SUE SUE SUE culture of the US.

I understand that, but when it's a purely technical decision they could easily enough give you constructive feedback.

You missed these two edge cases. Your code crashes on certain inputs. This is very inefficient, you could have done XYZ.

You could automate chunks of this, and protect yourself from any discrimination lawsuits by just making any engineer who reviews the code have zero knowledge of the candidate.

The worst I've seen is a recruiter that didn't tell me I had been accepted. I found out when someone at the company followed up on why I hadn't responded to the offer.

I have no idea how a commission-based business manages to do something like that.

Are internal recruiters (sales people) commission based? Seems strange.

No, but lots of firms (this wasn't Amazon) hire external recruiters who are commission based, usually a percentage of salary for each candidate placed. Some also get "right to represent", where you can't apply through the employer directly once you've started a process with the recruiter.

Which makes this utterly weird - it was literally a matter of giving up (potentially) several grand by not forwarding an email.

I'm not sure why.

Because as a culture, we stop thinking of candidates as human beings the moment we decide we aren't hiring them?

Ex Amazon here: that's not supposed to happen.

okay

But it does all the time, of course.

I have just under ten years of experience and lead teams of developers, Amazon routinely spams me asking me to do 120 min online coding tasks before even a phone screen too. It's just fucking disrespectful of my time, to be honest.

I'm at a new job where the "old team" of two developers is being replaced by 5 devs... the old team had ~15 years of experience and can't code their way out of a wet paper bag.

Not saying anything about YOU... experience is important... but 15 years experience doesn't mean 15 years of good experience or lack of bad habits.

Yeah, definitely agreed. I just wanted to point out the person's "I opened the door to Amazon as a new dev" isn't purely limited to new devs perspectives.

So, what were they doing for 15 years and why weren't they replaced sooner?

Basically the company started expanding and their code base started falling apart at the seams.

Two coders that each had "silos" with wedges to keep the two sides communicating together. One did web side - ordering, registration, etc on a Webform MVC customized hybrid. The other did floor applications.

New customer? New database, website, etc. Sql statements? "If company a then select * from blah where field like '{text}';" everywhere. Why select *? Because the different code bases diverged... why like/text? Because sql injection doesn't exist. Almost everything text fields... 2 wide inventory fields that house more than 99 items... 10 wide inventory fields that house 2 items...

I will have some posts for TheDailyWTF once I get my feet a bit more wet...

As to why it took so long? They were able to keep it running with duck tape and bubble gum... once the company started expanding, the better of the two programmers knew they couldn't keep up and left earlier this year. The other is due gone soon... Good guy, but... unwilling to accept that his code is shit.

We probably disagree, but to me "code is shit" and "the company started expanding and their code base started falling apart at the seams" is a far cry from "can't code their way out of a wet paper bag". Sounds like they knew enough to patch together a system that made your company money for years. To me, that puts them squarely in the middle of "can't code their way out of a wet paper bag" and "good engineer I would trust to design my systems".

I'm not super experienced but I read enough to know bad code when I see it.

  * No separation of UI/Code. WinForms in all it's glory.    
  * SELECT * in code behind. Never anything else.    
  * WHERE field LIKE '{}' - never 'where field ='. Always like.     
  * {} is a from text entry fields. Sql Injection? Sanitation? Boundaries? What's that?    
  * Separate code paths for different companies because each customer had their own unique stack that diverged - Database tables, Winforms, processes. IF Company A then SELECT * FROM DBA.dbo.TblA WHERE FieldA = '{}' ELSEIF Company B then SELECT * FROM DBD.dbo.TblB WHERE FieldB = '{}'... etc.    
  * Copy Pasta all the way down.    
  * Never used source control until New Guard arrived (me being newest developer).    
  * Test environment? Waste of time... Everything done against production. I saw the old programmer jack up a sql query resulting in a data restore, and I've been here less than two weeks.

You can argue that what they did "works"... but you can fix a car with duct tape... then wonder why the door flies off at 65mph.

Trust me (as much as you can trust a random guy on the interwebz)... Their code is shit. Not "I'm an artist and think your artistry is shit" shit... but every bad idea you can consider in coding shit.

I'm not saying their code isn't shit, just that it is shit code that works (for some purposes at least). That is much different from not being able to generate code that works at all. I would say these guys can "code their way out of a wet paper bag". They will just make a royal mess doing it.

I guess it's just a difference of terminology and/or nuance in terminology getting lost in "text". Hard to show sarcasm or "air quotes" in a text post :)

Only in programming would this type of statement hold any merit. I was an air traffic controller for 10 years prior to becoming a data scientist. Experience is more than just being able to code (or do your specific job), it brings a wealth of knowledge you have to yet notice or realize.

> Experience is more than just being able to code

Necessary, but not sufficient. If you can't code you're worthless as a developer. You can be a great coder, but if your other skills are poor you aren't worth a senior engineer salary.

No one is saying the experienced individuals cannot code. Based on OP's comment I am going to assume he/she is young based on my personal experience hearing these types of comments throughout my career. They stem from only knowing one way of approaching a task, to which they respond negatively to anything different, particularly if it is outdated. Instead they should seek to learn from the experienced individuals and understand why they are solving the problems in that particular manner.

I've had points in my programming career where I felt completely burnt out. I would open up a text-editor and just stare at it. I didn't want to create.

But, separately from programming, I absolutely love teaching/mentoring. I found that, if I was helping someone with a programming problem, I could code just fine while burnt out. As long as someone else was doing "the programming"—the part involving wanting to create something and actually typing it—I was fine with them "borrowing" my knowledge and expertise in the form of doing all their design work, finding libraries and API functions for them, correcting their syntax errors, doing all their debugging, and basically every other part of programming that isn't typing words.

If someone handed me a college intern—or, hell, even a really passionate and patient elementary schooler—to serve as my "assistant", then I could make them appear to be a great programmer. If you hired me to wander around a team and pair-program with everyone, I could have a multiplicative effect on that team's productivity. But, by myself, I wouldn't be able to code for beans.

What do you call me?

Code Midwife?

What (lowest tier) management material SHOULD (IMO) be.

You might still need someone above you to function as the team's abstraction layer to the company at large, but it sounds like you'd be a great leader among the actual workers.

Justify to me why you shouldn't be replaced by someone who has comparable skills, but doesn't rely entirely on pair programming?

I can't hand you an important task and expect it to get done unless I give you a second resource?

You are talking about burnout. Would you really walk into an interview and respond to a coding question with "Oh, you'll have to write with me directing because I only pair program"?

I'm going to stand by my earlier statement. Being able to code is a necessary skill for a senior developer. Or any developer really.

1. Why are you assuming that my job description would/should be "engineer"? Why not, say, QA lead?

2. Why hand me the task? Why not hand someone else the task, and I'll wander in and make sure they get it done twice as quickly? Why does everyone need to be modellable as a task-queue that atomic problem-statements can be dropped into?

You don't expect, say, your office manager to program; but you do expect that, by hiring an office manager, more programming will get done, because now your programmers aren't running out to buy drinks for the fridge and toilet paper.

3. Remember that I did say that I could get work done by pair-programming with an intern, not an employee. The phrase "second resource" implies that you're imagining yourself handing me someone who you could get Hard Problems done on their own. My point was that, with a few people like me around, you could mostly just "hire" people (often for free!) who have no idea how to get Hard Problems—or even Regular Problems—done, and me and my type of person would guide them and the work would get done in the process.

This is usually known, in the trades, as an apprentice system. Apprentices do all the "work", you know. They're the hands that build most things that get built. Masters just stand there guiding those hands.

> Why are you assuming that my job description would/should be "engineer"? Why not, say, QA lead?

Because that's what this entire conversation is about.

Just the other day I interviewed someone with ~15 years of experience who struggled quite a bit with FizzBuzz. We ultimately decided to pass.

Last week, I interviewed someone about to complete a master's degree from Georgia Tech who also could barely do FizzBuzz.

What should we be doing to identify people who fail FizzBuzz but we should actually be hiring? Honestly the bar for our initial phone screens is very low, and yet experienced and well-educated people still manage to fail, sometimes spectacularly. FizzBuzz is one of the most important questions we ask because of this phenomenon.

I learned to program on the job, I have masters in economic (econometrics focused, which I was hired), but I am not sure how someone can't make there way through FizzBuzz. I am sure mine wouldn't be the best code written, particularly during an interview, but I could make it through the test.

Based on my experience as an air traffic controller which requires more tests than I care to state, when we would transfer facilities we were given oral tests to gauge our experience. We would mark down the areas deficient that needed review and check areas off where knowledge was deemed satisfactory. There would be zero air traffic controllers if we dismissed candidates answering one question wrong regardless of simplicity.

I totally get why someone would push coding tasks even on experienced devs - if you're meeting someone without a recommendation then history doesn't guarantee value.

But it still seems weird to push heavy coding sessions without even speaking to the candidate, and that seems weirder the more experienced people are. You might assume that a new grad doesn't care what work they're doing and can just be interviewed for a job in "software", but why throw somebody with 15 years behind them into a funnel without even talking about what it's a funnel for?

The classic phrase describing this is, There is a world of difference between 10 years of experience, and 1 year of experience 10 times.

They only spam you? I've been called, on my desk phone 4 times in the last year by their head hunters. It seems no matter how many times I tell them no, they don't get the message.

I danced with Amazon once (casually, I have zero desire to move to a Pacific Coast state), and had a similar "first step" experience, just with no webcam. Had they asked me to code on a webcam I too would've refused. At this point I don't recall if it was CollabEdit, InterviewStreet, or something similar (it's been some time and I deleted the emails), but I remember that if I tabbed out of the interview page at any time I would instantly fail it. And here I thought that was bad.... Leaning out of frame fails you? Wow.

For comparison's sake I'm an experienced dev and have been hacking on embedded Linux stuff for more than a decade, though I have doubts that's the trigger for "webcam or not."

Was there any data retention period mentioned regarding your interview? Do they keep those videos forever, or are they discarded as soon as they're reviewed (assuming they're not live)?

I didn't look too carefully. There were other options open and I quickly decided to pass on that much hoop-jumping for something not high on my list. The general implication was that it would just be to ensure you didn't cheat (so there'd be no value once your candidacy ended), but I don't remember any actual contract, and I assume that anything not stated to expire is kept forever.

Although being asked to code on webcam is obnoxious, it's probably also a symptom of cultures where people exploit every trick in the book to game university admissions, exams, job interviews, etc.

Absolutely. That's part of why I stressed that it didn't seem to be standard Amazon policy - it looked like some hiring agent had decided "No fraud on my watch!" and pushed through an aggressive policy to make it happen.

My complaint was that it seemed both ineffective (imagine candidates with the Big-O cheatsheet taped above their monitor) and obnoxious (I wasn't even going to talk to an employee until I jumped through a bunch of hoops). If you're going to be demanding (and uncommonly so), then security theater with no engagement with the candidate is a bad way to go.

>imagine candidates with the Big-O cheatsheet taped above their monitor

You need some interesting mental gymnastics to explain why this is even a problem, given that they could easily have the same cheatsheet taped on their cubicle wall after getting the job.

and you don't have it during the onsite.

That's true - this all assumes that the existing "no resources but a whiteboard" system is even worth reproducing.

> I was expected to be on webcam the entire time to verify identity and prevent cheating. No joke about the entire time part - there was a reminder to get any water or office supplies I would need before sitting down, because the interview would be terminated if I left the frame of the cam.

That's new and stupid.

I'd tell them to get fucked.

You're lucky we're in a market that allows you to make that choice.

My webcam doesn't work in Linux; and you won't find me programming in Windows under ordinary conditions. I guess I can't work at amazon?

I was living in a place with spotty internet, so I wondered about these issues. It was fine to code online, but if the video got choppy would they blackball me?

I've had a few rounds of interviews with different parts of their company. None of them ever involved a camera (with the exception of a 2-way video conference with someone in a different office, during an on-site interview).