> No matter how I try to justify that this difference doesn’t matter in the grand scheme of things, the truth is that, having the option to eat lunch at office & availability of on-demand snacks throughout the day has boosted my productivity.
Must be nice. My company hasn't provided free breakfast, lunch or dinner in years.
My experience says that a communal lunch is extremely valuable in building a sense of community. Companies can get a better cohesive workforce by providing lunch options that bring people together.
I always skip catered meals for the same reason. I cannot stand forced socialization. Brain must turn off for a bit, and socializing is hard work (for me).
I'm an introvert and doing just fine, thank you very much. The fact you assume one needs to get out of his or her comfort zone or they will "get taken advantage off" and have "worse career progression" is too broad of a brushstroke.
>If you don't push yourself outside your comfort zone you wont grow - Oh and you will get taken advantage off and have worse career progression.
Or, he's more likely progress to a job where there is no patronizing idiot trying to ham-fistedly force him into non-work related socialization. Seriously, don't people like that have their own lives they want to live?
I have way too little free time to waste it talking to people I spend 8 hours per day with already. There's plenty of time to talk to those people during work hours, at least I get paid during those hours as well.
I gladly exchange empty blah-blah time about yesterday evening/weekend/whatever for a workout session during lunch. Eating by the desk if very much fine by me, it matters more to me what is on the plate (ie veggies, salads and avoiding junkfood generally). And its a great time to turn off the brain and focus just on exercise.
Protip: schedule your workouts ~2 hours after lunch. This achieves 2 things: staves off the afternoon mental fog, and ensures that the nutrients in your bloodstream go towards something useful.
Right? Some of the comments here make it seem like we're on different planets. "Can't work without on-demand snacks!" Silicon Valley has definitely "branded" their employment, and millennial are buying in.
Meanwhile, young people are burning themselves out at unprecedented rates.
> Meanwhile, young people are burning themselves out at unprecedented rates.
Indeed. And they aren't making enough money to buy a home. Then, people, mostly boomers, will wonder, "Oh, gee. When I was their age, I could afford college, land a high-paying job right after school and buy my first house before I was 25. How are they not doing the same?"
Why make lunch when you know you'll get it for free. And, if a company has the finances to provide free meals _every_ _day_, then that's one you'll likely go to.
Regarding the Amazon social side (which often gets a bad rep), in our org we have office happy hours twice a week with beer, occasional games and good food. People are friendly, get to know each other across teams and the culture is fairly relaxed. No team ceremonies or implied obligations.
The problem with workplace bonding over drug use is that it either causes people with substance abuse problems to either self-select out of participating, or abusing substances, or being stressed out by them being consumed in the workplace.
I say this, as a drinker, who does not have a substance problem.
It's one thing if the team occasionally goes out for an activity, which culminates in drinks. It's another thing when the thing people do every Friday afternoon is drink.
Good post from Divij. I worked at amazon a decade back and my 2 biggest learning there were from (1) building large scale infrastructure components (2) DevOps is an inherent responsibility of Dev.
I like the post, but would like the OP to do a recap after working 12/18 months or 2-3 teams in Uber. 1 month is too short of a time to have meaningful outlook of the current situation.
How often do you typically switch teams at a Big N company? I recently graduated and started working at a large engineering company and it seems that most of my team members were hired on to my team and have stayed there since.
It depends, In my last big company (>2000 tech + product), engineers would switch teams every 15 to 18 months on average. Ofcourse there were more desirable part of the organization, where switches would be much less.
I’m at Amazon now. None of the teams I’ve been on have had an absurd on call burden but I do know of teams that do (not in my org) and therefore struggle with high turnover (people don’t really leave Amazon burn just switch teams in my experience).
Overall, it’s made me better leaps and bound as an engineer prior to when I joined. Over the years when I’ve picked up a book on scalable systems or design, I easily identify the patterns of failure or whatever topics mentioned because I’ve had to deal with them on the job.
Amazon isn’t for everyone. My stress and anxiety level is generally pretty high.
I work with really really really bright people (compared to my previous companies) but being extremely intelligent doesn’t speak to your character. As a matter of fact, really intelligent people with bad character are 100x worse than Todd from my previous company who did very little work and was merely collecting salary.
If you have an opportunity to work for Amazon, at least as an SDE I say definitely go for it. But, if you want a relaxed 8-5 job, it may not be the place for you. The teams I’ve been on are full of overachievers but too many of those people in one room isn’t always a good thing.
More people need to realize that a company is employing you so you can out earn your salary. If you think you are making more than you make for the company, you’re expendable.
Well, there is nothing I would dispute about this claim, this is a capitalistic world after all.
But as regards to the comment about being 'expendable', I am certain to get a job out side of Amazon pretty easily depending on my own skill. In other words, this is a market that both companies and employees can play.
Amazon's strategy isn't focused on retention of long term employees, then it is its own choice, there is always a trade-off.
It's also a short-sighted approach. What can end up happening is hiring a lot of college grads to fill head count and get stuff done. And while they try their best, they lack experience or aren't mentored/trained because of a shortage of senior engineers.
So now your product needs a bigger team to handle it and the ops load increases or feature work slows. So now your senior engineers get frustrated and leave/switch teams. So then you hire more college grads and throw them into the meat grinder... meanwhile your products suffer [0] and the competition is catching up.
BTW, checking that sub-reddit is a good idea before joining an established team.
> But, if you want a relaxed 8-5 job, it may not be the place for you
I've been at Amazon 7 years. I mostly work 9-5, plus offset (ie, if I get in at ten, I leave at six). My biggest barrier to working those hours is that I like what I'm working on.
> If you identify an engineering problem that you want to tackle and it would benefit Uber, the management is very likely to allow you to spend time in solving that problem even if that problem scope if outside the team’s ownership.
My Amazon interview was the most ridiculous experience I have ever had interviewing anywhere. That round I got offers from Facebook (insta), Google (team matching said maps), Uber (eats) and a few others but not Amazon. At Amazon, I pulled out and declined with an email to my recruiter from the lobby of the building at the end of the day. My interviewers were broken up into two categories: Engineers who didn't want to be there, and terrible mid level managers that quizzed me on memorization of their company competencies. One of the managers was clearly reading his questions from a list, and did not care at all about what I had to say. That, combined with the sad office (manager's share a tiny office, everyone else sits in grey cubicles without sunlight), and no food or snacks (it matters) really broke it for me.
All that aside (I am willing to chalk it up to luck, god knows my first (failed) round at trying to get into Google went terribly), Amazon clearly does not compete by hiring the best engineers. Rather, they compete by throwing money at the problem and undercutting everyone else, getting by with mediocre engineering.
A job interview is a deeply personal process. If you get someone who is disinterested, which you can easily tell if A. They read from a sheet and B. Don't listen when you answer, that says a lot about the company you are interviewing for.
I think you might put a little too much stock into your work-life if you consider a job interview "deeply personal". You're looking for an employer, not a soulmate (and it's not like Amazon is some unknown quantity).
It would have been better worded as "fundamentally personal". I didn't mean it in the sense that you will talk about what your most secret desires are, I meant it in the sense that you as a person need to get a feeling for the kind of culture/people that the company you are interviewing at fosters. You can't do that without any form of personal connection, unless of course that's something you enjoy. All the more power to you in that case, but it's not for me and I think also not for most people.
Based on this, and the consistent theme that seems to run through the rest of your comments, it seems to me that all of these companies could stand to do more to assess the character of their interviewees. Reading this in the most charitable way I can still results in it coming across as arrogant, attention-seeking, and as you've made it to age 22 having experienced no hardship at all.
I am surprised you learned so much about me from my comment! Let me clarify a little: I am significantly older than 22. I had to drop out of university to provide for my ailing parents and to support my sister. I've spent more than a few nights sleeping in my car around the corner from whichever office or university I happened to be attending at the time.
Really? That theme of generosity is notably absent from most of your comments unless they glorify Google. A positive impression of someone is hard to come by if they seem inordinately eager to jump in on threads that paint non-American engineers in a positive light, or that dismiss racial discrimination as a negative thing.
One of my friends has a saying that is very difficult to translate to English, but a fair translation would be "everyone has different memories of the party". The point is not to use anecdotal evidente as absolute truth.
Maybe a few rounds of interviews with each company could help to paint a better picture. Personally I could say me interviews with Amazon have been some of the most pleasant I had so far, while other companies have arrogant engineers that ask incredibly hard algorithmic problems that you would hardly ever find in real life.
Just because I had one bad interview doesn't mean I should write off the entire company.
While many may hate Ruby Rails for whatever reason, Basecamp's way of operating business has been fascinating to me, and DHH has pointed out many obvious flaws in the way today's business operate that no one bothers to speak about it. They have been talking about hiring [1], and more to come in their podcast ( Not sure if that is out yet ).
I recently had an interview with a 5 day code assignment to build services, perform data transform against several competing requirements, and some other things. I provided lots of code comments, interactive documentation, test data samples, and a detailed readme file about as long as the code to explain how I went about things and how to reproduce my results
The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation. I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions. Felt like they were just wasting my time.
All my big GitHub projects are on my resume. They could have given me nearly identical feedback by looking over my GitHub projects and not waste either of our time with this ridiculous assignment.
On the upside I view this as a somewhat positive thing because if their developers can’t read code then I probably be miserable there.
If you don’t write unit tests on an assignment like that, you’ve pretty much failed. I made the same mistake in a similar situation with a different company. It’s tough because the expectations aren’t spelled out clearly, but unit tests are non negotiable.
[speaking personally, not on behalf of my employer]
I suppose interviewers regularly fail people for less than this but it's just ridiculous I bet if the interviewee is told to add unit tests the majority could and would
It's not a test of skill so much as a test of expectation, hidden expectations are the worse to deal with in an interview
If we're going to wag the testing finger and say always unit tests then why not always generative tests? They'd always test more inputs, why not spin those tests infinitely? Did they test in the repl? why not always mutation testing? why not always integration testing?
I don't think people like to realise that testing is a spectrum of confidence you'll never reach 100% nor should you expect to
Dealing in bullshit absolutes here is stupid, talk to your interviewee about what they could do to ensure their code complies with its intent instead of springing hidden expectations after the fact
I prefer to perform functional tests in my automation, such that you prove the application does what it claims instead of testing the internals to prove a function outputs the right data type. This seems like unnecessary tech debt that can be solved for in smarter ways, like a strongly typed language.
But had they included this as a requirement I would have provided it. I am not in the habit at guessing informal unspecified requirements. If that is an indicator of their internal communication then I suppose I am glad I failed.
All code being in one 750 line file is a bad thing.
It would never pass a code review where I work.
I would not really care if it worked or not and have
the team or developer come back with a broken down
version. (which if the code is structured well inside
a single file should be very fast to accomplish)
Splitting a 750 line file is not a readability improvement, if all the logic is related to and part of a single task.
Splitting code across multiple files when there's no actual reusability or abstraction driving the split makes it harder to follow the flow of logic. In particular, 750 lines is not so much that there's obviously a missing abstraction lurking there.
The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation.
These days a coding test has a pretty standard minimum set of features to get a pass, and they include reasonably well organized code and having some tests. If you're working alone those are less important but as soon as you join a team they're critical.
I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions.
When I do technical interviews I assume the candidates code works (and it often doesn't, but that's not the point). I review it first, then I see if it meets the acceptance criteria. If your code isn't the sort of code that would be acceptable in the organization it doesn't matter if it works.
I would rather reject a candidate on quality than failing the test. Also, occasionally, if the candidate has made an obvious error that stops their code working but it's clear they write great code I might still recommend making them an offer.
I don't want to be argumentative at all. I find what passes at one company doesn't at another and it's generally an interpretation of style that can be conformed to. For example, I am of the leaning that one line should do one thing only, and should be explicit -- which is different then many modern practices. Another example is array manipulation which, depending on the operation modifies in place and I reassign for clarity.
Does that make me a bad engineer? No. It makes me experienced. If any of those things aren't wanted at a future employer I can change to match the style.
To reject based upon that when the style isn't defined by tooling is weeding out great people who may not confirm but have the ability to.
Very true. I have been working at startups for a while as a hiring manager and one of the skill sets I've had to develop is finding good people who have been passed on by FAANG or who come from a non traditional background and never would make it past there filters. Simply because we can't afford the salaries, but still pay six figures to non bay area employees. It's been interesting watching the "I should work for a startup" to "I should work for FAANG" over the past decade.
I think it's do to two reasons: 1) salary at FAANG can be 2-3x what a startup can offer, granted that's in the Bay Area; and 2) there's been more then a few examples of equity not being structured in a way that is beneficial to early employees. Sam Altman even has a blog post that says startup equity needs a revamp.
> When I do technical interviews I assume the candidates code works (and it often doesn't, but that's not the point).
Why is that beside the point?
For me, as the candidate, if the evaluation is only subjective nonsense then the more important objective qualities aren’t valued in the exercise and probably in the office. That is a huge turn off to me.
Outside of interview conditions I expect people to be part of a team, which means they don't have to be able to solve the entire problem on their own. They can (and absolutely should) ask for help and advice from the other team members.
There is never a point in real work where it's all on one person. So the same should be true for candidates doing technical tests. If you demonstrate you can approach a problem well, you can write good code to implement the parts you could solve, but the end result isn't a working test then that's fine. In the real world you'd have had other people around to help with the bit you couldn't do.
But this isn’t outside of interview conditions. In a production environment I would write production quality code.
At any rate now I know for next time precise questions to ask to ensure we aren’t wasting each other’s time. Had I known this before the code test I would have politely excused myself from consideration.
Not sure I understand your point here. You're saying that in a production environment you'll write production quality code, but if you ask about the code style before the technical interview and are told to write production quality code you'll excuse yourself?
That just implies you can't, or can't be bothered, to write high quality code in a technical test. Why would you imagine an employer is going to overlook that and think you'll write better code if you get the job? That makes no sense.
But, I was never asked about code style. I was asked to solve a well defined problem and only graded on unspecified code style.
Code style is subjective nonsense. If it’s that important provide a Schema or lint rules. High quality code solves a problem against a variety of objective measures: performance, complexity, instruction count, portability, and so forth. Things that can be measured with numbers.
The inability to differentiate subjective criteria from objective criteria is extremely immature. You wouldn’t write a contract like this or treat a business partner like this so why would a company treat a candidate for employment like that?
Some aspects of it are. I don't give a damn about tabs versus spaces, semicolons, etc. A decent code formatter fixes that sort of thing so it doesn't matter.
I absolutely do give a damn about things like breaking code up in to easy-to-grok modules, writing testable blocks, etc. In your response a few posts back you said "The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation." That demonstrates to me that you can't write unit testable code, because you didn't write any tests and your code isn't broken up in to units. I can't write tests for a monolithic file like that without importing all of it and potentially getting side effects like prototype poisoning or globally scoped variables. That is a good reason to reject you as a candidate, and why you shouldn't write code that way.
> That demonstrates to me that you can't write unit testable code, because you didn't write any tests and your code isn't broken up in to units.
The code is testable. I provide data samples to test against and documentation on forming original new data samples for further testing. This manner of testing is easily automated.
I explained my thoughts on this and various forms of functional testing before receiving the assignment. To me this means they either did not understand test automation or they needed internal unit tests to make sense of the logic even though I provided copious code comments and documentation.
Again, it reaffirms they either cannot read code or didn’t bother evaluating past code style. If I were happy with that level of immaturity I wouldn’t be looking around. I am glad though to have discovered that immaturity during the interview process before leaving my current employer. I just wish they didn’t waste my time with an unnecessary assignment when they could have formed identical conclusions by looking at my GitHub projects specified on my resume and discussed in detail during the prior interview.
My final thoughts then were that they either lied about their conclusions, in that they used code style but really it’s that they cannot read code, or that my time isn’t valued (thus I am not valued).
> I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions. Felt like they were just wasting my time.
I don't know anything about where you interviewed and of course this may not at all be true for them, but bear in mind that the point of home assignments is rarely "does it work?" That the candidate followed instructions and that the project "works" is expected. What many companies are looking for is seeing how you document, how you organize, how you test.
Again, I don't know what happened in your specific case. Just a heads up that writing tests, documenting and writing good commit messages are usually what people look at first when evaluating a home assignment.
If your doing competency based interviewing (which Amazon appears to be doing) its on you to demonstrate the competencies.
But it does seem that Amazon's interviewing is not the best - I have worked for places where you had to take and Pass a 2 day residential course before you where allowed to interview candidates.
It's a half day course at Amazon to be an interviewer, followed by a bunch of "shadowing" interviews and phone screens. To be a head interviewer (bar raiser) requires 100+ interviews under your belt, a lot of additional training, and a lot of further shadowing.
The fact is, it takes a certain personality to be really good at interviews. (I suck at it because I like everyone, too optimistic.)
> Amazon clearly does not compete by hiring the best engineers. Rather, they compete by throwing money at the problem and undercutting everyone else, getting by with mediocre engineering.
Evidence please. Amazon has a lot of freaking fantastic engineers and "throwing money at the problem" is definitely not how they solve problems.
It's a huge company and not every single engineer is excellent and there are definitely rotten bits but that's true of _every_ company that's large enough.
Hello
See how you can start making a steady passive incomes of $100 daily on virta stock trading without you risking your money and your investment visit the website here http://www.virtatrade.com/index.php for more details
Build a culture of fixing the alerts and pages. Having the people who write the software answer the pages builds in a closed feedback loop, incentivizing reducing the operational burden.
If an external Ops group takes the burden of responding to pages, there is no feedback loop nor incentive for those writing the software to reduce the burden!
>> Having the people who write the software answer the pages builds
This is the Stockholm syndrome you often see in ex-AMZN people. Having devs burn themselves out within 2 years in insane oncall rotations is just not very smart. Nor is it the only way to do it.
>> there is no feedback loop
Not if "external Ops group" can refuse to support your shit if it sucks. That's how Google works: your service has to pass PRR (production readiness review) by SRE before SREs will agree to support it. If your service begins to deteriorate over time, SREs can dump it right back in your lap to fix, and require another PRR before they'll support it again.
And you don't hand the service over to SREs, there are still devs oncall, but the load is much ligher, and dare I say, SREs are much better at running infrastructure (and building tools to help run it reliably) because it's their job. They're also in multiple geographic zones, so at night an SRE in e.g. Zurich can take care of simple issues (or escalate to a SWE if it's something gnarly).
And I don't know how it is now, but SWEs used to get extra pay while they are oncall.
When they dump it back in your lap, does that mean you're now on-call for your own service again? I was just curious how that looks, do you get an email saying you're back on the hook for a service because it's broken too many times?
I've worked in an environment that was similar, but the difference was that the support folks haven't got enough power, or technical knowledge, to effectively manage the interface. I think that ops groups are the way to go, and devops is not an enterprise or long term ready prospect.
Works great if you create both the feedback loop and the culture of fixing the alerts.
But I've had friends work at companies that said "That monthly 3am page costs us 1 hour of overtime, fixing it will take 80 hours, that's a weak business case so the fix is a low priority" - i.e. the feedback loop without the culture of fixing the alerts.
Of course, a sane company would account for employee retention costs in that business case, and wouldn't let their codebase get into a bad enough state that fixing bugs was infeasible. But when you're at the job interview stage, companies aren't likely to be upfront about such things.
94 comments
[ 3.7 ms ] story [ 165 ms ] threadMust be nice. My company hasn't provided free breakfast, lunch or dinner in years.
I need to GTFO and have some time to myself. 8 hours is a long time.
I have done that in the past when a very good developer was working on some cool tech I suggested that he present to our team meeting.
Oh, god. My introverted self wants to slap you.
Or, he's more likely progress to a job where there is no patronizing idiot trying to ham-fistedly force him into non-work related socialization. Seriously, don't people like that have their own lives they want to live?
I have way too little free time to waste it talking to people I spend 8 hours per day with already. There's plenty of time to talk to those people during work hours, at least I get paid during those hours as well.
Good luck having a career much past 40
Meanwhile, young people are burning themselves out at unprecedented rates.
Indeed. And they aren't making enough money to buy a home. Then, people, mostly boomers, will wonder, "Oh, gee. When I was their age, I could afford college, land a high-paying job right after school and buy my first house before I was 25. How are they not doing the same?"
I say this, as a drinker, who does not have a substance problem.
It's one thing if the team occasionally goes out for an activity, which culminates in drinks. It's another thing when the thing people do every Friday afternoon is drink.
Overall, it’s made me better leaps and bound as an engineer prior to when I joined. Over the years when I’ve picked up a book on scalable systems or design, I easily identify the patterns of failure or whatever topics mentioned because I’ve had to deal with them on the job.
Amazon isn’t for everyone. My stress and anxiety level is generally pretty high.
I work with really really really bright people (compared to my previous companies) but being extremely intelligent doesn’t speak to your character. As a matter of fact, really intelligent people with bad character are 100x worse than Todd from my previous company who did very little work and was merely collecting salary.
If you have an opportunity to work for Amazon, at least as an SDE I say definitely go for it. But, if you want a relaxed 8-5 job, it may not be the place for you. The teams I’ve been on are full of overachievers but too many of those people in one room isn’t always a good thing.
Yep. Amazon is not subtle and demands its ROI on you to be HIGH.
But as regards to the comment about being 'expendable', I am certain to get a job out side of Amazon pretty easily depending on my own skill. In other words, this is a market that both companies and employees can play.
Amazon's strategy isn't focused on retention of long term employees, then it is its own choice, there is always a trade-off.
So now your product needs a bigger team to handle it and the ops load increases or feature work slows. So now your senior engineers get frustrated and leave/switch teams. So then you hire more college grads and throw them into the meat grinder... meanwhile your products suffer [0] and the competition is catching up.
BTW, checking that sub-reddit is a good idea before joining an established team.
[0] https://www.reddit.com/r/aws/search?q=sucks&restrict_sr=on
I've been at Amazon 7 years. I mostly work 9-5, plus offset (ie, if I get in at ten, I leave at six). My biggest barrier to working those hours is that I like what I'm working on.
The above sounds very refreshing and open minded.
All that aside (I am willing to chalk it up to luck, god knows my first (failed) round at trying to get into Google went terribly), Amazon clearly does not compete by hiring the best engineers. Rather, they compete by throwing money at the problem and undercutting everyone else, getting by with mediocre engineering.
I think you might put a little too much stock into your work-life if you consider a job interview "deeply personal". You're looking for an employer, not a soulmate (and it's not like Amazon is some unknown quantity).
Maybe a few rounds of interviews with each company could help to paint a better picture. Personally I could say me interviews with Amazon have been some of the most pleasant I had so far, while other companies have arrogant engineers that ask incredibly hard algorithmic problems that you would hardly ever find in real life.
Just because I had one bad interview doesn't mean I should write off the entire company.
[1] https://m.signalvnoise.com/its-high-time-to-rewrite-the-hiri...
I recently had an interview with a 5 day code assignment to build services, perform data transform against several competing requirements, and some other things. I provided lots of code comments, interactive documentation, test data samples, and a detailed readme file about as long as the code to explain how I went about things and how to reproduce my results
The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation. I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions. Felt like they were just wasting my time.
All my big GitHub projects are on my resume. They could have given me nearly identical feedback by looking over my GitHub projects and not waste either of our time with this ridiculous assignment.
On the upside I view this as a somewhat positive thing because if their developers can’t read code then I probably be miserable there.
[speaking personally, not on behalf of my employer]
It's not a test of skill so much as a test of expectation, hidden expectations are the worse to deal with in an interview
If we're going to wag the testing finger and say always unit tests then why not always generative tests? They'd always test more inputs, why not spin those tests infinitely? Did they test in the repl? why not always mutation testing? why not always integration testing?
I don't think people like to realise that testing is a spectrum of confidence you'll never reach 100% nor should you expect to
Dealing in bullshit absolutes here is stupid, talk to your interviewee about what they could do to ensure their code complies with its intent instead of springing hidden expectations after the fact
But had they included this as a requirement I would have provided it. I am not in the habit at guessing informal unspecified requirements. If that is an indicator of their internal communication then I suppose I am glad I failed.
I would not really care if it worked or not and have the team or developer come back with a broken down version. (which if the code is structured well inside a single file should be very fast to accomplish)
Splitting code across multiple files when there's no actual reusability or abstraction driving the split makes it harder to follow the flow of logic. In particular, 750 lines is not so much that there's obviously a missing abstraction lurking there.
These days a coding test has a pretty standard minimum set of features to get a pass, and they include reasonably well organized code and having some tests. If you're working alone those are less important but as soon as you join a team they're critical.
I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions.
When I do technical interviews I assume the candidates code works (and it often doesn't, but that's not the point). I review it first, then I see if it meets the acceptance criteria. If your code isn't the sort of code that would be acceptable in the organization it doesn't matter if it works.
I would rather reject a candidate on quality than failing the test. Also, occasionally, if the candidate has made an obvious error that stops their code working but it's clear they write great code I might still recommend making them an offer.
Does that make me a bad engineer? No. It makes me experienced. If any of those things aren't wanted at a future employer I can change to match the style.
To reject based upon that when the style isn't defined by tooling is weeding out great people who may not confirm but have the ability to.
I would be interested in your thoughts on this. Is it because of salary, opportunity or security?
I am outside the Bay area.
I agree. And this is actually the very reason why I can dig into a 5 year old, reasonably complex bash script of mine and successfully maintain it.
Why is that beside the point? For me, as the candidate, if the evaluation is only subjective nonsense then the more important objective qualities aren’t valued in the exercise and probably in the office. That is a huge turn off to me.
Outside of interview conditions I expect people to be part of a team, which means they don't have to be able to solve the entire problem on their own. They can (and absolutely should) ask for help and advice from the other team members.
There is never a point in real work where it's all on one person. So the same should be true for candidates doing technical tests. If you demonstrate you can approach a problem well, you can write good code to implement the parts you could solve, but the end result isn't a working test then that's fine. In the real world you'd have had other people around to help with the bit you couldn't do.
At any rate now I know for next time precise questions to ask to ensure we aren’t wasting each other’s time. Had I known this before the code test I would have politely excused myself from consideration.
That just implies you can't, or can't be bothered, to write high quality code in a technical test. Why would you imagine an employer is going to overlook that and think you'll write better code if you get the job? That makes no sense.
Code style is subjective nonsense. If it’s that important provide a Schema or lint rules. High quality code solves a problem against a variety of objective measures: performance, complexity, instruction count, portability, and so forth. Things that can be measured with numbers.
The inability to differentiate subjective criteria from objective criteria is extremely immature. You wouldn’t write a contract like this or treat a business partner like this so why would a company treat a candidate for employment like that?
Some aspects of it are. I don't give a damn about tabs versus spaces, semicolons, etc. A decent code formatter fixes that sort of thing so it doesn't matter.
I absolutely do give a damn about things like breaking code up in to easy-to-grok modules, writing testable blocks, etc. In your response a few posts back you said "The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation." That demonstrates to me that you can't write unit testable code, because you didn't write any tests and your code isn't broken up in to units. I can't write tests for a monolithic file like that without importing all of it and potentially getting side effects like prototype poisoning or globally scoped variables. That is a good reason to reject you as a candidate, and why you shouldn't write code that way.
The code is testable. I provide data samples to test against and documentation on forming original new data samples for further testing. This manner of testing is easily automated.
I explained my thoughts on this and various forms of functional testing before receiving the assignment. To me this means they either did not understand test automation or they needed internal unit tests to make sense of the logic even though I provided copious code comments and documentation.
Again, it reaffirms they either cannot read code or didn’t bother evaluating past code style. If I were happy with that level of immaturity I wouldn’t be looking around. I am glad though to have discovered that immaturity during the interview process before leaving my current employer. I just wish they didn’t waste my time with an unnecessary assignment when they could have formed identical conclusions by looking at my GitHub projects specified on my resume and discussed in detail during the prior interview.
My final thoughts then were that they either lied about their conclusions, in that they used code style but really it’s that they cannot read code, or that my time isn’t valued (thus I am not valued).
I don't know anything about where you interviewed and of course this may not at all be true for them, but bear in mind that the point of home assignments is rarely "does it work?" That the candidate followed instructions and that the project "works" is expected. What many companies are looking for is seeing how you document, how you organize, how you test.
Again, I don't know what happened in your specific case. Just a heads up that writing tests, documenting and writing good commit messages are usually what people look at first when evaluating a home assignment.
But it does seem that Amazon's interviewing is not the best - I have worked for places where you had to take and Pass a 2 day residential course before you where allowed to interview candidates.
The fact is, it takes a certain personality to be really good at interviews. (I suck at it because I like everyone, too optimistic.)
Evidence please. Amazon has a lot of freaking fantastic engineers and "throwing money at the problem" is definitely not how they solve problems.
It's a huge company and not every single engineer is excellent and there are definitely rotten bits but that's true of _every_ company that's large enough.
If an external Ops group takes the burden of responding to pages, there is no feedback loop nor incentive for those writing the software to reduce the burden!
This is the Stockholm syndrome you often see in ex-AMZN people. Having devs burn themselves out within 2 years in insane oncall rotations is just not very smart. Nor is it the only way to do it.
>> there is no feedback loop
Not if "external Ops group" can refuse to support your shit if it sucks. That's how Google works: your service has to pass PRR (production readiness review) by SRE before SREs will agree to support it. If your service begins to deteriorate over time, SREs can dump it right back in your lap to fix, and require another PRR before they'll support it again.
And you don't hand the service over to SREs, there are still devs oncall, but the load is much ligher, and dare I say, SREs are much better at running infrastructure (and building tools to help run it reliably) because it's their job. They're also in multiple geographic zones, so at night an SRE in e.g. Zurich can take care of simple issues (or escalate to a SWE if it's something gnarly).
And I don't know how it is now, but SWEs used to get extra pay while they are oncall.
But I've had friends work at companies that said "That monthly 3am page costs us 1 hour of overtime, fixing it will take 80 hours, that's a weak business case so the fix is a low priority" - i.e. the feedback loop without the culture of fixing the alerts.
Of course, a sane company would account for employee retention costs in that business case, and wouldn't let their codebase get into a bad enough state that fixing bugs was infeasible. But when you're at the job interview stage, companies aren't likely to be upfront about such things.