Hacker News Reader

Comment by phendrenad2 | Hacker News Reader

I used to think Google and Apple were making a poor choice by doing this kind of interview, but I wonder now if it gets the results they want: they want interchangeable cogs that don't stand out too much. They want known quantities. If you're "the documentation guy" or "the security-testing girl", you've wasted time learning skills they won't utilize, since they want you to be exactly like every other developer. If documentation and security are going to happen at the company, a dedicated team will be formed for that, with monthly reports on key metrics going up the chain to management. That's how big corporations work, from what I've seen.

View on HN

HR wants the cogs that are flexible because they can cram them somewhere whenever the company wants spin down a team and move the personnel elsewhere. This is great for big companies that just need warm bodies to crank out crap however it's an inefficient process when you look at the lower level. You have a larger team of people that are less familiar with the task that a smaller team of experts could handle better and faster. If you can handle the schedule and direct cost hit of a larger, less specialized team, it reduces the later costs of needing to lay off people and hire new people. You can just move these warm bodies around somewhere else. A small specialized team is going to be a bit more riskier since once the job is done, are you going to have a need for these experts? Would they want to stick around doing something they never wanted to do? If a specific field is your core business, hiring experts is critical when starting up. But once youre a massive corp, you really just need boots on the ground to handle the mundane. College fresh-outs are usually the kinds of people that get drawn into these warm body kinds of jobs. They want blank slates that can crank out code, documentation, or whatever the pointy hairs need. If you really do consider yourself an expert, consider a consulting/contractor gig where you come in, do the specific job they really need, and leave with a bucket of cash.

Most engineers at Apple are assigned to one (small) team, including new college graduates.

Before you throw Google and Apple into the same bucket consider this: There is no unified job description for a Software Engineer at Apple, and it will often vary depending on which VP or even Director you report to. At Google, there is a ladder comprised of specific milestones that you must meet that is agreed upon by committee and used throughout the entire company.

At Google, you almost never know which team you will land in before you interview. At Apple, you probably know who your future manager will be before you interview.

(Source: I have worked at both companies.)

I was at a place that had been around for 20+ years, but needed to grow fairly quickly. So they systematized their hiring process. The focus was on generalists both because a lot of their technology was written in-house (it predated the commodity, off the shelf, solutions). It used the theory of the off the shelf solutions, but often had a different name or a slight difference. But the major reason they wanted generalists, like you say, was so they could move people around as-needed.

Much of the industry was either specialists in their studies, or specialists in that they knew a specific software package. It was interesting to interview people who had very in-depth knowledge of one thing, but completely oblivious to even the basics of other areas.

You’re right, and it can get worse. Certain focused industries such as financial services employ what they call “subject matter experts” aka “SMEs”. Turns out most are “solution matter experts” as in, only know how the particular wonky solution works as installed at their company unchanged since it was installed 10 - 15 years ago.

Do any specific interviews come to mind? I'm curious what sort of questions you asked, since I am a specialist :)

This was all about 10 years ago and it definitely lifted some of the trends with interviewing at places like Microsoft, Google, etc. There were 3 areas; technical, personality, and critical thinking. The criticism I noticed from interviewees grew further down that list. The job involved user support, which was the personality portion (it wasn't just "team fit"). Critical thinking had some of those abstract, problem solving questions tech companies were notorious for, but also had a mix of actual issues encountered.

Here's my defense for the critical thinking questions since I know it's a contentious topic here; I'm evaluating how they asses and troubleshoot something. Often, actual technical problems get caught up in the minutia or domain specific parts. So abstracting it and even removing all of the tech keeps people from getting hung up on that. I hate "trick" questions, but sometimes would ask one to see if they were thinking towards optimization or non-traditional. It's actually deflating if they already know the answer. I never cared if they got a result, I'd often move on if it took too long.

I felt the most criticism towards the technical questions. Many of them were more technical than really ever came up on the job. I think it's good to find the limits of a candidate's knowledge, but not ding them for it. An example would be doing stuff with pointers when the job is 100% in a scripting language. Sure, ask them if they know the basics of pointers, sure maybe once in 5 years they'll troubleshoot a bug that might need obscure knowledge, but I would hope that would get triaged and passed around instead of expecting everyone to deal with the 1% case.

Yeah I have come to a similar conclusion - the labor marker for software developers in the bay area in a sense becomes highly liquid because of similar job requirements, experiences and interviews. Heck I was told by a FB interview to basically go through leetcode “hard” problems to prepare for the interview.

Leetcode is just a game that you have to play to get into these companies. I suspect that OP had other interview rounds that went poorly. There is always a chance of getting a bad interviewer, but it doesn’t often happen in every single round.

I never understand this kind of comments. Is there a reason why OP should have bad intentions when writing the comment? The article is about Apple not providing sufficient documentation for their APIs and OP wrote about a experience that supports reasoning why Apple seemingly is not focusing on delivering documentation.

So how about giving reasonable arguments why OP probably had rounds that went poorly and is salty about it and why Apple has a wonderful software developer culture that focuses on quality instead of assumptions? Apple has problems with documentation since years, one example I had to deal with recently: their maps API. The MapKit programming guide is still in Objective-C, old design and outdated.

> The article is about Apple not providing sufficient documentation for their APIs and OP wrote about a experience that supports reasoning why Apple seemingly is not focusing on delivering documentation.

FWIW, I don't see how "I tried to add documentation in my interview and my interviewer didn't like it" translates to "everyone at Apple hates documentation".

> The MapKit programming guide is still in Objective-C, old design and outdated.

Objective-C guides are not inherently old and outdated.

> FWIW, I don't see how "I tried to add documentation in my interview and my interviewer didn't like it" translates to "everyone at Apple hates documentation".

You're absolutely right and this could have been an argument made by trangon, instead of an assumption about bad intentions by the OP. The interview story is just an anecdote in the end.

> Objective-C guides are not inherently old and outdated.

I agree in parts, they're not outdated in terms of facts present (although I wonder if MapKit didn't have any changes since October 2016). What I meant is outdated in a sense that Apple is pushing Swift but doesn't provide a programming guide in that language for this particular topic. Still supports my point of Apple having problems with documenting their APIs. SwiftUI is another example.

I think it's bullshit that "Leetcode" is a game you have to play. I've been in the software business for 25 years and not once had to use any of that knowledge in my work. When those games come up in interviews with me I call them out, if they hold fast I walk. I don't need to have my time wasted. My experience should speak for itself.

In several career focused communities where the majority of the readership is people with less than 5 (and often seeking first job)... where the focus is on Big N positions...

there is a common answer of “study leetcode”. No other advice, just the belief and assertion that all you need to get one of those jobs is to score higher than the other people.

This idea unfortunately perpetuates itself as one person advises another and a person.

The number of leetcode questions solved is used in the inevitable male appendage sizing contests.

Reply on news.ycombinator.com