My one and only Google interview went this way years ago. Each round they'd send me more books to study, which frankly I couldn't be bothered to read given the circumstances.
My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again.
I'm not claiming I'm Google caliber, whatever that means. Obviously I'm not because I don't have the patience for their interview questions.
To be clear, the entire question was:
What's not in a Linux inode?
My answer was:
Lots of things...dinosaurs, the moon...
The interviewer told me very matter of factly that it was in fact, the filename.
I honestly lost all respect for the process, sorry Googlers.
I had a similarly bad Google experience that I've talked about before[0] but will copy here:
I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone.
However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remember the exact algorithm so I basically had to re-figure it out on the fly, which took most of the interview (I even similarly mention "in any real situation I would just look this up", but that didn't help). At the end, I had a bunch of pseudo-C++-code that should do it correctly.
I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind. It was never mentioned previously that the code would actually be compiled and run, and with no syntax highlighting or ability to compile and test the code myself there is zero chance it was ever going to work.
I never heard back, so I'm assuming my code failed and they left it at that. Anyway, I'm much happier now that I think I would have been at Google.
At this point I'm pretty sure FAANG hiring is just a random walk. Every now again someone happens to have looked at all the questions they ask recently for that particular interview cycle (or avoid the trap ones like that) and that person gets hired (and then put on the ad targeting team or whatever).
The experiences that people describe here just confirm something that many of us has learned a long time ago:
NOBODY HAS "FIGURED OUT" HIRING !
Not Google, not Apple, no one. Sure, some places (and individual interviewers) are better at it than others. But at the end of the day, hiring is a deeply subjective process with lots of error and uncertainty built into it's nature. The subjectivity is intrinsic.
Places like Google can afford to be nonsensically picky and not suffer drastic consequences from it. They have a thick, never-ending stream of highly qualified candidates. At their volume of hiring, it doesn't matter to them if they screen out some folks that would have been brilliant hires, nor does it matter if they hire some promising but ultimately disappointing duds. All of that is OK.
Sadly, however, it seems that small shops are trying to cargo-cult Google's hiring practices. That IS harmful to the company and the candidates, IMHO. I think folks in these non-FAANG companies should get trained on how to conduct interviews, especially if they're interviewing non-senior candidates. Interviewing is a skill in itself. It's not something that comes automatically with expertise nor is it something that can be left entirely to HR drones.
Pretend there's a Programming Quotient (PQ) which is like IQ.
Let's say Google would like candidates with PQ>130 with 95% confidence. Google has an error with std. div. of 15 points in measurement of PQ in jobs interviews. Google then needs to set the hiring bar at 160 PQ in order to get those candidates. This:
- screens most qualified candidates out; but
- most candidates who do screen in are qualified
Statistics would suggest this leaves you with 95% qualified candidates. A more precise Bayesian analysis will show you don't end up with 95% qualified employees, but the basic idea works -- it's still a majority. You set an impossibly high bar, so that candidates hired need to be qualified AND lucky. You discount unlucky candidates, but you don't hire (many) unqualified ones.
The problem, of course, is that all Googlers are convinced they all have a PQ>160, and are superior to everyone else. That's where you get the obnoxious Google incompetent arrogance.
I’ve used Google’s software. I’m not sure they’re all that great.
Someone just released a product that offloads Chrome to the cloud. Gmail has a very long loading screen. Hangouts was replaced by something like 4 incompatible apps. Android phones are significantly less power efficient than iPhones. YouTube copyright notices are trivial to game. Etc
I think the bar I gave, PQ of 130, is about right for Google. Your typical Google programmer is pretty bright and pretty competent, but not spectacular.
Most of what makes big companies succeed or fail is in the overall culture, organizational design, incentive structure, and corporate structure -- properties of a network of individuals rather than of those individuals themselves. I think most of Google's success and failings can be explained that way, much more so than the success or fault of employee quality.
Organizational design is really hard to get right. A senior manager described it like a herd of cats. If you get them all mostly moving in a beneficial direction, you're doing okay.
That's why they pay executives the big bucks. Executives fake understanding how to manage this stuff. Most don't, but they do a good job of convincing boards that they do.
Yeah I don't know, I've been extremely disappointed with Abseil, protobuf, and gMock. So whatever metric they're using, it's not generating particularly great C++.
I wouldn't care about some company's code quality but in these cases Google's clout (due partly from their maladaptive hiring practices) causes these bad libraries to get grandfathered into many projects that I have to deal with.
I've seen amateur programmers produced great code, due to cultures of code review, peer mentorship, high professional standards, and time to think deeply through problems and talk things over.
I've worked in companies where great programmers produced horrible code, due to cultures of optimizing to productivity metrics / features shipped, rushed timelines, and interrupted work schedules with meetings, requirements changes, and people multitasking projects.
I'm not arguing one of those is better than the other. Running a business is about tradeoffs. I am not particularly impressed with anything Google has engineered in the past decade or more. The original search, gmail, Google Docs, Android, Maps, and a few others were brilliant, but those are a long time passing.
On the other hand, I'm not ready to condemn anyone working on those over that. Competence is situational and context-dependent. I also don't have insight into Google business decisions. Google revenues are growing exponentially, so they're clearly doing something right.
The number of things Google farms out to "the contractors" is crazy. I've talked to a few folks that got to work in the big beautiful facility but, the code they were writing was the worst, "pound it out, who cares how it looks or how well it performs" quality.
Except that the measurement error is very clearly fat-tailed, and the std.div. is clearly much larger than one std.div of competence of the population.
Place the bar high enough and you will get more and more people far into the tail, and less and less people that actually fit your bar.
I very much agree with everything you wrote, except for the arrogance bit. Many actually suffer from the impostor syndrome and just a few I could call arrogant. I'm sorry you had to deal with them but please don't generalize from just a few.
Outwards arrogance is often the manifestation of impostor syndrome, but I digress.
Corporate arrogance isn't a property of individual personalities. Most Googlers are perfectly nice people. The Google corporate culture is a whole is rooted in a deep superiority complex and dripping with arrogance. Google believes it knows better than its users, and that translates to all aspects of product design. If you moved those same engineers to a different company, you wouldn't have the same behavior.
I'll also mention that each organizational design has upsides and downsides.
This culture seems to work well in Google's early markets (e.g. search) where users are statistics, and where most problems are hard algorithmic problems, and users are secondary. It has upsides in B2C markets like Google Docs or Android. It crashes-and-burns in a lot of B2B markets, like Workspace or GCP, where customers have a high degree of expertise which ought to be respected.
I'll mention a lot of fintech companies, as well as elite universities, have a similar culture. Those are domains where it leads to success as well.
I'm sure that's true, but I've interviewed there numerous times and I invariably get one or two shockingly arrogant and obnoxious interviewers. The fact that they usually have no idea why I'm being interviewed, and clearly have a lot of other things to do, may be the source of that perception. But it so often feels like "you're already wasting my time, but here's my favorite trick problem that makes me feel smart, man you're a waste of time."
The reason this cannot work is in any process that's that constrained, if there is any factor other than PQ that can get you a position, the outcome of the job interview will be entirely determined by that factor and not at all by PQ.
Instead, you should try to find lots of correlates of PQ and measure them regularly.
A lot of really good people are discouraged by repeated rejection. However, high levels of rejection of very qualified people are built into this (and many similar) systems. You have to be qualified AND get a lucky die roll to get in the front door. Once people stop taking rejection personally, they can start acting more rationally, and there's less emotional harm. People feel really bad about themselves otherwise.
I think you've hit the nail on the head. I've been on both sides of the desk so many times. When I'm hiring, I'm trying so hard to recognize the person is nervous, probably interviewing at multiple places, and they don't want to be asked to solve stupid algorithmic puzzles that will never come up in their daily work. While interviewing, I try to recognize that they NEED to ascertain whether I can actually solve problems performantly and quickly. They also need to quickly decide if I'm worth the high dollars they're about to offer me.
Because of this, I often hire people I've already worked with. I'm also often hired by people who've already worked with me. I hate that this leads to a very homogeneous experience... or even what might seem like gatekeeping. I've just found that the best indicator of how a person will perform, is already being familiar with their work.
Or you hire people you know. Which isn't perfect, has it's own set of problems, and doesn't scale. But I can't really complain given it's how I've gotten every job (just a few) after grad school and my interviews have been mostly perfunctory.
Here on the other side of the FAANG spectrum working with and for other independent contractors and various small (5-20ish devs) consultancies, I'd say that hiring based on who you know and you your peers recomend is far and away the primary way work is done.
The good news is, it's a very open network. We have a highly active Meetup scene, pretty regular public hackathons, annual small software conferences and un-conferences, and coworking spaces are (well were) packed.
For the most part this has worked, people new to the community are able to find jobs and the people hiring them know what hey are getting. But also like you say, this doesn't really scale to larger operations.
I'll accept the statement. But I will say that hiring from a network is at least a very different thing from hiring through a grueling set of often artificial interview hoops. It requires a potential candidate to have genuinely interacted at a higher than superficial level with a lot of people in a professional capacity. Which may not be harder than "leet code" but is certainly very different.
And yes, all the big companies have referral programs but that's mostly just a very rough first pass as a lot of referrals are basically I'm connected with this candidate on linked in. Referral bonus please.
> Sure, some places (and individual interviewers) are better at it than others.
In my, admittedly not super extensive experience, I tend to believe that about 1 in 10 companies actually knows how to run a hiring process. I'm not sure precisely what kind of error bounds I'd put on that, but I doubt I'm off by more than a factor of 2 either way.
There's nothing to figure out. Relationships aren't a maths sum. They work out to varying degrees, and have too many variables and depth to predict. But the group of people with a reputation for having maths skills, a reputation for not have social skills are going to figure it out - what could go wrong?
we have, we don't have technical interviews anymore, just a 'cultural fit' discussion.
coding has become so trivial anyone with a brain can piece together snippets from stackoverflow.
do yourself a favor and if all you do is crud operations in a web app, don´t even bother with tech rounds.
> At this point I'm pretty sure FAANG hiring is just a random walk. Every now again someone happens to have looked at all the questions they ask recently for that particular interview cycle (or avoid the trap ones like that) and that person gets hired (and then put on the ad targeting team or whatever).
This might actually be part of the retention strategy. If everyone who works at FAANG knows that they're somewhat lucky to get in, regardless of ability, it means they are less likely to jump ship. What's the point in applying for another job when you're already paid well and it's unlikely to end in anything but lost time? You're unlikely to win a 10% lottery twice, given the amount of time you'd bother investing.
I am not looking externally until I'm sure I'm done at AWS. I've done 80+ interviews here, and I'm consistently amazed by what drives people to say "The candidate wasn't up to the coding bar". As far as I can tell, you are almost never up to the coding bar. I think we interview so many people just to remind ourselves that if we leave, we aren't getting back in.
Just to head off the "So why don't I argue for change?" questions, I'd rather work on self improvement than fight tooth and nail to make the hiring process a little bit better. I'll let somebody else add that to their promo doc.
That culture is so foreign to me. Each place I've left in the past 10 years, I'm pretty sure I could go back. I know enough folks or at least have been told by C-Suite that "the door is always open, just give me a call". I went through a few rounds of Amazon interviews in 2020... I don't think I'd ever way to experience that again.
I remember seeing a comment about Amazon once claiming in order to be seriously considered for a role, you have to be better than 50% of the existing team you’d be coming onto.
To be fair, that would mean that your ability level is the median ability of the team you'd be joining, which doesn't sound all that far-fetched to me. If the skill level of new hires is always close to the median, the overall team ability should stay the same in the long run.
This line of thought obviously depends on the assumption that you can measure the exact ability using just a single quantity.
Exactly. Who wants to hire somebody who's dumber than half their teammates? That's a recipe for failure. Assuming inaccurate measurement, you'll actually have some below median, so you need to bias upward or else you'll just end up with a bunch of mediocre eng.
Yep, and that point has been brought up ad-nauseum internally. Also Jeff did comment how he would probably not be hired by his own company. I personally saw the business pushing the scales to the point of 'just get them in the door, oh my god we are growing too fast and don't have time for your bickering'. Depending on the business unit and how hungry the hiring manager is that issue of raises the bar can just be a hand wave and 'get em` in'. For some technical positions you have a 'bar raiser' interview you who is often an IC who was promoted to Management ranks and has to serve penance by being the one to conduct countless BR interviews. 99% of them were pretty chill on the Clark/Fufillment side of the business. Cant speak to the Jassy/AWS side of the house. Their concept of BR may be more concrete. We rarely kept people out just because they did not 'raise the bar' since that is subjective as hell and personally I like qualified metrics.
I never interviewed for the AWS side of the house since I knew I wanted free time, and a life.
On the AWS side of the house, the bar raiser doesn't actually interview the candidate. The bar raiser is there as a neutral party to help facilitate hiring decisions and debriefs.
It's the bar raiser's job to make sure that the hiring manager doesn't just hire people to fill seats. More than once, I've seen bar raisers override hiring managers when there was compelling evidence from the technical interviewers.
At least in my org, you don't get the job if you don't raise the bar. Period.
That is crazy- with us BRs would just sit in on the POD like any other member and have the same voting authority as everyone else. I wonder when things split internally that Team Jassy and Team Clark starting doing things so differently. Thanks for the post man, that is crazy to learn.
That’s true if we assume that ability does not change with time. But if you have a spectrum of experience in the team, it might be unrealistic to expect rookies to match the median.
Inside that is called raising the bar. Often times I would personally aim to find people who were 50% better than the best person I knew in that role. Often times I would still incline on people during their POD. I would just strongly incline with 'raises the bar' on folks who met that rare exception. Honestly I was on the Dave Clark side of the business and we were much more chill about things vs the Jassy/AWS cult. Those dudes might as well be from the moon. So take my statement with a grain of salt. We worked for the same company... but we also didn't, Amazon is just that big.
I had plenty of times where an entire hiring pod would incline on a candidate because they had the soft skills we were looking for in that role and we knew we could sharpen their technical skillset in house. You don't have to be a rocket scientist to work at a FAANG... you just have to be interviewed by a team that is hungry and likes you.
Candidates should be better than 50% of the people currently in the role. So if you're interviewing for an SDE1 position, you're expected to be better than half of the current SDE1s.
You're evaluated against people in the same role, not the entire team. But, yeah, the idea is that the hiring standard (the 'bar' in Amazon terms) is always getting higher.
Sometimes I see articles about a wrongfully convicted man being let out of prison. This usually comes with a cash payment of some sort. The whole we took 20 years of your life, oops, here’s a million dollars. Every time I see this though I think ‘no, no way does money replace my time.’ That’s simply not good enough. And not because the payments are usually ludicrously low, but because there is no amount of money that would buy off my life.
Same as there is no amount of money you could give me to end my life, a position which I assume is shared by a vast majority of humans.
Time is not money. It’s not even close as an exchange rate. I would never put myself through these types of interview processes (not to mention that I would assume that sort of thing to be indicative of the job itself and company as a whole) because I value my actual life and dignity far and above what I value as an upper middle class income.
I value my actual life and dignity far and above what I value as an upper middle class income.
I am at least 90% sure that part of these interviews is to filter out people who these sorts of views. These employer would much rather have someone who wants to work 100 hour weeks and be the 'hero' over someone who works exactly 8-4 monday-friday and then goes home.
IDK, if the interview is just a few hours of misery to get a significant financial upside, it's not such a big deal. People always assume the job will be miserable too, but that varies from team to team. Especially because the salary is high enough that you may be able to save enough to buy your life back if you're careful and have time on your side.
Be sure to price in general life risks like accidents, cancer, stress induced hearth attacks etc. The problem with this approach is, that a non zero number of people will not live long enough to buy their life back.
It's very true, and very natural. It's one reason why FAANG salaries have been getting so high.
If I change jobs, and find myself in a good situation, and need more head-count, I'm going to reach out to people I like that I've worked with before, see if they might be interested in a job change. I know I can work with them, know we'll build good stuff.
There's a constant drive in FAANG to hire more people, most teams have open headcounts. To the degree that it's extremely hard to build up that funnel of candidates. If my team has a head-count of 5, that realistically means I've got to find a bare minimum of 30-40 candidates to enter in to the pipeline from somewhere, to maybe get close to that target. That's a slightly optimistic conversion rate. Now scale that up across a company with thousands of teams that are hiring. Getting that pipeline filled on that scale is crazy. It's just one of many reasons why FAANG go all in on college hiring events.
I can almost 100% guarantee to get someone I've worked with in a FAANG co-worker through the interview pipeline and in to a job. They know their shit, they know what they're doing, and they know what the process is like.
It's because the DoJ Antitrust Division came down on them hard in 2010[1], and part of the settlement forbade the companies from engaging in that behavior again.
One can interview without quitting the current job. That allows for multiple attempts over time while retaining the current status. People may do so to see what pay they’d be offered.
100%, speaking as someone who's been both sides of the equation in FAANG hiring.
Part of the problem is the sheer scale of hiring, but I think most of the problem comes down to the lack of feedback or evaluation mechanisms on the interviewing side.
They train you up, half a days worth, training tells you not to be an arsehole, not to ask stupid questions, not to have unreasonable demands of candidates, not to be biased. They don't train you in valuable skills like active listening.
Next thing you know, you've done training, and you're interviewing candidates every week or two (or more often), and there is zero feedback mechanism. No one evaluates your interview questions, no one asks candidates to provide feedback on the interviewers. No one looks to see if you've got unreasonable expectations as an interviewer, or have your expectations set too low.
You do have to do a post-interview group discussion with the other interviewers to make a yay/nay decision, but it's super easy to present what you did/asked in a positive light.
The whole system is designed around the interviewer being right and infallible. Is it any wonder the process is so completely and utterly broken?
edit: > or have your expectations set too low
This is where I bias towards in worrying, imposter syndrome and all that jazz. I've made a conscious choice to not raise that bar higher. I think the questions I ask are good, I think they're set up well enough to encourage candidates to go as deep as they feel comfortable with. I try to design them with no one true answer but have a few in mind so I can go where the candidate goes.
I also did interviewing at a FAANG and this was not my experience.
1. We trained 4-5 times on each type of question. The first few were shadows, and then we did reverse shadows where someone watched us give the interview and gave feedback later. In one category I asked for and was allowed to reverse shadow an extra 1-2 interviews.
2. There was auditing. In debriefs where you discussed the candidate and reviewed notes, the debrief lead was supposed to closely examine what questions you asked and how you conducted the interview, with the explicit goal of making sure that the interview was conducted within spec and your recommendation made sense given performance. Shortly after I was certified to do interviews, a debrief leader (correctly) identified a major issue in an interview that I had conducted. That candidate was given another interview in the same category. Although I didn't face any official sanctions, it was definitely an embarrassing experience and made me handle future interviews more thoughtfully.
Overall, I was fairly comfortable with the rigor of the process that I saw. I'm certainly not saying the process is perfect but my experience did not align with yours.
Not if it's taken too far, as it will create new biases based around the "rigor" of the process. You end up "hiring to the process" as opposed to "hiring to the team / role". If someone doesn't have enough experience/knowledge, but they are clearly talented enough to learn on the job and look like they could accomplish great things, that person may be a much better fit than someone who knows everything but is terrible at executing or working within the structure of a large organization.
(the "lizard brain" is a myth by the way; I think you're confusing it with unconscious bias of heuristics, which is not what the triune brain theory was about)
Are you saying each interviewer just makes up their own questions?! That's ludicrous if so. Where I work, we have a standardized pool, with standardized evaluation criteria.
Everyone makes up their own. I can't for the life of me fathom how this doesn't subject them to all sorts of discrimination etc. claims (one of the reasons lots of companies favour standardised questions).
Obviously the drawback for FAANG is that standardised questions would rather rapidly leak. Very quickly you'll just end up with candidates that know how to answer your questions.
Where I work now, it's a mix of pool questions ("soft" skills) and interviewer-made questions (technical skills), but it's not a hard and fast rule to use the pool questions. I rarely use the precise wording for the pool questions, and instead adapt them to match the conversation with the candidate.
Adapting to the candidate is probably good most of the time, but don't work too hard to make that happen. Computational geometry is on my resume, and interviewers are always trying to show that they know that too by trying to bend their question into that. The exercise very often detours as they've led me way down a wrong path because they're analogy doesn't fit, and all they wanted to know was if I knew about minimum spanning trees or even just heaps.
What's funny is that I specifically remember a conference where some library that a google employee wrote was terrible. The one google developer talking about it, disavowed any responsibility of it.
Whatever metrics that google is using in their interviews have probably become worthless in the past decade as people game the system.
In my startup I interviewed a 48 years old senior Java programmer with excellent resume, who took 1hr to write a String.contains(), it only worked for the requested 4 letters, didn’t work if a letter was repeated twice, and didn’t work with Chinese characters. At least it had the JUnit. I asked an employee to do it too and he made his code pass the JUnit in 6 minutes.
The candidate hated the interview, claiming it was discouraging. Coding is erratic, talent is strange, it really is a craft and we still don’t know how to reliably raise someone to competency.
1. The candidate was a complete and utter fraud and their previous (and apparently well-regarded) employers were too stupid or negligent to notice this, wasting literally millions of dollars (48-21 * $100,000+).
2. Something about the interview failed to let this person demonstrate the skills that had kept them employed for two decades. Maybe their mind went blank under pressure, or at the end of a long day. Maybe they got hung up on something trivial (that a quick search—-or nudge from the interviewer—-would have resolved), or the question was unclear.
To add to this, I’ve found engineers more likely to hang on time series and string manipulation problems. Likely due to a combination of not having to code low level functions in these areas, as well as infrequently encountering the problem.
Yes, strings are hard and times/dates have a ridiculous number of edge cases, and sometimes very poor language support. This works both ways though; if the problem is easy enough (calculate average cycle time) it can give you lots of edge cases to discuss and really show how someone problem solves, which is really the point of a programming interview. If someone even mentioned non-english language support that would be enough for me, forget about implementing it.
I personally dislike giving questions with too many rabbit holes. My observation on a few questions is that it’s a 50/50 shot if the candidate who freezes on a question recognized more nuances than the candidate who didn’t which means I’m not getting any data.
Fizz buzz was a great question in that it had pretty much a Boolean success criteria.
The interviewer needs to be good/prepared to make it work.
If the interviewer only says "Write String.contains that passes these test cases" goes back to playing with their phone, several things may happen. One person will take that absolutely literally ("It's a test; better do as I'm told"), and you'll dismiss that apparent garbage or move onto the "real" assessment where they're hoping to shine.
Another will get bogged down in something the interviewer regards as a distraction, and "waste" a bunch of time on something the interviewer regards as a distraction. "He handled unicode, but not substring matching (KMP or Booyer-Moore) or vice versa." Maybe someone will goldilocks it and hit the right (not-explicitly-specified) balance of (also unspecified) features and time, but...
If you structure it as "Please, do the dumbest possible thing and we'll iterate"--and don't hold that initial pass against them--I could see it working well.
Sounds like the solution then would be to give interviewers all of the systems and support they would normally have access to on the job and see how well they adapt to a conventional task or an issue that was recently solved by someone in a similar position on your company, and have their result evaluated by someone involved with the implementation or fix.
That would tell you if their workflow would fit your company much more than knowing how to run a coding challenge would.
On the other hand, tools tend to be fast to teach and pick up relative to fundamentals. Most companies have rough around the edges tooling that a candidate either wouldn’t know about or need a couple weeks to get productive in.
I would say 1 is possible enough that it’s worth checking for. Remember that insanely too hard programming detail is a reaction against a situation where 99% of candidates couldn’t program at all.[1]
What proportion of your colleagues do you think are wildly incompetent? Not just a bit sluggish, subpar, or sloppy, but not even remotely able to do something resembling their job description.
There are certainly a few. The job market, being a combination of people who want new jobs and those that can’t keep their old ones, is undoubtedly enriched for them.
Even so, it seems unlikely to me that there are anywhere near as many as most people say. You certainly don’t have to hire someone who flubs your interview, but you also don’t have to assume they are frauds.
> What proportion of your colleagues do you think are wildly incompetent
30%, minimum. I was hired alongside a guy with a fantastic resume. He pushed zero lines of usable code in 4 months. When he left I purged about 20 files which were tests that were just completely commented out (but I guess those count for LOC according to github's crude measure). I would say that not only was he incompetent, he was worth negative (thankfully, nothing critical) - Maybe in order to cover his tracks? he had moved certain classes of tagged tests (e.g. skip, broken) to "ignore" status instead of 'yellow star'/red dot, I now, months after his departure, have a pr reverting those changes months after because I didn't notice he had done that. Thankfully it had not covered up any major defect in our codebase (someone could have left a corner case test as "broken" with the intent to fix it later and wound up forgetting to and sending it to prod).
But hey. Programming isn't that bad. In the physical sciences it was 60-70%.
The problem is that it only takes one or two wildly incompetent people to completely disrupt the quality of the software. These are the kinds of developers who actively create bugs, usually by building (or copy/pasting) solutions that only work by accident, or who decrease the velocity of everyone around them by generating reams of overcomplicated and brittle code that is hard to test, hard to review and hard to maintain. It costs a lot of management time too, trying to find a way to get them to improve, or to build a solid case for letting them go.
I think the reason why every developer tends to have a story about these sorts of incompetent colleagues is not necessarily because 50% of their colleages are incompetent, but because even if just 2% (one person in the department) or 5% (one person in your larger project team) is incompetent, that can be enough to cause a seriously negative impact.
I should clarify I lifted the 99% stat from the linked wiki.
I agree it seems high.
I’ll estimate zero to 10% wildly incompetent. Many of the folks who aren’t able to program find other ways to be useful: Testing, requirements, prod support, sys admin, config. It’s not even clear they couldn’t program, but maybe came to prefer the other work at some point.
absolutely. The incentives to train for the job search and then apply (and succeed at) a job with zero relevant competency, are quite high. And there are... geographies... which have a deserved reputation of being mills for those sorts of individuals, likely because the economic incentive is even stronger than the median, which I suspect is quite annoying for actually competent people that come from those geographies.
A few percent maybe, but not as high as 10 percent. It's also not just people who "can't" do it, but also those that aren't motivated or cooperative (for whatever reason).
I interview for my company. 80% of the DS applicants (some of them with SWE background) that apply for our senior positions fail with FizzBuzz or some riddle of similar difficulty. This is already pre-filtering for seniors from established companies. We do not pay bad for the market. They also do equally bad with other FizzBuzz-level tests in other areas that they claim to have worked in.
This is exactly my experience too. Sometimes it's incredible just how little applicants understand about how to develop software. I've even interviewed people where they were allowed to have a web browser and IDE while coding a solution, and they still struggled.
Personally I am a much bigger fan of using FizzBuzz as a gate than an algorithm question. I think algorithm questions optimize for the kind of developer who doesn't mind memorizing algorithms to get a job, which might be a useful skill, but you can test that same skill of memorization using FizzBuzz, and then you don't end up also filtering out people who can code but don't care about memorizing algorithms.
In any case, I always think it's worth using their solution as a jumping-off point to ask other, more language-specific questions. Things like: how would you change this if it was intended for use in a FizzBuzz library, how would you annotate this if you needed it to be injected as a Spring dependency, why did you use a for loop instead of a Java 8 stream (or vice versa), what are the implications of declaring this thing as final or static, can you write a unit test for this, and so on. That's when you can get past the point of memorization into figuring out if they actually understand what they typed, which is helpful to ascertain their level.
No, it's just an opening to discussion. For example, depending on the experience of the person, it might lead to a conversation about dependency injection in general, the transition from Spring-specific to JSR-330 notation, maybe they can give some examples of where Spring-specific annotations are still useful, they could talk about constructor over field injection, or when it might be better to use a static/pure function instead of a bean, all kinds of stuff.
For me there are basically two questions to answer when I am interviewing someone. The first is if they have any real programming ability at all, which hopefully FizzBuzz should answer. (Many people do not pass that threshold.) After that I'm looking to figure out where they could fit into the team, or the company. That means seeing if they are already familiar with the frameworks they will be working with in the position (usually, but not always the case for junior applicants who have held at least one job before), but then also if they can speak critically about some of concepts used in those frameworks, and perhaps compare different approaches that have been taken to solving similar problems over the years (if they are more senior).
It's not a wrong answer if they don't know the framework or the concepts behind it at all, since they might be switching specializations, but that's important to know at the interview stage because they might be better suited for a different role than someone who is deep in the framework and more likely to be able to hit the ground running.
Thanks for posting. I'm always very interested in hearing form people who mention how ostensibly senior people fail fizz buzz.
My question is: what happens after people pass fizz buzz? Failing fizz buzz is how you filter people out, but it's unlikely that coding up fizz buzz passes the technical screen. What kind of questions do you use to establish this, once you're past fizz buzz?
I've failed far more tech screenings than I've passed. I could easily do fizz buzz, and when I've prepped for an interview, I could some tree and set permutation stuff. But the questions get so much more difficult than this. Since difficulty varies, an example of a difficult question for me is "find all matching subtrees in a binary tree" (at the whiteboard, in 45 minutes). When I got feedback about the no-hire, the explanation was that I had a good grasp of algorithms and made some progress, I didn't solve enough of the problem in code (tight pseudocode would have been ok) in time allotted (again, this was ~45 min at the whiteboard, one in a series of 5 one-hour technical exam style interviews during a day of interviewing).
I can't claim to be a great coder. I have understood how to code merge sort and quick sort and more complicated tree structures, and I could do them again if I studied and loaded it all back into short term working memory, but I'm content to know how the algorithms work generally and get back into the details when I need... but when anyone mentioned "Fizz buzz", I do insist on stating that my impression, based on quite a few interviews, is that fizz buzz isn't what is screening out software engineers. Lots and lots of people who can write fizz buzz (and build and print a binary tree pre order and post order, and do dfs and bfs, and solve problems with them) are still frequently screened out.
I'm at the point where I just won't do tech interviews anymore (or take home tests). I won't study for exams or do mini capstone projects for an interview that may or may not work out. I would do these things for a degree or licensing exam, but not for a job interviews. It's just too much of a time sink.
I accept that this may cost me good opportunities (in fact, it has), though of course I don't know if the interview would have gone anywhere, other than costing me another long prep session with "cracking the coding interview".
I'll finish the way I usually do, by 1) acknowledging that you are free to interview how you like, and that nobody owes me a job, and 2) mentioning that many companies complain incessantly about hiring difficulties without realizing that their own interview processes may be filtering out talented people and that nobody owes them an employee either.
> My question is: what happens after people pass fizz buzz?
We tune up a little bit the difficulty. The point is to start a conversation and see what the candidate knows about, ¿does he knows about time complexity?¿differences between passing by reference/value?. Afterwards we talk about the technology that they use, what they like, and what they will like to use in the future. Just to see if they read about their field and are able to talk without saying something egregious.
And if they do fine we bit the bullet and hire them.
> nobody owes them an employee either
Now that I am "in the other side", I can see a lot of things that will definitively would improve the problem at micro/team level, like posting salary or increasing the WFH days. But ¿would they improve at macro/company level? The things is, companies, including tech companies, from small startups to big corps, usually have much more problems than the quality or quantity of their software.
(signed, someone that has been rejected, and will be rejected, to more interviews that he has passed)
I’m the interviewer, I’m still wondering what happened.
This was the introductory question before launching 200 threads and asking him to solve the deadlocks/inefficiencies, which was
the real question supposed to let him show off his skills in front of my employees, specifically crafted for him because I wanted to persuade my employees he was an excellent hire. So he had a taylored chance to show off his skills but failed at the introductory question.
But on the other hand, how can you be asked “Here’s a substring, return true or false if it contains the substring, this is the introduction of 5 questions so don’t sweat it” and not just write two nested loops and an if? I’d pass on UTF8 problems, but when you’ve been working with Java for CRUD apps, you still should have your UTF8 correct. This is how you end up with passwords that must be ASCII because the programmer is bad.
I had number two happen on an interview recently and I am incredibly happy the interviewer didn't hold it against me. I forgot an otherwise simple word/term, but the pressure of the interview just made my mind go completely blank. I think everyone has a tendency sometimes to forget what it's like to be on the other side, and will hammer on small mistakes, or not consider all the factors.
I'm sure I'm on somone's list of incompetent bozos for an interview that went like this: "Please, describe Python programming language." That's it. I had no idea what I was supposed to be doing, and the two fellows interviewing me would not elaborate.
I talked about what I had done with Python. Stony stares. Do
I talked about the nature of Python itself (interpreted, multi-paradigm, lexical/LEGB scope, the GIL). Stony stares.
I wrote some trivial programs on the board. Stony stares.
Had I brought an actual snake, I might have tried to charm it.
At the end, the CEO told me they weren't overwhelmingly sold on me, but would think about it. Never heard from them again.
I've repeatedly had employers very happy with my abilities & results, and am also entirely sure I've, on a few occasions, convinced interviewers I'm entirely unable to write code and am one of these frauds everyone's sure exist and that they need these coding tests to "catch".
The second is certainly more likely, but I'd wager the likelihood of the first is greater than 10%. I've encountered my share.
There are so many "developers" just faking it, I can certainly understand using a test that would reject 90% of the good candidates if it could reject 99% of the bad ones.
What was the goal of the question? Why did you want the person to implement a contains method? Did you really want to verify they understood String implementation in Java?
And if the candidate was able to do this in 6 minutes, what would you have thought? "Great, let's hire"?
In my humble opinion, the question is a waste of time either way. You'll get much further trying to probe what the candidate does know rather than randomly creating an exercise that you think they "should be able to do if woken up in the middle of the night". People forget how stressful interviews are and how easy it is to assume shared context.
The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.
Multi-lingual support seems reallyreally hard, especially in six minutes. I would think most people would need to look at technical (i.e., unicode) and linguistic references to get it right.
Should does the ligature f l match itself, or the ASCII constituents 'f' and 'l'? How about combining vs. pre-composed characters? Some Chinese characters show up in other languages (Japanese, Korean) and are sometimes split between Hong Kong/Taiwan/Mainland language tags too. In fact, there's a mess of work devoted to this ("Unihan" https://www.unicode.org/versions/Unicode13.0.0/ch18.pdf). Having figured out what you can do, you then need to decide what you ought to do. Not being a Chinese-speaker, I have no idea which options would seem natural....
In fact, having written this all out, there's no way someone "solved" it from scratch in six minutes. It would be a great discussion question though....
for (int i = 0 to text.length() - substring.length()) {
boolean found = true;
for (int j = 0 to substring.length()) {
if (text.charAt(i) != substring.charAt(j)) {
found = false; break;
}
if (found) return true;
}
We’re not taking rocket science here. This code already properly handles surrogates and Chinese characters. The question about characters that can be written in two different ways should only be raised as a second level, once the first implementation is done.
This is the introductory question before solving concurrency problems, because it’s much easier to understand what a thread does when you’ve coded the body yourself.
> Why did you want the person to implement a contains method?
The job is CRUD + integrating with Confluence + parsing search queries from the user, so finding “<XML” in a page and answering “Yes! This is totally xml, I’m positive!” is a gross simplification of realistic tasks in the real job (and in fact in most webapps), with characters instead of XML or JSON.
I have the feeling that you think this question is entirely abstract, but I both tailored the exercise because he touted being good at improving app performance on his resume (including using JProfiler) and I took care of using a realistic on-the-job example.
> Did you really want to verify they understood String implementation in Java?
Well, what consumer product can you work on if you trip into all UTF-8 traps? Telling customers “Just write English because we can’t be bothered to learn the easy thing in Java that handles UTF-8 properly” is… is acceptable unless he also fails the fuzzbizz test. And once UTF8 is mastered, it’s good for life! I wouldn’t mind teaching him if he didn’t fail the rest, but as a senior you should really know the difference between .getBytes() and .codePointAt(i).
> If the candidate was able to do it in 6 minutes, what would you have thought? “Great, let’s hire”?
The 4 other questions were classic gross concurrency errors, tailored because he touted it in his resume and I wanted him to shine. A senior should be able to guess them blindfolded as soon as I tell them “There are concurrency problems”, without even looking at the code ;) Volatile, atomic, ArrayList non-synchronized, 200 threads for a connection pool of 10, a DB accepting 7 cnx (note the prime numbers make it easy to spot which multiple is causing the issue), and strings of 10MB each with Xmx=100m, if he finds any 3 of the 12 problems, and 2 more with help, I’d hire him. If he ditched the code and postes tasks into an ExecutorService (as they teach in the Java certification level 1), I’d hire immediately.
1) We want to test concurrency but start with implementing String#contains.
2) You have to know how to implement String#contains because you might use contains in our environment (not really, but theoretically, so you better know how to implement it).
3) You must absolutely avoid basic UTF-8 traps because users use UTF-8.
Neither of the above tells me what would you gain if the candidate nailed the question. It just tells me that:
- Your team might or might not use contains to verify something is XML (I truly hope not).
- Your team uses UTF-8 strings (which is one piece of the shared context that the candidate probably does not have).
- You tested candidate abilities of performing under pressure rather than testing their knowledge or skill.
- You are trying to hire the exactly same senior developer as if you promoted someone on your team with your codebase.
You come to the interview full with assumptions and biases about what a senior candidate absolutely must know instead of seeking what they bring to the table and why they call themselves senior. Let me tell you there are lvl 4 and 5 Java candidates that have never touched UTF-8.
Finally, and let me blow your mind here, there are senior developers that haven't really used String#contains in the last X years of their career either.
I don't know what was the quality of the candidate, but I feel, from my limited PoV and lacking all the info, that your interview process is deeply flawed.
Honest question: I'd really love to know what UTF-8 traps people fall into all the time when working on a consumer product with Java - especially given that Java basically stores all Strings in UTF-16 (well, starting with Java9+ there's some "optimizations" made, but still). I literally can count those issues on one hand in over a decade of working on such (multilingual) products.
I also completely fail to see what a CRUD app (i.e. java + db) + shooting REST requests to confluence has to do with your concurrency questions, as in interview != job fit, but that might have to do with some missing context.
> The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.
This! When giving interviews last I really worried if the questions I asked where just indicative of my own Dunning-Kruger effect.
i.e. Do I only ask questions I already know the answer to and not questions I don't know the answer to?
If I do then am I just filtering for people with the same background and knowledge and missing out on people with other skills I don't know, because they're in my blind spot, I need yet?
> i.e. Do I only ask questions I already know the answer to and not questions I don't know the answer to?
I've been advocating for a "coding interview" where both the interviewer _and_ interviewee draw some random question from leetcode or other problem bank, and try to work at it together.
This would show collaboration skills, and you can tell pretty easily how helpful the candidate is with his/her contributions, and whether you find there is an impedance mismatch somewhere.
It probably also maps more closely to the kinds of interactions you'd have after the person's been hired.
I think it would also help calibrate: if you can't figure it out, is it fair to expect the candidate to figure it out? Maybe it's just a hard problem!
Curious about the age of the person who supposedly wrote it in 6 minutes. If you're fresh out of school, "String.contains" may be top of mind, but the vast majority of people never write that function in practice, so it's easy to not think about.
I don't do interviews in my current job (mostly because the pandemic really did a number on hiring) but in my previous job the only coding question I asked was what I thought was a fairly simple string problem. They could assume ascii, use any language they wanted, and make any other assumptions to simplify the problem.
My then-co-workers liked to ask harder algorithmic questions but I wanted to give the candidates a little bit of a break with something easier.
Yes and apparently clang is now suffering from Google not caring about latest C++ compliance.
Apple mostly cares about LLVM based tooling in the context of Objective-C and Swift, Metal is C++14 dialect, and IO/Driver Kit require only a subset similar in goals to Embedded C++, so that leaves the remaing of the clang community to actually provide the efforts for ISO C++20 compliancy.
Yep. If Clang doesn't have C++20 support by the time C++23 is out, I'm pretty sure my workplace at least will completely drop Clang and build solely with GCC. A win for open source, if nothing else.
Clang has a permissive license, GCC is (of course) GPL.
Which one is best for open source is debatable.
Permissive licenses make it easier for companies to make proprietary software, or even a closed source version of the original project.
Copyleft licenses (like GPL) are intended to promote free/open source software but they can be a legal headache, which can make users favor proprietary solutions.
On HN, I think that people tend to prefer permissive licenses (but complain when large companies "steal" their work, go figure...).
"Data-oriented programming" (to distinguish from object-oriented) is largely C-style C++ that is written for performance rather than reusablility/abstractness/whatever. In the embedded programming world where performance is paramount, a lot of people have low opinions of many C++ features. One could also never completely trust compilers to implement everything correctly.
I'm not saying that's a bad thing. Google usually has a good reason for what they do (not everyone is always happy with the reason, but Google can always explain why they do stuff).
I come from an embedded background, and understand that.
Go is also an outgrowth of the Google idea that was first expressed in their style guide of basically "engineers are too dumb for harder features, let's ban them in the style guide (for C++) or just not have them (for Go)"
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"
It's my understanding that there is a colossal gap between the hiring bar imposed by recruiters and the companies' HR department and what's actually the company's engineering culture and practice.
My pet theory is that HR minions feel compelled to portray their role in the process as something that adds a lot of value and outputs candidates which meet a high hiring bar, even though in practice they just repeat meaningless rituals which only have a cursory relationship with aptitude and the engineering dept's needs.
I don't think HR is really that involved in the hiring process. They certainly aren't at my company. They'll read the job posting and make sure that there isn't anything illegal in it, but then that's it. It's up to the Engineering Managers to come up with a process, and make adjustments when there are roles to be filled.
This is the first time I've been involved in coming up with the process, but from what I've observed, it's a similar situation in other organizations.
> the hiring bar imposed by recruiters and the companies' HR department
That is simply not how things are. The hiring bar is designed and upheld by people on the same software engineering job ladder as a candidate. The role of recruiters is primarily coordination. The role of HR is compliance with local employment laws.
This one is extra weird to me because I've written a lot of C++. I don't think I've ever committed a bug related to dynamic dispatch, templates, or some other "fancy" features. Not that I haven't committed bugs, but they're mostly either language agnostic logic issues or things one could have written just as easily in C.
Geohotz had a good rant about this once - the kind of people who need to cram leetcodes and memorize algorithms are not the kinds of people who Google wants to pass these interviews.
Makes a lot of sense, you could solve all these questions without knowing specific algorithms as long as you are good at problem solving - which is, I assume, the intent of the process.
> Makes a lot of sense, you could solve all these questions without knowing specific algorithms as long as you are good at problem solving - which is, I assume, the intent of the process.
You could solve all these questions as long as you are good at problem solving, *given enough time*.
However, with tight time constraints and perfomance pressure, the only way you could solve all these questions is memorizing and practicing all these algorithms.
There was a hilarious rant about a FAANG hiring question that was something like: "Write an algorithm for detecting if a linked list has any loops in it, in linear time, using a constant amount of memory."
Apparently the correct answer is to use "Robert W. Floyd's tortoise and hare algorithm", which is trivial to explain and code.
The catch?
It took a decade of computer science research between the original statement of the problem and Floyd discovering the solution.
So... no worries, you have an hour, a marker, and a whiteboard. Your time starts: now.
I'm just imagining an engineer coming up with a novel solution to this problem in under the hour deadline and then not getting hired because it's not the "Robert W. Floyd's tortoise and hare" algorithm.
"So we specifically asked for linear time."
"Uh, yeah, I did it in log(n). That's better."
"It doesn't match what's on this paper they gave me. Thanks for your time. We'll be in touch."
it took a few million years until Newton figured out basic mechanics. but i don't think it's unreasonable to ask a junior engineer some basic kinematics questions!
You’re expecting the mechanical engineer to recall something they learned about kinematics, not derive it on the spot. It’s a test of knowledge, rather than cleverness. The equations of motion are also more central to physics and engineering.
A decent programmer should know that linked lists exist, their general properties, pros and cons, etc. However, cycle detection is not a particularly common operation, so not knowing Floyd’s algorithm tells you very little—-and their failure to do years of research in 45 minutes even less.
Yeah, I think a closer analogue would be asking something like "derive the conserved quantities of the gravitational two-body problem" and then dinging candidates for forgetting about the Laplace-Runge-Lenz vector
A software engineer? Sounds totally unreasonable. A mechanical engineer, sure, it's going to be required material on their education.
The tortoise and hare algorithm is not the foundational skill required to make software work the way an understanding of motion is for building structures. That's why it's often omitted from educational material yet these people are able to produce usable software after even something like a bootcamp (which I guarantee basically no bootcamps ever touched this algorithm).
I'm not sure I approve of asking even more well known algorithms like Djikstra's algorithm or A* in a job interview, unless the role was something that specifically required that area of knowledge like building pathfinders for video games or robots or something.
If they actually aren't looking for people who just cram CTCI or leetcode, coming to this answer from first principles is demonstrably far more difficult than you'd expect achieved in an interview.
Which becomes forgotten knowledge in about 6 - 12 months time after you've last needed to apply it, depending on how often you'd have to use that information.
These sort of questions have an incredible recency bias, and have zero relevance to engineering competence.
I have a theory that these q's legally favor recent grads without having any explicit requirement to do so. Helps them filter for young, freshly-trained students who they can mould into whatever they like inside of the FAANG-bubble.
It's funny you put it this way. I actually did a couple of hard level Leetcode problems and I thought they would help me immensely in my day to day life in addition to helping me get better at interviews.
No such avail. In fact, unless these algorithms and problem solving methodologies are baked into your memory there's no way you are white boarding a Leetcode hard level problem in an interview.
What I was impressed at an Uber interview was their system design interview process - which basically boiled down to 'how do I abstract retrying a 429 - rate limit exceeded.
What I take is that - the interviewer is expecting a very specific solution even in an open ended system design question. It's like throwing a needle in a haystack at you and expect you to get to the needle in like an hour :).
>> which basically boiled down to 'how do I abstract retrying a 429 - rate limit exceeded
They're probably looking for some sort of variable refilling leaky bucket implementation, which is funny because I believe this is exactly what they do internally. It was probably the task the interview had in front of them in their day-to-day and wanted you to do it for them!
This is a fair design question for a senior role (which this sounds like) that promotes disccussion, but expecting a specific solution is really only testing "does this person match my preconceived ideal for what a <dev> is?" which is really dangerous and has very little value.
> the kind of people who need to cram leetcodes and memorize algorithms are not the kinds of people who Google wants to pass these interviews.
I thought it was exactly those who Google wants to pass. Anecdote: ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google. His knowledge about algorithms and data structures was like mine: I know what a tree is, I know there exists operations one can perform on them and some of them are more performant/efficient than others... but I would need to Google how to "reverse a binary tree" if I had to do it in less than 1h.
I read an article recently about Google’s fairly awful interactions with HBCUs (historically Black colleges and universities). One thing that caught my eye was Google’s disapproval of seemingly standard CS programs in favor of a syllabus for cramming algorithms into student heads. That was one of their excuses for hiring differentials.
The "reverse a binary tree" problem gets often brought up as one of these tricky algorithm problems that you just have to know. However, the "algorithm" is to just swap all of the left pointers with the right pointers in each node.
The biggest difficulty for most seems to be that they don't know what "reverse a binary tree" actually means. It sounds kind of mathy and opaque, so I get it, but candidates should be able to have a dialog to figure out what the requirements mean. And on the flipside interviewers should be ready to have that dialog and not count not knowing the term by heart against the candidate.
This problem to me feels qualitatively different than the "rabbit and hare" algorithm for finding a loop in a linked list mentioned by another poster. That one needs a non-trivial algorithmic insight that just might not come to you during an interview. The solution to "reverse a binary tree" flows out of the structure of the problem statement as long as you have the fundamental skills for walking and manipulating data structures and the conversational skills to understand the problem, both of which seem fair to test for.
I think being able to pass a FAANG level coding interview with 3 months prep is a better indicator of their intelligence than one coworker's opinion, which could be clouded with biases.
And I think the vaunted "FAANG level coding interview" is a prime example of a setting where three months of hard swotting can make even a relatively dim bulb shine brightly.
A tree for performance? I've used a rope once or twice.
Plenty of times where I've used trees because they're the logical representation of the problem (ever had a field called "children" in your code? HN comments are a tree. Etc.)
A perusal of Google's recent software track record would indicate that optimum efficiency aided by a wide knowledge of a library of algorithms and manual implementation of the same is either not what Google actually cares about, or if it was what they think they care about, not effectively delivered by the steps they take to achieve it.
I went through a marathon of interviews for one FAANG company (8 in total - coding screen, 4x in first round, 3x in second round). I did enough preparation to remember quite a couple of the Leetcode solutions by heart. I was pretty much a code printer if I got one of those, not much thinking involved anymore. I reckon it was clearly visible that I've seen a similar question before which is unavoidable if you've done enough prep.
While it's probably not what an interviewer is looking for, having the most common solutions memorised gives you an advantage of time. A coding interview usually consists of two challenges. If you get stuck on the first one and take too much time to answer it, you won't have enough time to go through the second one.
To avoid the code printer perception you can always go through an explanation what alternative solutions could be applied to the given problem, what their complexities would be and why the one presented is the best.
You need to act and pretend to think it through. Then you seem like a brilliant programmer they want to hire rather than someone that recently worked on the problem.
> Geohotz had a good rant about this once - the kind of people who need to cram leetcodes and memorize algorithms are not the kinds of people who Google wants to pass these interviews.
>Makes a lot of sense, you could solve all these questions without knowing specific algorithms as long as you are good at problem solving - which is, I assume, the intent of the process.
That's just absurd. If someone with no "algorithm" experience who was a good problem solver had to work out an answer from scratch for the interview its almost certain they're going to find the brute force answer and FAANGs pretty universally want the most efficient one so these people would routinely fail.
Its totally clear that what FAANG hiring optimizes for is recent CS graduates who passed tough Algorithm weed out courses at well known colleges in the past 18-24 months. They are young with no families or obligations and are happy to work 12 hour days at Google because they have hip open offices and ping pong tables.
I've mentioned before but at my previous FAANG gig everyone only looked at the resumes they were assigned to interview like 15 minutes before the interview time was scheduled down the hall / building somewhere.
No one knew who they were interviewing or what was on the resume until they glanced at it while walking to the interview room. I suspect all interviews and the process are just made up as folks go along, and half the time you get a gig or not mostly based on if one of the people you talk to is in a good mood or not.
One could argue that, when you're interviewing a lot of candidates and your acceptance rate is low, it makes sense to maintain a consistent approach to interviews. For example, asking all candidates the same question would help you develop a better sense for what a good discussion looks like, where candidates tend to struggle, how to help them along without solving the problem for them etc.
This is in contrast to tailoring each interview to a candidate's background.
With that, I think looking at a candidate's resume 15 minutes before an interview is not that unreasonable.
What am I missing?
(edit: this is meant for IC roles rather than management)
There is no consistent process anywhere in any of the interviewing loops, it is all random and made up as everyone goes along. There isn't any deep insight or thoughtful discussion and lots of work being put into the process, it is an afterthought and squeezed in during the day between other fires which are burning, none of which are good for the interviewee. This has been my observation at about every company I've worked for since I've been in IT.
My profile on LinkedIn for the longest time stated "No PHP jobs please" as a way to weed out recruiters that would send me job offers for PHP roles on the basis that I once did some PHP.
I've updated the profile to include "No FAANG companies" because I'm pretty sure I would not be a good fit for them but that didn't stop their recruiters from pestering me.
It may be a random walk but I think the goal is to convince whoever gets hired that they’re special and talented and elite members of their discipline.
Harsh hazing and initiation rituals are a pretty effective way to build team "spirit" and make people believe the group they've joined is special, and being a part of it makes them special or better than non-members. It may or may not be part of why FAANG interviews the way they do, but it is likely part of the outcome.
I interviewed 100s of candidates and there was this one guy that I would pair up with and he never said yes. I’ll never forget one candidate absolutely nailed it and his retort was “no, she clearly memorized the answers” so yeah, don’t take it personally.
I think there's probably one or more "real" filtering steps to start with, but after those steps there's still way more qualified candidates than positions to fill, and at that point the only possible solution is to choose randomly. But that's not "satisfying" so instead they just keep interviewing and finding reasons to reject people (all completely arbitrary, since everyone is already qualified) until they reach the target number, at which point all remaining candidates get offers. Which effectively results in wasting a bunch of everyone's time and then choosing randomly anyway.
(This is a massive oversimplification, of course, but you get the idea.)
You don't pass a FAANG interview by looking up all the questions and memorizing them, you just get a feel for what they'd ask you and learn how to respond with what they want.
I've never written a sort from scratch since my college days, over 30 years ago. Also never had a job interview that asked me do to so, or any other coding questions. I'm planning more for retirement than a next job at this point, but I shake my head at what my younger colleagues need to go through these days for the opportunity to write JavaScript with IDEs that do most of the work for you.
I sometimes have to implement a sorting algorithm when I write bare metal code that doesn't have any sort of standard library available. Of course, being a 1337 hacker, I then resort to the state of the art bubble sort. Or maybe an insertion sort if I'm feeling fancy. But enough bragging.
OT: I wish I could relocate a blog post (on Microsoft’s site, I think) about a very a naive and “obviously wrong” sorting algorithm that a dev identified in their (Excel?) codebase. Turns out the code was naive because the vast majority of their users were sorting very small sets of data and the implementation actually performed much better in those circumstances.
Funnily enough, if you're sorting small amounts of stuff it does not matter what algorithm you use. If fact your O(n log n) sorts are probably a lot slower on less than some millions of elements.
I liken it to what lawyers go through with the bar here in CA. It's gatekeeping.
Just like I don't think the CA bar should have a pass rate in the 20% range, I don't think coding interviews should ask riddles that are nearly impossible to solve on the fly unless you get lucky and memorized THAT riddle in your studying.
A big part of the problem that usually never gets discussed is how the lack of institutional trust between tech companies affects hiring and interviewing. There's no licensure in SWE, so in a sense your reputation is based on the companies you've previously worked for. But it seems like even if you have "name brand" corporations on your CV, other companies have no trust that your experience indicates competency. So engineers are forced to go through the leetcode grind every three years (or whenever they change jobs). Seems highly inefficient to me, especially when it's advocated by technologists who say they want to "automate all the things."
This is definitely true. But, let's be honest here: anyone who's done at least 10 or so standard, ~1-hour technical interviews has probably run into a candidate who looks great on paper, but just can't demonstrate enough basic skill to do the job.
One such candidate I interviewed seemed like they'd be really great for the role: PhD in graph theory, publications, projects listed on the résumé, couple of different programming languages (including ones we used). To me, this person's résumé screamed "solid mid-level developer." I would have probably been willing to pass them at a junior level, had they been able to perform at that level, though.
The interview itself was a pretty familiar story. For the technical portion, I introduced the problem (not a LeetCode-type problem, a more practically-oriented problem), we talked about requirements, drew some stuff on the board, and then got to coding.
I had a feeling when we were going through the requirements discussion that this might not go as smoothly as I'd hoped, but I pushed that feeling aside and did my best to let them shine.
We let people code in any reasonable programming language, but they must write actual code. They can fill in stuff like dummy helper functions, if necessary, but we want to see some kind of running, syntactically correct, and, preferably, at least lightly tested code.
They chose to code in Java, which, while not a terrible choice, seemed to me kind of like they were just handicapping themselves when stuff like (IIRC) Javascript and Ruby were listed on their résumé.
To make the long-ish story a bit shorter, we muddled through trying to implement the requirements we'd talked about earlier in Java, meanwhile the candidate was showing me a distinct lack of familiarity with basic facilities of the language, such as "what sort of methods do lists have that might be helpful here?"
Needless to say, this person did not pass my interview, and we did not end up hiring them. But, I really, really wanted them to succeed. Like I said, on paper, they look great. And, I'm sure they could have gotten through a culture fit interview just fine. I'm just not sure how well they would have done on our team, working on our rather large, pre-existing, and somewhat crufty code bases.
If you can figure out a good way to automate the task of "filter these developers down to the ones who can write some semblance of code," in a way that goes deeper than just "Write some code and run it against our automated test cases," I'd like to hear about that. And, I'm not doubting that it could be done, in theory. For instance, maybe something like the engine behind GitHub's CoPilot could provide a way to analyze and grade the candidate's code on things like style, testability, test coverage, modularity, &c.
But, AFAIK, there's nothing like that out there now, so, a structured process consisting of ~1-hour technical interview sessions, one-on-one with the candidate, attempting as best as possible to simulate the real work environment, is about the best I can think of.
My first degree was civil engineering and I took the California Engineers in Training exam back in my college days and boy was it tough even though I had stellar grades from a top university. You could bring mountains of reference books to the exam but you had no time to use them. You had to solve endless problems based on fundamental techniques you already learned during your education.
Oh, I'm not about to claim that these licensing exams people in other professions take once and then never worry about again (bar exam, medical boards, etc.) compare in difficulty to a typical SWE interview.
But, here me out here:
Suppose the CA bar exam were changed in format to be more like a SWE interview. That is, instead of being a 2 day affair consisting of 5 essays of 60 minutes apiece, a 90-minute performance test[0], and 200 multiple choice questions, let's shrink it down to a format that fits in one day and under 5 hours.
Now, let's nix the performance test right away, because it would be incredibly difficult to shoehorn in any kind of real, practical task in under 90 minutes.
According to [1], it looks like 100 multiple choice questions are allocated 3 hours worth of time. So, basically, our cut down format could be 100 multiple choice and 2-3 essays. So, that's about half the amount of testing that's done currently, more or less.
Now, if you have half the amount of testing available, you have a choice: you can cover half as many areas of law, you can cut down the depth of coverage in each area, or some combination of the two. In any case, what you've done is increase the variability in the test. In other words, passing is now more likely to be influenced by exactly which version of the test you get.
If there's an area of law you're weak in (say, bird law), it might not even be covered. Conversely, if you're a real expert in bird law, you won't get as much of a chance to shine in the new format. That means our new format both allows somewhat more marginal candidates to pass, and gives up some sensitivity in detecting people who are really, really good.
So, in summary, the new format omits any sort of practical task, increases the variability of the test, increases the probability that marginal candidates will get through, and decreases the ability to distinguish truly excellent candidates.
Seems to me that's sounding more and more like a typical day-long SWE interview, isn't it?
While I do agree the CA bar is tougher than it should be, a lot of the low passage rate comes from graduates of less-than-stellar schools. If you look into passage rate per school it’s naturally much better at the higher ranked universities.
Isn’t that almost the definition of gatekeeping? Make the process to enter the law profession so difficult that only students from select universities have a good chance.
Of course prospective lawyers should clear a certain level of knowledge before they are allowed to practice, but the passing rate is puzzlingly low. CA law schools, as a group l, really only prepare such a low number of their students to practice?
Law school teaches you theory. The practical part is supposed to come from competitive internships.
The bar is hard for CA because we go to school for the theory and then no one really teaches you the formulaic way to answer bar essays. Add on top of that it's a lot of memorization and study. Most students I went to school with had egos and thought they had it in the bag only studying on the weekends.
shitty law schools has become a huge problem in the last couple decades. similar to ITT tech or phoenix online. They drastically lower the lsats needed to get in, then almost no one becomes an actual lawyer from that school, but they do get 100K in debt.
also, gatekeeping has a negative connotation because it is usually used when it seems unwarranted. If only schools with high quality education are passing students, that doesn't seem like a problem with the gate, but instead with the other schools. I absolutely want lawyers and doctors to be required to pass certain criteria.
Well, not exactly. You need to have a certain level of competancy to be an effective lawyer. Those who arent “good enough” for the better law schools are often preyed upon by overpriced and underresourced schools to give false hope those who couldnt cut the mustard. Not saying you cant be successful if you go to a crappy school, but the chances of it happening are slim to none. Just look at pass rates of Whittier (I think they’re shut down now) or Thomas Jefferson and then look at the tuiton rates. And this isn’t even counting the non-ABA approved schools...
many people including myself believe that availability of legal services is broadly lacking in the US. not necessarily a shortage of attorneys, but a shortage of attorneys that can do work for anything but top-quintile clients. artificially restricting who is and isn't allowed to perform certain jobs often has that sort of effect.
attorneys multiply when left to their own devices, which is often bad for society.. (since like law enforcement and middle management, LOTS of new people every year want the job for all the wrong reasons) so California Bar limits the new attorneys, which both lessens the total number of attorneys, and also advantages the incumbents.
Not all younger developers have to jump through those hoops. There are plenty of companies that don't do that kind of nonsense, because they're trying to hire good engineers, rather than, specifically, engineers -- good or bad, that'll get sorted out later -- who will happily sacrifice their spare time to figure out how to jump through the arbitrary hoops that their jobs entail.
Holding this kind of bullshit interview isn't a bad idea if you're a megacorp with chaotic teams and fourteen levels of management hierarchy where people spend most of their time on infighting and career building. You need people who jump through hoops, because successfully delivering most projects in these environments is 10% difficult technical work (which the good engineers can handle, and you can typically hire enough of them via recommendations), 40% YAML-poking bullshit work, and -- optimistically -- 50% jumping through all sorts of technical and non-technical hoops, most of them self-inflicted.
I navigated this kind of process successfully early in my career, and the only thing that made me more miserable than interviews like these was the work I got to do afterwards, after accepting the offers. Once is happenstance, twice is coincidence, three times is probably just how these things are -- I'm now pretty convinced that the quality of the interview is (barring statistical accidents) highly correlated with the quality of the actual position.
It's very difficult, because making sense of the examples would require explaining all the convoluted decisions and corporate mechanisms behind them, and that would make it trivial to identify the companies in question.
I can give one example, I guess, since it's been a long time, it's a very common scenario, and this is an internal thing, so anyone who can identify it is either already there (tequila's on me this evening, mate) or has worked there before (I'm still up for tequila).
The buggiest component in one of the projects was the testing framework. It was a home-grown testing framework, incredibly slow (think "takes about 5 seconds to send a 20-character string over a 115200 UART line"), and it had a huge bug backlog.
Virtually all bugs got closed with WONTFIX. The person who'd written that monstrosity had made it up the management line, and his minion was now in charge of the team that allegedly maintained it. Since all sorts of bullshit metrics like bug fixing rate and total number of bugs and whatnot came up during quarterly operational reviews, a low bug count was nice to have. And since no customer ever complained of a bug in the testing framework, for obvious reasons, all that was required to keep the bug count to zero was an understanding between these two guys that all bugs would just get closed.
So you had to spend a few hours finding creative workarounds, since the two-line fix you'd come up with in five minutes would never get applied. And I mean creative. We had code that literally eschewed non-functional framework code by exploiting a race condition in its code in order to do RPC calls without going through the buggy framework code.
Now imagine you have to do something like this for every single task you do and you have a pretty good idea about how it goes. I mean you technically spend 100% of the time doing what you're supposed to do, but only about 30% of it is actually what you're supposed to do, everything else is mostly fighting cargo cult practices, senior engineering ego, and management disinterest.
I had one interview where they asked me to write out some fairly complex SQL joins on a white board. This was for a Java dev gig, NOT a SQL admin gig. I decided to really lean into how awful it was by putting in notations for three different implementations (Oracle, MSSQ, and Postgres). I was subtly making fun of them but they didn't pick up on it.
I got the offer and took it because I do contracting and had just unexpectedly gotten a contract canceled early, so I was unemployed and have a family. At the end of the 3 month contract they offered me a full time position and I declined.
I do my own Graph algorithm implementations sometimes
Especially when I'm not sure the Graph approach is the right one, it's easier than either
1. Getting the Boost.Graph in the source tree to actually compile
2. Dealing with the bureaucracy of getting some, other, Graph library requiring feats of compilation possible for mere mortals into the source tree
This is, however, not something I do from memory - much like the ancestor comment I see the relevant skill as closer to recognizing positive-weight Shortest Path and knowing you want Dijkstra than being able to write Dijkstra without wifi
I happened to have, by chance, practiced writing sort from scratch right before an interview where they asked me to do just that. Doing it correctly in just a few minutes gave me pretty high status. Higher than I deserve. The randomness cuts both ways.
> I've never written a sort from scratch since my college days, over 30 years ago
I didn't study CS at college, and I've never needed to write a sort on the job, so I've only ever written sorts in job interviews! I think I worked out a basic bubble sort, and told them it probably wasn't the fastest way of doing it but that it'd do the job.
I once had an in-person interview where they gave me a sheet of printed code and asked me to point out the syntax errors. Some interviewers are absolutely insane.
More than a decade ago I had an amazon interviewer write some perl on a whiteboard, and ask me to find the error.
There were two - I pointed out both and they didn't seem super happy about it. To this day I'm still not sure if one of them was an unintentional error.
A past employer of mine used to have one of these. It was a true work of art: around two dozen lines of code with something to discuss in EVERY SINGLE LINE, ranging from dumb syntax errors to logic errors to problems of overall design. Made for some great conversations.
The problem I see is that it probably looks really dense and complex the first time a candidate sees it. This is not a great way to start the interview. To me it comes across like "find Waldo in the next 30 seconds. Also there's a bunch of other characters hidden in there. Go!" We all know what we're looking for (kind of) but it's a very stressful approach. It might work better if you paired and wrote this crazy code, and looked to them to identify issues as you built it up.
I had to review someone's PR for one interview. Ultimately I failed it because me feedback focussed solely on implementation details and asking if there are better ways to solve the problem (with some suggestions as a nudge). Apparently, that was fantastic and showed all the qualities of good coaching...but they expected me to point out all of the instances of poor indentation and other aesthetic things. My justification that it was unimportant and that running rubocop would fix it wasn't good enough - the PR had to know all of the nitpicks.
You know, if I had to do that for every PR I reviewed, I'd be burned out in no time.
It was a shame, but if I didn't flunk that interview then I wouldn't be where I am now.
Done right there will be a lot more in there than syntax errors. A good example of this sort of test will separate those who have revised syntax without really thinking (they'll get the syntax errors but little or nothing else, great if you want to employ a human linter) from those who actually think about what they are looking at will spot much more (a logical error that would cause an infinite loop, a point where a comment and the code disagree, an incorrectly validated input, an injection flaw, a heavy expression inside a loop that could be done first and result-cached for efficiency (your compiler cannot always identify such situations), hard-coded credentials, bad naming, ...). The best may identify some but also state why in the grand scheme of things is might not matter (efficiency in code that runs once so 10μs and 100μs is statistical noise) or where other priorities might take precedence (for example readability and therefore ease of maintenance).
Does this kind of trick question work well in practice? If they explicitly ask for syntax errors it would be a waste of time to also check the code for other errors. I can’t imagine many people opting to do that unless they know it’s a trick question.
It shouldn't be a trick question, but an open one. “What can you see wrong in this code?, there are a few things, we don't expect you to see them all”. For non-junior starters it is effectively a simulated code review — can this candidate spot problems before they get committed further into the pipeline (and hopefully avoid them in their own code).
I don’t see what information people can glean from those trick questions.
Any time I’ve interviewed people I’ve made it a point to emphasize that none of my questions are trick questions and if anything is unclear, they should ask clarifying questions. The result? Interviewees are more comfortable and are far more honest about what they know, what they don’t know, and you get to see a glimpse of what they’re really like.
"Basically, I will ask you questions, and hopefully you will give me answers.
It is fine to say 'I do not know'. It is fine to guess, but if you do, I would prefer that you tell me it is a guess.
If you want any clarification, I will try to provide it. If you don't recall the exact signature of a library function, ask me. I will note down what I said and not hold incorrect nformation I give against you.
What is super frustrating is that these same companies and people are convinced they can find game-changing productivity gains in software development, like magnitude-level improvements, yet ask questions that, what little increases we've made in the past 50+ years have made trivial.This is just a lazy question.
Your IDE can check your syntax. For people who have to switch between languages regularly, precise syntax memorization is difficult and a waste of time.
Your IDE can tell you if your syntax failed to represent any valid program. It can't tell you if your syntax represents the wrong valid program. If you can't even spot invalid syntax, you have no hope of spotting bugs, because you can't read what the code says. Which turns out, contrary to your beliefs, to be important for many purposes.
That doesn't mean you can't debug. You can step through the code step by step in the debugger, or add more and more logging around the bug, until you figure out which expression has a meaning unintended by its author. But that means that, if we're working in a language someone knows well, you're likely to spend hours debugging a problem that they can just see immediately when they're reviewing a merge request. That's an orders-of-magnitude difference in productivity when it's important for code to be correct, precisely due to what you call "precise syntax memorization".
Most of programming isn't writing code. It's reading code.
It's possible to go overboard with this. There are other skills that are more important than being able to look at some code and immediately see what it means. There are excellent programmers with severe dyslexia who will just never be able to do this. But it's foolish to think that gaining this skill is "a waste of time" for those who can.
There are languages I've used where I don't know the syntax that well. PHP, Ruby, x86 assembly, OCaml. There are languages where I know the common syntax well, but there are plenty of obscure corners of the syntax that I don't: C++, Perl, bash. But I regularly switch between C, Python, and JS, and I'm pretty confident that I know their syntax, as well as numerous other languages like Tcl, Lua, Prolog, PostScript, and arguably Scheme and Elisp, which I don't use regularly but still wouldn't have any trouble spotting syntax errors.
I'd struggle to code a five-line program that'd compile in languages I've written tens of thousands of lines of code in, in Notepad, that'd actually compile & run on the first try. I might fail that in a language I was writing last week. I mean, I might manage it, but it'd be sheer luck. Decent chance I forget, in the moment and under pressure and without examples to crib off of, IDE support, or the ability to check the manual, the correct way to do comparisons for all types, even, or basic stuff like how to print to the console or what this language's sugar for a "for-each" is, or whether it has such sugar. Reading input? The right calls for file IO? Anything more complicated than that? Oh god, there's no way.
Luckily I never fucking ever have to do that in my actual job. If I did, I might well get good at it. Since I don't, I... don't. I also haven't gotten much better at driving semi trucks or framing a wall, in my over-a-decade career writing software. Go figure.
An IDE can check your syntax, sure. It can even catch low-level bad practices ("you're making a database call in a tight loop, this is horribly inefficient"). This is, in my opinion, basic tool usage: warn of LHF early.
Last time I saw one of those test-ish pieces of code, though, an IDE+static analysis would have caught about 1/2 of the problems; the other half required actual thinking (not statistical pattern matching, aka AI): "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."
> "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."
Good type systems do this, although it's beside the point.
The point I was making is that the IDE remembers unimportant things so that my only concern is the actual thinking part. It abstracts away the minor and sometimes very important syntax differences.
While I understand where you are coming from, I disagree.
IDE tools are great performance enhancers, but they can also be crutches.
I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits).
edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
Let's use (C++) something not common, but not all that crazy:
bool x = false;
x ||= something();
How many multi-lingual programmers will remember which one of the 7 languages they know does have a boolean assignment operators and which do not without looking it up? Does that make them unprofessional?
How many do remember exact operator precedence rules for all those languages, when in practice you may need just the basic ones and use () to work around the lack of exact knowledge.
Also which version? Something not working in PHP 7.3 may be ok in PHP 8, but company wants you to code in PHP 7.3, or ES5. In practice you get quickly acclimatized to any of the languages you know after working with them for a few days or a week, but good luck remembering exact rules of any of them at any given time when asked.
You're not mentioning or alluding to the one obvious syntax error. I don't know how to spoiler it so I will say there is an issue on the second line that, again repeating, I don't know how to call out.
also if you can't spot that error, you might not realize a subtle, yet important, detail about that line (if written correctly). contrary to what you might expect, it cannot short-circuit the way || does, leading to possible performance or even correctness issues.
This is very true. I hope that people are not using the short-circuit feature in a way that impacts correctness! I would have an issue with that code for trying to be too clever even if there were no bugs and it worked well.
Performance issues, on the other hand, I can see accidentally arising.
Yes, the "and" pattern is common. I've seen plenty of "ensure this exists before operating on it" chains, where it even goes if ( pointer && pointer->otherPointer && pointer->otherPointer->member == value )
I've never seen someone use an "or" pattern in a non-confusing way.
That is, I've seen "and" patterns that act as a safety/early out. I fail to see the use of an "or" pattern where you want to stop executing if the first value is true (ignoring using nots to invert the logic of an and pattern, and I would criticize that).
That boolean assignment operator was addressed. Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.
They do exist in other languages. ES has it in exactly that form. Java has it in the |= form, not to be confused with the bitwise OR of the same form.
Whether or not these short-circuit is not all that interesting for most boolean logic. (Though it can be useful to know if these are used as hacky error-handling and default-setting. It depends on how you read "something" whether or not that's going on here.)
Where and when? Because I was the only person alluding to it, and the replies to my post.
> Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.
C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
> > That boolean assignment operator was addressed.
> Where and when? Because I was the only person alluding to it, and the replies to my post.
The words "boolean assignment operator" are in the first sentence after the code snippet in megous' post.
> C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
As far as I can tell the |= operator in C++ is the same as in C, i.e. a bitwise OR operator. It works for booleans due to their bit pattern, but it's not the same. My C++ knowledge is extremely limited, so I looked it up and I may be misinformed though.
Java's |= is different for ints and boolean. There are no bitwise operators for booleans: bool1 | bool2 is a strict logical operation (that doesn't short-circuit). bool1 |= bool2 is a logical operation that will fail when other types are mixed in. int1 |= int2 is a bitwise operation. Java does not have a short-circuiting ||= operation (but ES does).
For the most part these differences aren't that important, but they do trip people up when switching between languages.
I'm just thrown for a loop. Why is the default to assume I'm familiar with the ||= operator in ES?
The fact that the ||= operator short circuits makes sense from an optimization point of view. I will maintain that there is no good use for the correctness (as opposed to optimization) of the code to depend on that feature.
How many of the multi-lingual programmers that know 7 languages are really good in all 7? As an interviewer and hiring manager I am more impressed of people than know 2, max 3 languages very well than 7 at an intermediate level.
I see this attitude in the corporate world and among people who are newer to programming a lot.
For skilled, experienced programmers, most mainstream languages become an implementation detail. You have to spend time learning idioms, footguns, and generally the way the language manages memory, but you absolutely can be great at 7 languages because they fundamentally do many of the same things.
I haven't hired people based on "their stack" in a long time, and it's been completely fine. Someone with skills can quickly learn your stack and be productive in it. I personally jumped on a project as a coder a few years ago having never written C# before, and I was productive in about a day. All the concepts were familiar, and the stuff I had to learn was mostly syntax.
Exactly. "If a person can drive a Honda, how well can he drive a Mazda?". Duh, just as well as Honda.
And just like the natural languages, the more you know, the easier it gets.
> All the concepts were familiar, and the stuff
> I had to learn was mostly syntax.
This reminds me how I have learnt to program. I grew up in then USSR, we had no computers at our school but we had programming lessons. So I was introduced to all the fundamental concepts: variables, assignment, loops, control structures, etc. When I went to university I finally got access to the computer (Yamaha MSX). And then it was exactly as you say: "what's MSX Basic's syntax for this particular concept?".
If a pilot is only type-rated to fly an Airbus 320 he is not allowed to even try to fly an 737 nor a different type of Airbus. This attitude of "a car is a car, what can go wrong?" is deadly in some domains.
In my (corporate) role most of the people around me have over 20 years of experience in a very specific domain (manufacturing execution systems) and it takes about 5 years to train a new person. Having someone new productive in month is a dream for us, but it never happened.
If you can be productive in about a day, please explain why a pilot gets ATPL (airline transportation pilot license) after a minimum of 1500 hours of flight. Also please tell if you would board a plane where the pilot has 100 hours - that's an awful more than a day or even a week.
I know what a language ought to be able to do and where the usual foot-guns are. I haven't even attempted to really learn a language thoroughly since my first one (Perl—and yes, that's probably part of where my brain-damage comes from). It's all the same stuff, more or less. Understand pointers and how things like how OO systems are usually implemented, how stacks work, that kind of thing, and all the languages start to blend together.
99% of the pain in a new language usually ends up being the (often god-awful) tools, platform/SDK bullshit, and learning where the clearest path is incorrect (no no no, the official docs and tutorials say to do it this way, but everyone who knows what's what actually replaces that entire part of the language/first-party libraries with this other library developed & open-sourced by some other company, since the official way is obviously so terrible, and you just have to know that, or notice by reading other people's projects—ahem, looking at you, Android). The language itself is typically nothing.
This has worked out fine for me. It does mean I've gradually grown to hate languages that lack static typing. I don't want to remember or look up things when I can make a quick note and then let the computer remember or look it up for me. I thought that was kind of our whole thing, no? Having computers do stuff for us, when they're able?
I think you overestimate the value of being super intimate with any given language. Pretty much no language in common use is so different from the others that you drastically have to change how you express any given thing you're trying to do. Knowing concepts and when and how to apply them is more important in my considered opinion.
In my opinion, if you're hiring for an expert in a specific language, you're not hiring a software engineer, you're hiring X language developer or X language software engineer. The language needs to be explicit in the position listing and perhaps even job title. That's fine if that's what you want but be specific about it so you don't waste people's time looking for a language specialist when most people anymore are generalists that have all sorts of knowledge distributions for any given set of technologies but can most likely adapt and learn to fit your distribution of technology given just a bit of time and opportunity.
Modern development requires juggling too many technologies for most people to specialize in a single language unless their career goal is to niche themselves to that language.
Someone doing webdev fullstack for more than 10-15 years will know at minimum ES + (PHP/Python/Ruby/Java/Go...) + SQL + HTML/CSS and a few utility languages.
So at least 4. If you combine webdev with something low level/embedded, you need at least one systems language, so you're at 5 languages you need to be proficient in.
Add one hobby language or a second web backend or systems language, and you're at 6 major languages.
7 is a lot. But 5 is plausible to be proficient in for someone who switches between webdev and lowlevel stuff to not burn out, or has a FOSS hobby.
I've shipped production code in 17 different programming languages. I wouldn't say I'm proficient in any one of them, they are all just tools to solve a problem and the knowledge of language specifics comes and goes. Need to hyper-optimize a DB query on an Oracle RAC cluster? PL/SQL. Need a shader? GLSL works fine. Need a webpage? HTML/CSS/JS. Need to build a 7' long flying robot fish? C. Programming languages are just tools.
In over 20 years of working in IT I never found a single webdev-type of person that can write an efficient SQL query by himself. Yes, most are able to write a query to bring the correct result, but I saw way too many cases where the perf test on a database with the expected production volume was running in completely inacceptable times and the developer had no idea how to fix that; for each version of SQL perf-tuning is very specific.
Also proficient != expert. I met enough developers that were brilliant in their work to be convinced that 5x developers are not a myth, but they are real, while rare, occurrences. For me a senior developer in X knows the ins and outs of that X to the level that his code is an order of magnitude better in term of efficiency, performance, productivity and security. A regular developer can be just proficient, but it is not what I wrote about.
It is an option, but how fast will they be very efficient? It takes years to master something and some people, not all, need to have that mastery level.
Yes, they are absolutely crutches. All great tools, libraries, and abstractions are crutches. I want programming to be easier for myself and my employees.
The only problem with a crutch is that you might end up not having it when you need it. That's not an issue in this case.
> here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
The original example that I was responded to was about an interviewer who expected their code to compile. That would include incredibly pedantic things.
For example, if you're the kind of person who uses single quotes in JavaScript and then you're suddenly writing a different language where '' is different from "" and `` and $"" and whatever, you could easily make an unimportant mistake that prevents compiling.
If a company did not run automatic tests and lints on whatever they felt was important to have when merging to production, to the fullest extent possible, I would stop everything and write those. This leaves reviewers free to focus on the intangibles: architecture, expressiveness, logic and data flow, and so on.
In my experience, Pull Requests aren't about catching syntax errors... the build will fail if there's errors like that. Rather, a Pull Request, and the code review involved, is about the underlying logic of the code; both with what it's doing it and how it's doing it.
I don't buy that argument, as a programmer you have to write out code following a precise syntax all the time. Programming would be insanely tedious without knowing correct syntax.
Having said that, if someone came up with an interview test which used especially esoteric parts of the language in unconventional ways and then asked to spot the errors, the could be a dubious question.
> as a programmer you have to write out code following a precise syntax all the time
When did I claim that the IDE absolves you of needing to know the syntax?
It doesn't. But between autocomplete, hinting, linting, and any other static analysis, it makes it close to painless to switch between languages without making horrifying mistakes. The top-tier JetBrains IDEs (IntelliJ and Rider come to mind) will even tell you ways to make your code more efficient or modern, like changing a bunch of if/else to pattern matching.
Why should I have to remember the full truthiness table of JavaScript? Why should I have to remember what all the different string delimiters do in every language? It's not important. My IDE can (and does) know that I'm trying to do some kind of string interpolation and will just fix it for me.
I think some of this is filtering out bullshitters. In a previous job I used to interview a lot of unfiltered candidates. What we did was sit them down at a Linux command line and ask them to show us the files in the directory, open a file for editing and that kind of thing. A surprising number of people who claimed years of Linux experience had clearly never used the command line at all.
I've tried questions like this (super basic but can quickly filter out people who know nothing), but sometimes the candidate seems insulted! I try to quickly move on to a harder question.
If you start with "I'm sorry if you find this question offensie, but recently we had a wave of candidates who had problems with basic things so we need to start from the beginning" and the candidate still feels offended, well, they're being offended too easily which might cause problems in the future.
I think people can still find it off-putting that after all the evidence they provided you to get to that point, you're challenging them to prove they aren't complete frauds. Like you could has spent 30 seconds googling them and verify they are legit, but it seems you didn't even bother to read their resume. Not saying it's the case, but rather that not everyone is aware of how good the frauds can be at presenting themselves and bullshitting through interviews.
I don't think the problem is offending the ones who know how to do things. It's making them think they're applying for a worthwhile job.
I remember thinking what you're writing about there, that there's a lot of people to be filtered out, and that good candidates wouldn't be offended.
So we had this simple two-part quiz question for people, starting with "what is the expectation of a dice roll?". Amazingly a lot of people can't figure this out.
But also a lot of people know the answer immediately and will wonder WTF you are asking such a simple question for. I remember this one lady who interviewed with my firm, the look on her face when she realized we weren't asking anything complicated. You could just tell she thought we were a bunch of amateurs, and she'd better be on her way to see some other proper hedge funds.
I could see it if you're resume talks about a whole bunch of intense recent development in the exact same language they want to test, but only then.
In contrast, I've been stuck in a giant multi-language integration-fest, and... well, there are definitely languages on my resume that I would not be comfortable being pop-quizzed on, simply because I've been using others for the past two years.
I've been doing C++ full time since 1996, and yet I frequently have intellisense warning me about forgetting something silly - like a missing capture in a lambda, or even forgotten semi-colons. That's because I'm not an f'ing compiler.
_Can_ I make sure the code is 100% correct before even compiling? Sure, but I'll spend an hour checking every detail, while intellisense does it while I type.
I mean, yes. In a whole program, typos or mistakes happen. No need to try to prevent those. So do spelling or grammar errors when writing in English. We expect a professional writer to have a human editor to catch those and not be perfect. But asking an applicant for a writing job to find the spelling/grammar errors in a paragraph seems reasonable to me.
The simple fact that you think so tells me that you aren't a programmer, and that you should stay far away from interviewing or managing programmers. About the only thing the two situations have in common is that both are based around a text-based medium; for the rest there is just no comparison between writing computer code, and writing text for humans. Have you ever noticed how very few people can actually write both good computer code, and good documentation for the users of that code? That's because they are completely different disciplines, requiring a completely different mindset.
Let's turn this around: if I were interviewed by someone who flagged down my code for missing a #include or lambda capture (both very easy mistakes to make), I'd know that the people I'm interviewing with are idiots with no understanding of the thing they claim to be testing me on. Would I want to work there? Nope.
You seem very confused. At first I was worried you misunderstood my text: maybe you have trouble with natural language but not programming (or maybe English but not code). That would certainly explain your claim that they are disjoint skillsets. But as you went on, you committed a logic error, so now I'm just thrown.
There is a difference between "find the errors in this provided code" and "write code on a whiteboard with no errors". At no point was I talking about code you wrote.
Also, it's an aside, but I find people who can program well write excellent documentation for the users, if what they are writing is an API. Of course, they are not the best at explaining the steps in a GUI, but that probably has less to do with communication skills in general and more to do with the difficulty understanding how they perceive the problem.
But yeah, I think I've seen questions like that for an intern positions. It's basically a "have you ever seen this language?" to weed out people quickly.
> It's basically a "have you ever seen this language?" to weed out people quickly.
It's not that. People who constantly use multiple languages in an IDE will not be able to point out most syntax errors outside the IDE. So it's not a "have you ever seen this language" filter.
> I'm curious what position would this question make sense?
I was once asked a similar but better posed question: I was given some code and asked what I'd point out if asked to do a code review on it.
And the code had loads of things wrong with it, from bad variable names and incorrect comments, through unit tests that didn't have any assertions and loops that weren't actually loops, all the way to choosing a non-secure random number generator in an application that needed a secure one*
In other words, it was a test of my ability to code review, with some glaring issues to give me some easy marks and set me at ease, and some subtle issues where talented people could really set themselves apart. It was fair and relevant to the job because I was presenting myself as a senior programmer with lots of experience doing code reviews and coaching junior developers.
It's possible trinovantes's interviewer intended to give the same sort of test - but either didn't explain the question clearly enough, or trinovantes misheard or misremembered.
Citrix gave me a page of code which had a lot of tricky obfuscated syntax problems. Code that looked live but was actually commented out, nested comments that were not terminated properly, code formatted in a very deceptive way, strings that were not quoted correctly so they would not end where expected on the page. It was all very contrived stuff that was deliberately deceptive, not like real broken code, and the errors would have shown up with syntax highlighting.
I caught most but not all of the tricks.
This is also the only interview I have ever had where a panel of engineers stood behind a desk and all barked questions at me. I did not get the job.
At a different interview, this one with Microsoft, the lead engineer showed me a page of actual code from their app and asked me what I thought. Luckily the bug instantly leaped off the page to me, although many people would not see it. That was a good way of proving that I have a useful ability, and a better use of time than whiteboard coding or quizzes. I got the job and they were glad they hired me.
I tend to believe that "walk me through a peer review of this code" is a great interview question. It speaks to the user's familiarity with the language, with problem solving in general, and also people skills. Sure, it's not the end all/be all, but someone needs to be pretty amazing to want to work with them if they are incapable of doing a peer review.
This is awesome and I think every company should do something like this. You get to ballpark technical ability really well while getting some very relevant behavioral information (i.e. what will it actually be like to work with this person, without lame ‘culture fit’ questions). It can be hard to test competence in a way that allows all kinds of devs to shine; code reviews are pretty unavoidable on the job though so it’s a good fit.
Coding is a mostly solitary activity that you probably don’t want candidates spending more than ~60 minutes on, ideally on something that resembles the actual day-to-day instead of sucking all the Leetcode possible out of them. Even just quickly pair programming on something nets you more data points in the same time.
Depends... imagine getting four pages of C# code and having to play Where's Wally but you're not even sure what Wally looks like. Surely it'd be better to just write FizzBuzz.
It's literally asking someone to write perfect code in a time limited situation, under pressure, how can someone with any kind of coding experience ask someone else to do in an interview?
Not one person ever code reviews code that was not already compiled. Requiring you know the syntax of a programming language (in my case, Swift, changes syntax in every release) outside of a compiler is pointless. I remember in the early days of J2EE people asking you for the home interface of an EJB stateful session bean. Like who the hell cares about memorization in the era of Google, and that was 20 years ago when Google did no evil. This isn't first year computer programming 101, you are paid to make things that work, not regurgitate syntax.
We may have had the same interviewer- tbh I thought this was pretty reasonable and more of a warm up really. I think this also lead to a discussion on some questionable logic and how you could improve the code.
I had 10+ years experience in C++, I thought it was completely reasonable. Especially compared to their later questions around something along the lines of finding a shortest path in a tree. I interviewed there a bit before their process was so well known to be game-able, I went in with zero study time on obscure algorithms outside knowing the O(N) of the most widely used, and certainly did not practice actually writing or interacting with trees and such.
There was a function with a syntax error, that also returned a pointer to stack memory, and made some logic error where it assumed a class with no vtable would be polymorphic.
I have done this. Is it really such an insane idea? Makes for a nice break from "what does this code do"? You need some technical "anchor" to make for more concrete discussion points.
Would you accept "my build toolchain and linter will catch all of these syntax and stylistic errors." as an answer? 'Cause that's what all your devs are going to do IRL.
Not really since that doesn't leave much room for discussion, but that is my problem not theirs. The point is to have something to discuss, not to listen for a singular answer. Now we can discuss hypothetical situations and philosophy but I'd much rather have a concrete piece of code to go through.
Seeking out problems and errors can be a good conversation piece. Hopefully you get to hear some anecdotes, prod the taste in style and how well that that taste might play with others. The interview situation isn't easy for anyone, and anything that can if something is even remotely qualified helps.
I worked at a place that did something similar. VBA code, printed out in a proportional font, no word wrap so long lines spilled over...
"What does this code do?"
That was a pretty easy one to figure out, it pulled coordinates from a database table, and then it stepped along all the lines trying to find the longest one (they were a metal shop).
"Do you see any evidence that this code has been optimized?"
wait until you see this asshole move being pulled to find a bug in production code under time pressure their team has failed in the real environment by being given out some thousand-lines long printed code from the development branch.
I've been working in C for most of my career and I've never heard of such questions. They're not in any textbook I'm familiar with. In fact they're incredibly pointless and irrelevant.
What about it is disrespectful? It seems to me that it’s testing for something relevant and I don’t see it as otherwise bad (abusive, pure trivia, easily Google-able, etc)
It is akin to giving a spelling quiz to an author. There is a level of decorum required when dealing with professionals. A junior verbally pointing out a syntax mistake reveals a naiveté about the competency itself and "the mission" of the field.
In this interview, I would have liked to receive two code examples (that might contain errors) and discuss benefits according various objectives.
If the interviewer makes it clear that pointing out syntax mistake is not rude, I could mention them in passing. This demonstrates not only attention to details but also decorum.
I once halted an interview because of this kind of thing. Told them their interview process suggested they were looking for someone substantially less experienced. When they then insisted everyone had to go through this, I told them that was a warning sign to me that their hiring process was a box ticking exercise rather than addressing the actual needs of the positions they were hiring for and that I was no longer interested.
Recruiters need to understand that these kinds of processes will often filter out the wrong people, such as those skilled enough to be able to pick and choose.
A lot of interviewers have complete leverage, so they don't get any sort of feedback or real check on their ability or processes. It's only when a candidate isn't desperate for the position, is competent, recognizes red flags, and gives them the feedback that they'd ever be aware of. You don't have to be upset to realize there's a mismatch and withdraw your candidacy.
Candidates often have to call out nonsense otherwise it may never be called out. Processes need feedback to adjust and adapt, otherwise they'll typically continue with momentum alone.
With that said you can give feedback in a polite and professional way, you don't have to be arrogant about it. "Based on the questions, it appears you're searching for these specific abilities which are often attributed to a junior role, so I believe I may be a mismatch for this specific role. I'm going to politely withdraw my continued involvement in this process. I appreciate your time and interest and hope you will contact me if a more senior role is available." Or something to that effect. You don't have to be arrogant to give feedback.
If you were like "what, this is ridiculous, what am I am an intern? Good luck filling this trash position!" And then walk out then sure, that person clearly had some anger management issues.
I once interviewed for a director role and the first round went something likes this:
Interviewer: How would you reverse a string?
Me: boggle Any language I want to use?
Interviewer: Yes.
Me: Okay, Ruby. "somestring".reverse!
Interviewer: boggle
Me: I don't think we're aligned on what this role is. says thank you and leaves
Interviewers need to understand what they are interviewing for.
I mean, it all comes down to how that situation is handled.
If OP was a dick about it, then yeah, it serves to filter out an arrogant assbag.
But if OP simply explained that the interview led them to believe the position was a more junior/entry level than they were expecting, that seems fine. Further, to even explain that the interview process seems to just be a checkbox process seems fine; if you work in a critical thinking/creative role, checkbox culture is an absolute brain drain.
Getting that out in the open, in honest and respectful terms, is a fine thing to do. Why wouldn't it be?
Further, any hiring institution that feels the need to build in 'tricks' to filter people out of the interview process is toxic. Even if the people they're filtering are arrogant assbags.
If a prospective employer has a hiring process that is wasteful and pointlessly bureaucratic and tests people for things entirely irrelevant to a role, that tells me they're likely to be an awful place to work and/or don't understand what they're hiring for (which is likely to make them an awful place to work too).
If you I consider that arrogance, then so be it. I consider it not taking jobs that'd make me miserable, because I don't need to.
A prospective employer doesn't have a right to have me bend over for whatever process they'd like.
TBH, aeons ago, we had this as a high-pass filter (doesn't notice a glaring SQL injection hole, no problem with eval() on user input? Nope.) and a conversation starter (-why are you constructing a database handle right in the middle of business logic? -indeed; how would you do this?)
It very much depends on the code - but I was genuinely surprised how many applicants, claiming to be fluent and applying for a senior developer position, had problems just grokking what the code did (a while loop reading from database).
Definitely not - if an author has written a book in German (even if it's not their native language) then giving them a German test is definitely insulting, the same applies for a newscaster in Italian if they have done reporting in Italian previously.
What you say applies if you're hiring people for their first position at that task (e.g. the author writing their first book in German or a newscaster who has never done reporting in Italian professionally). If you're hiring people at some hypothetical "level 10" then your interview needs to discriminate between "level 9 or less" people and "level 10 or more" people, but asking them to assert that they meet "level 1" implies that they might not, and that implication is literally insulting.
In the interview case, you often have someone who claims they wrote a book in German (but you can’t see the book) or to be a professional Italian newscaster (but you can’t see any of their reporting).
Switching part of the interview to be in Italian or German would not be seen as disrespectful, right?
It’s interesting that some find the coding equivalent insulting rather than merely a bar pointlessly laid on the ground to be stepped over.
The difference IMHO is in the expectations of what's required from the applicant. Switching part of the interview to be in Italian or German would not be seen as disrespectful as it does not add much (if anything) to the length of the interview, but asking them to fill a 30-minute quiz on basic Italian/German grammar would be disrespectful.
A bar pointlessly laid on the ground to be stepped over is reasonable iff it's you can just quickly to step over it - but if they ask the candidate to waste half an hour to prove their capacity for stepping over bars laying on the ground, that is disrespectful of their time.
For programming, a trivial short task (e.g. fizzbuzz) is appropriate but a trivial long task is appropriate only for junior positions but disrespectful for senior ones - ask something that tests whether they're capable of something serious, because passing the trivial task can't be sufficient anyway.
I think the issue is what happens if an author ghostwrote a book in German? I guess that's the book version of copying code off Stack Overflow and claiming it's yours? People trying to game the system make it crappier for everyone else.
Then do it in a different way. Phrase it as a toy pull request that the reviewer has to review, and let that contain everything from minor syntax errors to logic errors to missing core stuff (like missing test cases).
That's why you are reviewing a pull request in your IDE.
And you are having a CI build and unit tests in place. If it doesn't compile or a lot of tests are failing, a sane person won't even bother to review a pull request.
Serious question, as I've never done a PR in my IDE; hadn't even thought to.
If you check out the branch in your IDE, is there a way to have it highlight the changes in the branch you're reviewing? Or do you need to reference the output from `git diff` or the github PR view?
3. Open the branches listing panel in the sidebar.
4. Mouseover the target branch of the PR
5. There's an icon that looks like two nodes with arrows pointing between them. Mouseover text "Compare with ...". Click it.
6. The search and compare panel in the sidebar has a listing of files changed, you can click a file to get a diff view.
There are gitlab [1] and github [2] extensions which streamline this workflow if your code is hosted on one of those services, and let you leave comments in editor which show up in the web UI.
IntelliJ has support for display a diff for a branch or github PR built in [3] but I hate their diff modal view.
My lesson learned was "don't listen to what they say, watch what they do". As in, don't trust them to tell you what they're looking for, understand that figuring out what they're actually testing is also part of the screening process.
I don't see a lot of focus on the hide-the-ball aspect of interviews, but is something I've experienced a few times and bothers me way more than anything else.
The clearest time this happened I was told the company was big on pair programming, so I'd be doing a pair programming session. It turns out they meant I'd be tested on whether I could finish a coding exercise in the allotted time with someone watching. There was zero "pair programming" of any kind involved and time spent on collaboration counted against me.
Back when I wanted to interview at google, I sensed some frustration between HR and the engineering. Some engineers just didn't make good interviewers.
I had a recruiter obtain approval to have my technical review ignored because I pointed out so many flaws in it. At that point I had too much of a distaste for the process to continue.
But I kept being approached by Google recruiters, kept recounting what had happened last time and asked if I could expect better this time. None could promise things had improved, and a few did express that kind of frustration.
This was years ago now. Could have changed of course. But I started telling them to go away.
I was getting HR hits like every six months and eventually I told them I would get back in touch when I was ready.
Now I'm getting an email every month from FB, and about ready to do the same with them.
The last time I passed the first and second rounds and Google let me languish on the third round for a month. I still probably would not have made it through, but it was surprising that my candidacy was dropped like that.
It says something about their HR systems that it's clear they don't review past interactions before doing this. To me that's a warning sign too - I'm less likely to consider interviewing if a company contacts me again and the interaction doesn't start with a pitch of how this time or this position is a better fit...
The problem is that many out there try to copy the dysfunctional FAANG interview style. Google was asking those dumb brain-teaser questions for years, which were obviously useless to the naked eye, and then they realized themselves that those were counter-productive.
Yet, you could expect one of those in almost any interview process. Seemingly smart people are ready to jump on bandwagons, too.
Google was asking those dumb brain-teaser questions for years
Microsoft started doing this, realized it was a bad idea, and stopped before Google even really started this practice. So Google is as guilty of bandwagon jumping as everybody else here.
I find it… troubling? That a technical interviewer can’t tell for herself whether your code will work. Wouldn’t you ideally want people who actually understand code to be giving the coding questions?
Are you saying that because this interviewer needs to run code to find logic errors, she's somehow not a competent engineer? Because I usually need to run code to find logic errors. Sometimes I use formal verification instead but that's pretty rare. Am I also not a competent engineer?
He's saying that in order to judge someone's ability at something, you need to understand that thing yourself. If you require the candidate to write perfect code using nothing but a whiteboard, you need to be able to read that code using nothing but a whiteboard as well.
If the interviewer cannot do this, how is he going to judge the result? Does he know how to run a compiler? Does he know how to run the code? Does he have the skill to judge the output? Is it really a good policy for a company to discard a possibly excellent candidate that just missed something silly that would normally be checked by a tool while you type?
If you can't tell the difference between sketched-out kinda sorta pseudocode and potentially workable C++ then you're certainly not competent in C++.
And if you fail to communicate the requirement for one or the other then you're certainly not a competent interviewer.
You also have to ask what exactly is being tested here? Is it the ability to remember syntax? To remember an algorithm? To improvise an algorithm? To recognise which algorithm is needed?
In my view, if the answer involves a topological sort the interviewer should know how to solve it and be able to follow and find errors in the candidates code. If the interviewer, knowing the answer, cannot find any issues then surely the code is fine (for code written in an interview)
It's also possible that she hadn't seen the particular algorithm used before, or that she was having an off day or stressing about a meeting immediately after the interview, or that there were errors that she did see and she didn't want to say "yeah there are errors here" because doing so could affect the candidate's confidence in the interviews after hers. I could imagine any of these being true. Or she could just be a bad interviewer.
That is irrelevant. Asking someone to type non trivial code outside of IDE and then expecting it to compile and run without issues is lunacy. Even junior programmers know this. The interviewer in this story was either an amateur, an idiot or on power trip.
I guess I'm also an idiot then, thanks, how kind of you to say that.
Actually hang on, I'm editing this to be slightly meaner. Your whole take that doing this is a sign that she's either an idiot or on a power trip is a very familiar thing that people say about women in tech and I'm honestly tired of it, because I can see myself doing exactly what she did and I don't like it when people say those things about me. Please don't do that.
You just can't tell someone to type code into google docs and expect it to just work and worst off all judge a persons skill on this basis. It takes minimal experience of programming to learn this. Hence all the jokes that people are surprised/suspicious when their code runs after first compile.
If you disagree with this you could have provided any sort of counterargument. Instead you took this weird "women in tech" angle. Wrong is wrong, interview here was wrong, gender did not play a role.
If you can't assess someone on their response then you're not interviewing them, you're just giving an exam by proxy. But that might very well be because the whole recruitment process is thoroughly stupid.
So, we can have an interviewer perform a possibly incorrect manual validation of an interviewee's possibly faulty code. Reading code is harder than writing it, and presumably the applicant has been asked to do something tricky.
Or they can run it, asking the real arbiter of truth whether it works or not.
Of course, "whether it works" is merely one (very important) metric of quality.
The interview is a proxy for working with the person. In this case, it's a proxy for pair programming / code review. A good chunk of what the interviewer, ideally, looks for when asking a coding question is communication from the interviewee - can the interviewee communicate what they are doing and why? Can they explain the intent of the thing they've just written? Do they have a clear picture of it in their head, and can they communicate it? When the interviewer spots problems with it, what does the ensuing discussion look like? - how well does the interviewee collaborate in solving them? If the interviewer is wrong, does the interviewee push back? How? Can they understand you, and can they make themselves understood?
Can you work with this person? Can you collaborate to write code, or will it be a daily struggle?
Whether the code actually builds and runs after the hour is up does not help answer these questions; it is arguably the least interesting part of the whole process. The time limit is artificial; if all the other things align but you didn't happen to get it working in one hour, you'll likely have got it in two. If they don't align, you'd likely never have got it.
Every recruiter says the same thing, but in practice the interviewer is only looking for the right answer, and that is what determines the outcome of the interview. I've never seen anyone helped out by soft skills while still having an incomplete solution.
The problem is it won't run. It was written in google docs without IDE. Everyone who programmed in their lives knows this. You cannot write out a whole algorithm like that and not make any even trivial error.
This is like writing code in notepad and creating a PR without building or running it to test once. What is this testing? There is no real world scenario where you are expected to work like this and for a good reason.
Yeah. If I were asking a trickier question and I got an interesting new variant of the solutions I'm aware of, I'd absolutely run it if I had time to type it up and everything. Most solutions are either something I've seen before verbatim or obviously wrong, though.
I think it depends on who gets to choose the programming language.
If you're interviewing for specific language skills, then what you say is clearly true.
If it's a general coding skills interview, I invite the candidate to code in whatever language they like. More often than not they choose a language I am sufficiently fluent in to follow along. In rare cases I need to ask them to explain a thing or two. In very rare (but generally quite fun) cases they choose a language I am totally unfamiliar with; this tends to lead to interesting discussions.
In all of those cases the full coding transcript is captured and, if necessary, can later be additionally reviewed by/with someone who knows the language well.
P.S. Also, their thought process and approach to problem solving is just as important as the code, and is largely independent of the choice of programming language.
Funny and illuminating examples of this are the excellent "hexing the technical interview" series (read in any order): https://aphyr.com/tags/interviews
Standard disclaimer: everything below is my own opinion based on my personal experience, and I'm not speaking on behalf of my employer.
> I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind.
I've been interviewing at Google for nine years and have never done this. I generally don't think it's fair to ding a candidate for something I don't notice in an interview, where I'm at a huge advantage. If it looks right to me then that's good enough.
But that said, I have often asked questions similar to what you describe. You have to write code in the shared doc because hiring committees want to see it - fair to blame the process for that, but not the interviewer. I actually appreciate this for a couple reasons:
* It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes on how a conversation went (especially for people who aren't native English speakers)
* I sometimes find that candidates who communicate well struggle to turn their ideas info code. Other times, someone's communication and solution are kind of average, but then they use all the little things I like seeing (defaultdict(set), zip, etc. in Python). Lots of people claim to be very experienced programmers; seeing how comfortable and fluent someone is when actually writing code is a strong signal. If you don't like the focus on data structures and algorithms that you haven't thought about since college, you should probably appreciate the coding part.
On one hand, I can appreciate that it's unpleasant to be put on the spot. Or being forced to use crappy tools. Nobody likes that.
That said, if a person is being considered for a coding job, wouldn't that person want to demonstrate their coding abilities? I mean, assuming they're actually good at coding?
In interviews, I much prefer a concrete problem to an abstract one, and coding problems are typically far more concrete than most other subjects covered in SW dev interviews.
Google Doc is specifically designed for writing and reading and used probably by more people than any other piece of software ever for that task. And you think it's fair to compare it to crayon and napkins? What a world we live in. Programming is often about thinking through the problem, but if you can't separate yourself form your IDE when writing code and it's about syntax then that says more about your style.
While I don't necessarily disagree with the sentiment, I can provide a real life take. Not specific to GDocs, this applies to all browser based editors.
You may usually write code in a terminal based programmer's editor (vim, emacs, ...) and realise the code you've just written is not quite right. You want to delete the last two words. There's even a default and handy keybinding for doing that.
I consider google doc coding an extension of the white board coding, which often happens in pair programming. I do not think it should aim perfectly working code, but at least I would personally expect reasonably good whiteboard coding hygiene from a colleague, at least for a report to the committee.
> It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes
Except that writing code in a Google doc on the phone doesn't in any way resemble the real "playing field". I grant that it's level in that everyone faces the same constraints, but to write code in a gdoc with red squiggly lines underneath every keyword, automatic capitalization after a dot, and variable width font? How does that give you any kind of useful assessment? It's like handing a butter knife and some twine to a doctor and saying "here, show me how you'd stitch up this wound".
Google interview process is designed around how badly you want to work there not what are your skills i.e practising solving bunch of leetcode puzzles on whiteboard and speaking out loud is all it takes to get through the interview process. It just takes some time to prepare.
I think that is basically it. I think many of these FAANG companies interviews are more of a hazing than an actual assessment. Everybody who works there had to go through that interview… if you want to be part of the pack, you too must endure it.
When viewed in that light it actually doesn’t seem quite as bad.
I worked at Google and did a fair share of interviews. Two observations:
When you have 3 interviews per week for a prolonged period, you, as an interviewer, are not going to do a stellar job every time. What's worse: you will develop a routine and it becomes very easy to give candidates that do not fit your routine a lower grade. It takes effort on the interviewers part to recognize talent that perhaps doesn't fit your routine or your expectations. If you are not going to end up being a bad interviewer you also have to try to relate what you see in interviews to what you know about work.
For instance I _never_ asked people to code live (mostly on whiteboards back then) because it just isn't a relevant exercise. And I was kind of horrified at experienced interviewers who asked people to code and then got obsessive about small details that the tooling would have taken care of. Absolutely pointless.
The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared.
The other thing that horrified me was when we let inexperienced people who had been out of school for less than a year interview people. These interviewers barely knew how to write software themselves, and they'd get even more hung up on irrelevant stuff because they simply had no idea how to be software engineers.
I doubt that I would have done very well in those kinds of interviews because this isn't how I work and it certainly isn't how I teach people to do problem solving. Problem solving requires more time because any even mildly tricky problem worth solving tends to have a lot of facets far beyond picking an algorithm or knowing how to code it up. That's the easy part because for that part, you have books, papers, tools and other people to seek advice from.
Junior programmers right out of school with no engineering experience have no business interviewing developers. They make poor and overly judgemental interviewers and only rarely are able to spot talent if it doesn't fit their template. They also aren't going to fight for candidates that may not fit the imaginary template, but have some special gift because they are junior programmers. It takes a certain amount of balls to say "I know you think this candidate is rubbish, but I see something here and I don't care what you say, I am going to insist".
(btw, statistically, this used to be a good predictor for later success: candidates that were somehow "controversial" in that they didn't make the grade with some interviewers, but displayed something that made other interviewers fight for them)
> The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared.
Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that's not the only point of the interview. An important goal there is to check if you can really code. We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position), and in fact it's a desirable property if you don't, because that allows us to see your thinking process. Some of the best interviewees I've had, they didn't have the right solution, but impressed me with how they thought about the problem and dealt with the situation of having a problem in front of them that they didn't know how to solve. How they considered possible boundary conditions and restrictions and extensions. Someone saying "yeah, this is just depth-first-search" and then spits up a memorized solution gives me zero insights on whether the candidate is good (and will likely not allow me to write great feedback on the candidate, unless they're able to sell me that they understand what they are doing and why and how). It's usually expected that most of the interview will be taken up by you implementing some algorithm, and it's expected that you won't get every detail right.
We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.
With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.
There’s enough counter anecdotes here on HN when this topic comes up that the wording of your post comes off as tone deaf. You actually seem to believe every interviewer at Google behaves like you, for the same reasons, to the same standards.
“We do NOT”
“You messed up”
“let me be very clear”
“whether you’re able to code”
These types of statements come off as patronizing. If your whole process sounded like this, and if you somehow actually do represent a majority of Google interviewers, then it’s no wonder so many folks have a distaste for the experience.
I tried conveying what I was told when I was trained for conducting interviews, what I've explicitly seen demanded on the interview forms I have to fill out and what I get as feedback from hiring committees. Thus I indeed assume that my opinion represents the majority of interviewers. Whether that assumption is warranted or not, I wouldn't know.
Well, in real life this varies. I've seen interviewers from among the first 200 Google employees, nitpick their way through someone's whiteboard code, obsessing over every comma and semicolon. It was embarrassing. And I have to say that while shadowing these interviews I couldn't help but think "I've seen your code - you have bigger problems than getting the syntax perfect, mate" (about the interviewer).
It depends on who you get as your interviewers, so generalizing isn't really useful. Some interviewers can't relate the interview to what it is supposed to tell you. I've seen that in inexperienced interviewers and I've seen that in very experienced interviewers who had enough GOOG stock to buy a small country.
If the interviewer can't think of a better way to test candidates, that's on the interviewer. Not the candidate.
> So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.
How much money can you bet that this never or does not happen? If you can't put your money, I find it difficult to take this seriously.
> We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)
This statement "we don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)" made me chuckle.
I can see this interviewer writing feedback like "Well, this candidate didn't come up with a perfect implementation of Dijkstra's shortest path algorithm, but its OK, they were pretty close. Oh wait, they are a senior engineer? Nevermind... they should have really mastered these algorithms while building CRUD APIs all these years."
This is all ridiculous. Of course you have to test that people can code, but it doesn't follow that people must be able to code without any references available, or without using standard libraries. I can code just fine, but I still have to look up the arguments to functions I don't use very often, etc.
As far as algorithms/data structures, most of what we do on a day-to-day basis is more about selecting the appropriate data structures and algorithms that fit the problem, and assembling them together correctly. I've never needed to code a hashtable, but I need to think about their characteristics and whether they're appropriate all the time. I've never written a btree, but I do understand database indices pretty well. So in my view, asking candidates to code up these things on the fly in an interview with no reference materials is a total waste of time. What matters more is if they can correctly apply them. If you're really sure someone needs to write these things, then a more realistic move would be to sit them down with a standard textbook or paper and see if they can get the code working.
> After all, we expect you to be able to write production-level code that servers billions of users.
And you do all this through sheer clairvoyance, rather than using tools like unit tests, code review, design specs, etc, right? No? Then why are you expecting people in interviews to do it without those things.
How does Google interview for product development skill? That’s seriously lacking in that organization, definitely the worst of the FANGs.
The arrogance displayed in your comment isn’t backed up by the ultra-low quality of product being produced by Google. Something is clearly wrong with the culture and hiring process there. Maybe instead of fretting over people using strlen as an exit condition, you should look for people who can actually produce software people enjoy using. You don’t even need to do a coding interview! Just browse GitHub for people you want to hire and get to work convincing them to join you.
A friend encountered this with Amazon, although their tool at least has some code help (at least when I tried a year ago). The interviewer tried to compile his code.
I hate this. People have IDEs and internet when working. Having to write something that can be compiled in a doc is just stupid.
As someone mentioned in another comment, I also never had to actually implement a sort since I left university more than a decade ago. I'm happy to discuss the different types and approaches to how they could be done - as to evaluate problem solving, logic, and general understanding - but to actually code in an interview...
In a similar way, this week I even jokes on Twitter how I'm doing many improvements and refactors on a codebase, but there's the occasional 'how I do join 2 lists on Java again?' moment when I completely forget something basic.
i failed quicksort the first time I interviewed at google. then got hired and worked there for 12 years and never wrote a sort.
I also complained that google's coding solution (docs, basically) was a terrible way to code, other companies use coderpad or whatever, but I expect that Google will never change this. They love to hire people who are excellent at coding CS approximate solutions, but have little to no judgement on how to do good software engineering.
That does happen more often than you think. The hiring manager wants to hire a friend, tells HR he needs to hire a good programmer in mind (but doesn’t disclose it’s his friend). HR tend posts job postings for legal reasons knowing full well none of the candidates will be hire. They then reject a few candidates and then brings the friend saying they couldn’t find someone more qualified.
1. You should have been better informed about the expectations of the interview, so you would have had a chance to prepare yourself.
2. Coding in a Google Doc is a terrible experience. It's a step up from coding on a whiteboard, but that's not saying much. Google has since moved away from both, prefering an online text editor that's not quite an IDE but at least more programmer-friendly.
3. The goal shouldn't be to write 100% correct code without any compiler feedback. That's insane. Still, there is a big difference between "candidate forgot a semicolon once" and "candidate did not know how to write a for-loop without IDE feedback".
But beyond those valid complaints, it sounds like you were also unhappy that you were asked to write any code at all. I don't think that's reasonable. The point of a phone interview for an entry-level SWE is to determine two things:
1. Can they figure out how to solve a nontrivial problem?
2. Are they able to translate ideas into reasonable, working code?
For an algorithm question that boils down to a topological sort, the interviewer will see three kinds of candidates:
1. Those that don't have a clue how to solve it.
2. Those that recognize it boils down to a topological sort.
3. Those that recognize it boils down to a topological sort and are able to implement a solution.
Each of these candidates is strictly better than the last, and Google only wants to hire the third one.
> I didn't remember the exact algorithm so I basically had to re-figure it out on the fly
Yes! That was the whole point of the question! You had already demonstrated that you were at least a "type 2" candidate, so now the interviewer was trying to move beyond that and figure out if you were actually a "type 3" candidate. Nobody expected you to have the exact solution memorized, but they expected you to be able to figure it out from first principles.
> I even similarly mention "in any real situation I would just look this up", but that didn't help
That was missing the point, which was to test your ability to actually implement a solution.
In the real world, if you encounter a standard problem (which happens often, like "I need this list sorted" or "I want to put this stuff in a hash table for O(1) access") you wouldn't even look up how to solve it. You would just call the existing standard library function and move on.
Logically, the problems that you end up spending most of your time on are not of the standard variety, and involve actually thinking about how to break down the problem and actually implementing your intended solution. Those are the problems Google needs you to solve on the job. If you can't even implement a topological sort from scratch, why should anyone expect you to do anything more complicated than that?
My experience with Google (in the UK) was an interviewer who asked a very similar question, among a number where he was clearly unprepared to deal with answers that weren't 100% as expected, and asked questions that had basically no relevance to the role.
The experience was so bad that afterward I sent a lengthy email to the recruiter thanking her but pointing out I expected to fail the interview because the interviewer insisted on things that were wrong or irrelevant and set out why as a courtesy so they could address it for the future.
I was rung up and was told the recruiter had gotten the interview set aside, and offered to just have me bypass the technical interview and wanted to move on to an interview with the hiring manager.
In the end I declined, as the first interviewer would have been one of the people I'd have managed, and I just did not want to deal with a team with a person like that, and the whole process was just excruciatingly slow to the point I had offers on the table before they could line up an interview.
It seemed to be a process optimised for people who either desperately want to work specifically at Google, or doesn't have alternatives.
I kept getting calls from Google recruiters for years after that and kept recounting my past experience and asking if they could provide a better experience this time around.
I have had worse interview experiences than Google, including one where I halted a phone interview halfway through and told them they'd shown me I didn't want to work there, but Google is pretty high on my list of places I'm not particularly interested in interviewing.
> In the end I declined, as the first interviewer would have been one of the people I'd have managed, and I just did not want to deal with a team with a person like that,
Oh, I can totally empathise with you because I've been there. I applied for a position which was the head of a team and a future direct asked me esoteric statistical questions from his PhD thesis. I did quite well to answer most of them but he wasn't impressed.
Weird. When I was casting for actors instead of trying to "trick them into doing something bad" and throwing them out, I tried my best to get it to work with them, even if it meant I had to do something different.
A casting is always stressful, they don't need me as an enemy as well. If they are not good enough with a ton of help, they won't be good enough period. If they are really good with a little of help, they can still be better than someone who needs no help at all. In the end I care about the final result, not about whether they grade well on some invisible scale that only I can see.
This. Help the person you're interviewing. You'll both get more out of it, you'll both enjoy it. If you're in a company that is expanding, you'll be interviewing a lot, so it's really important that it doesn't depress the shit out of you.
So factor that into your judgement. If you needed to help them constantly, you still know they're a bad candidate. Nothing is gained by stonewalling them other than potentially getting someone who's going to badmouth you to everyone.
I've definitely had interviews with solid candidates who just faced an early roadblock, but were brilliant after I gave them an early push. Sometimes that's more of a sign of communicating a question poorly or nerves than genuine lack of knowledge on the candidates part.
This, so much. Interviews are very stressful for candidates, everyone should remember what it's like sitting on the other side.
I've been doing a bit of technical interviewing and I usually try to help people along so they reach the "end" of the interview, especially if they're not doing too well. So many candidates sound defeated when they're struggling with a task and it's a form of respect for me. They've put themselves out there, after all.
Treating candidates - which you know you are going to reject at some point of the interview - with dignity is the right thing to do and can go a long way when it comes to your company's reputation.
That is the hard part of the job. You need to be able to take yourself out of the equation. If you can't do that, you are simply the wrong person for the job.
Usually it is not hard to notice whether you'd like someone to succeed and then factor that in.
Same thing. One of our main actors was once a guy I didn't like at all. But he was fantastic for the role and it turned out to be a good decision afterwards (despite him being complicated to handle, which we also factored in).
Maybe the hard part is to get a HR person that cares about the outcome instead of their authority.
What happens in the real world when a colleague has a mental block? They Google it. If that doesn't help, they slack the team: "Hey guys, this is something stupid-simple that I can't bring to mind right now, but... <question>".
Why should their interview be a stressful stone-walling event when life as an employee is not?
Maybe an interview should have "Who wants to be a millionaire" lifelines. Two "Googgle"s, and an "ok, I give up - give me a hint".
I agree with the spirit of what you are saying, and in light of the role unconscious biases plays in hiring, I'm challenging my own beliefs on how to run an interview.
How does an interviewer ensure all candidates are offered help fairly and equally?
What is the purpose of asking a question, that if a solution is found after "hints" are offered, would be acceptable for hiring?
If the question you are answering has a "right" answer you are asking the wrong question. E.g. if you search for a web dev, give them a problem and some constraints (e.g. language), ask them to draft a quick solution.
When they are unsure then they will usually ask about the problem or about how the problem should be solved (microservice, shell script, ...)
These are valid questions and you can turn them into more knowledge about the candidate by asking them what pros/cons they see by going each route.
Just like that I have actors that want to know more about the role and actors that need less guidance. In the end their performance counts. I will still try to give them hints inbetween takes (just like I would when we work together on the set) — but in the end it is their work which I will judge.
Unless you are hiring for a position where a dev works in complete isolation and receives no guidance whatsoever I think emulating the real thing is the way to go. And that usually doesn't entail holding a devs hand and neither it does entail not helping them at all.
Same-ish. I got through several phone interviews and was asked on-site for a full day of interviews, back to back, with a lunch break in the middle. The HR girl was honestly running around like the mad hatter, apologising for being late and then running away as soon as she had left me in the general area where my interviewer would be. Some of the interviewers left me with the next, others just wandered off, leaving me in a room. One of the interviewers was in a different office so we talked over video conference. I say "we talked" but he was reclining so far back in a chair that he might as well have been in bed, and he read questions from a sheet without once looking at the camera. After that I did actually get a decent interview from someone who was on the team I interviewed for. During the lunch break someone had to take me for lunch, and from the moment she showed up I gathered that, like perpetual interviewering, bringing ten-percenters for lunch was another boring part of the job. I also got a really bad 'vibe' just walking through the building. Lots of fun-looking-stuff like games and beer fridges, but everywhere, people with headsets on staring into screens, never once looking up to see who is in their vicinity. Anyone ever seen Coraline? The people with buttons for eyes...
After that whole depressing charade was over, I figured it would be an offer or GTFO. Nope, I got called for another interview. I said "eh, no thanks".
Years ago, while applying to some security engineer position at Google, they were testing low-level skills focusing on vulnerability research, C/C++ and x86. At that point having spent 10+ intense years on that arch: having written binary translators for it, reversing/exploiting software and writing a micro-kernel. After rejection, they recommended me to read a "x86 assembly 101" book which was truly infuriating at that point.
Granted, it was an automated email, but an automated "No" would have been more appropriate. Is it so hard to offer different standard responses? Why does the company consistently fail at human interaction, be it candidates or customers?
From my circles, most share the feeling that FAANG/MSFT are insulting for candidates (I can only speak for Google/Microsoft).
Because they have a money printing machine called AdWords which affords them the opportunity to be terrible at anything and everything else without any impetus to recognize it or need to care.
Yeah I was asked to complete a pretty challenging question in 25 minutes (eventually solved it after the interview ended in 2 hours) and after it was clear the interview wasn't going anywhere, asked for tips. They said "study data structures and algorithms"
Like... yeah thanks I guess this degree and 5+ years experience isn't worth much. Such a broken process
It's so stupid, all of it. They try to come up with random questions that doesn't mean anything if the candidate remembers the answer at that point in time.
I've read about Linux inodes. I know what they do. In fact I even have had Linux systems where I get inode related error messages because the partition had too many small files on it.
But given that question, in that situation, I would likely not know what they even meant with that question. Am i supposed to have all the inode details memoried forever in my mind? It's fucking ridiculous.
I’ve written a few Linux file systems and I’m not even sure I’d have answered that question correctly.
I’ve also failed job interviews where I was told there was no coding expected in the face to face and then got given a piece of paper and asked to solve 3 theoretical problems in SQL on paper while 3 interviewers watched. 10 years prior I’d worked for several years on Oracle middleware so I knew SQL inside and and out but I still lost my nerve at that interview and was told I wasn’t experienced enough.
There was another telephone interview where I was asked all sorts of command line questions, the problem there is they spelt out the command line flags differently to how I normally talk and read then (eg “what’s see hatech em ohh Dee seven hundred and seventy seven”, had i seen it written down I’d have been like “oh you mean see hatech mod seven seven seven” (chmod 777) but they way they read it out sounded cryptic has hell.
So there’s a valuable lesson I’ve learned for interviewing: putting pressure on interviewees is just as likely to filter out good candidates as it is bad ones. So you’re better off making them comfortable during the process. Good but nervous candidates will perform better. The interviewing process shouldn’t be about who can hold their nerve the longest.
There are moments in life when I wish everyone was forced to learn NATO phonetic alphabet early in school.
"Charlie Hotel Mike Oscar Delta Seven Seven Seven".
The reason to cram into people a standard spelling alphabet is that it minimizes confusion over the usual "see as in $random-first-name". The reason to standardize on the NATO one is that it's already an international standard, and a subset of the population that goes to work with anything resembling a radio transceiver will have to learn it anyway.
It wouldn’t have helped in the interview if they did use the NATO phonetic alphabet because when you read CLI commands or talk about them in the office, you don’t spell it out using the NATO alphabet.
The point was the interviewer read a written command differently to how I’d typically hear it. It’s a little like the S-Q-L vs Sequal debate and how that can sometimes throw people.
In terms of topical content it's a good question. The idea that the name is a link stored in a directory entry is a key part of filesystem architecture and anyone familiar with unix filesystems should be able to immediately talk about why.
The problem here is that what could be an invitation to showcase knowledge is reduced to a vague, one-dimensional and non-obvious trivia question. There are a ton of valid answers to this question, like:
* The file data
* Extended attributes (ACLs, etc)
The topic is fine, but the framing of the question is terrible.
If I wanted to test a candidate's knowledge in this area I would probably ask: "Why isn't the filename stored in the inode?" -- this initiates an architectural discussion, rather than a poorly designed guessing game.
Guessing games in general are a red flag for the employer. They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.
If your question has that "gotcha there is just one right answer"-feel to it, you are doing it wrong.
I had a teacher once who constantly asked questions like these in such an imprecise fashion there was no way anybody could have guessed how the question was even meant to be answered. I still cringe when I think about it, because the only purpose of these questions was to show us that he is really clever and we don't know shit — and it didn't work at all.
Personally, I have always approached interviews as an opportunity to either teach or learn. I pick a subject and drill down until either the interviewee reaches their limit of knowledge, or I do. Why is it like that? How does that work?
Then, we have a discussion. One (or both) of us is learning and we work out the whys and hows together. If I'm the one learning, and I hope that I am, I fact check the discussion after the interview. If not, I get a strong indicator not just for the technical level of the candidate but also how they operate at the edge of their comfort zone. I've found this can be a strong predictor of future growth.
> They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.
Ding ding ding.
Even the question, as asked, was OK. The interaction with the interviewee wasn't.
OP's joke was clearly just asking the interviewer to be more specific. Instead of exploring the question with the interviewee (e.g. "well, can you think of something that one might naively assume to be in the inode, but that is not"), they get pissed? lolwat?
Yes and that's true of ACLs as well which I think underscores my point: Questions should be an opener to dialogue. A topic, not a conclusion.
Discussion of these whys and hows and whens is the most valuable part of an interview and will more accurately illustrate depth and breadth than any number of fixed questions.
I have been headhunted by them multiple times in the past. The last time their recruiter called me and explained me that after the usual screening and HR calls I would need to pass multiple increasingly complex technical interview rounds - and then THEY will decide on the role and project I am best suited for (if at all). I have flatly asked the guy whether they are being serious and turned him down.
To be fair to Google, though - their interviewing used to be first class. When I got into the first call sometime in the early 2000 or so, the interviews were difficult but with competent interviewers and no BS scripted questions. But that was because it was done in-house, I was talking directly to some engineer in Palo Alto over the phone. Even the HR lady was actually pretty technical and was asking me rather pointed questions.
Later on they outsourced it to HR agencies and it became "the process", with people being called over irrelevant/not interesting jobs (entry level sysadmin in Ireland once - even the HR guy on the phone recognized it makes no sense to call me over it ...) and the "we decide ..." at last.
However, Google is by far not the only company doing it. Microsoft's hiring process was very similar and Google's explicitly inspired many smaller companies or "less desirable" (for the candidates at the time) companies to ape this, thinking it is somehow a good idea.
This seems to be pretty much the norm in the tech industry. Along with attempts to effectively have the candidate redo all comp-sci final exams during the interviews - because "credentials can't be trusted", as someone told me.
Give me a break. It is high time tech companies should start treat (especially experienced) engineers with a bit of respect and dignity, we are not school kids anymore.
> even the HR guy on the phone recognized it makes no sense to call me over it ...
Well, he had a quota to fill so ¯\_(ツ)_/¯.
There are situations where the market can be spectacularly efficient. Outsourcing hiring to third parties is definitely not one of them.
In this case, big companies can afford broken interview process, because it's not their time that's being wasted, and the inertia of a big corporation can hide a lot of inefficiency.
facebook had me as someone who could fill their quota for 1st rounds etc I sent an email asking them not to do this twice now. It is quite funny though, because every time I bring up NYC being the only possible location for me, the recruiter usually grumbles says its "tough to get into NYC" and then usually I get that the engineering manager "doesn't like that many people" I wonder how many people have been rejected working for Facebook because one person in NY doesn't like them? I mean that person might be amazing, but still seems limiting. They do fine anyway though, most of the hard parts have already been done long ago at Facebook I would suppose.....
As much as I dislike interviewing I totally agree with this statement. Almost none of my graduating classmates could write a fizz buzz and I wish I were kidding.
But think of how smart he felt after telling you the answer! That confidence boost alone was probably worth their time to interview you, mission accomplished.
Oh don't worry it wasn't just one question but the whole interview. One I remember was how would I explain [insert random algorithm] to a board of decision makers, I made it sound like I was explaining a 100 year old how to turn on a computer.
I had no interest in ever "explaining" stuff to non-technical people at that time, all I cared about was the code. So I also trolled one of the guys interviewing me since I happened to be stuck with his legacy "code", which made me judge him and take him with absolutely no seriousness: he was one of those "cfa" people who learnt how to "code" a line of VBA and think they're Linus.
I also remember the face of the HR person who was like wtf the whole time and politely told me they had "chosen" another person for the job, I laughed inside and politely answered that I understood.
I recommend against this behaviour to past me anyways ;)
We all have to feel our oats at some point … and then realize later how childish it was / how poorly we treated others … so we can be forgiving of those who come after us …
IMO asking gotcha questions like that to make yourself feel smart is just cringeworthy and silly.
Your goal when interviewing people should be to find things out about them — with gotcha questions you don't find out anything about them, but they find out something negative about you.
It is also scripted. Google used to use internal people do to the screening but not anymore, they have outsourced it to agencies. And a random recruiting agency drone on the phone, paid minimal wage, can't be expected to ask sensible questions, so they get a script to choose questions from, along with expected answers.
I doubt Google has outsourced their entire process.
But many recruiters work as independent contractors or in recruiting firms. They often do a minimal phone-screen, vs sending a candidate "cold" to the hiring company.
Nope, the inode question is part of the 50-ish long trivia quiz that a sourcer uses to figure out if a candidate is worth putting on the phone with an engineer.
The inode question is tricky. It is certainly not something an employer should take for granted you have memorized. But the answer can be reached by reasoning, at least if you know something about filesystems and the concept of hard links. Which you probably do if you have read the "ln" man page.
It is still a pretty poor question, I remember getting a similar kind of question when I passed through the (at the time, in Sweden) mandatory conscription testing, where you are tested for which role you best fit as a military conscript.
One question on the intelligence test was: "What is heaviest, gasoline or water?". I did not know how to approach the question, I had not memorized the density of gasoline and I didn't think an intelligence test could have assumed that either. I was stumped. How could that be an intelligence test question? Only afterwards did I realize that the test creators probably assumed that knowing that gasoline floats on water as common knowledge, and if you were intelligent enough you should be able to derive the answer from that. I think the inode question is similar.
It depends on the amount. Two pounds of gasoline are heavier than one pound of water.
Yes, I get that they are asking about density, not mass. My point is that tests need to be carefully written. I remember once during an early online screening at a multinational they asked something like
Alice went shopping in the morning and bought apples. What did she buy?
A) Apples.
B) Oranges.
C) All of the above.
D) None of the above.
With the information provided, the only answer we can reject is D, because we know that she did in fact but apples. However, it is possible that she also bought oranges (and/or something else), in which case answers B and C would also be correct. We don't have enough information.
Bear in mind this was a test for recently graduated software engineers, who are supposed to be trained in logic, so I spent a few seconds puzzled wondering why the question was worded so strangely.
Well, maybe it'd be better called "aptitude test": if you don't know that gasoline lighter than water that means you've never handled it manually, so better not put you into an automechanic position.
It was 2 days of various tests, resulting in a number of scores, physical, intelligence, psycological etc. All together an aptitude test. I don't know why this was called intelligence test, it was a mix of questions, not all of these kind. I remember many were something like "circle the fourth word of the second sentence except if..."
Almost everybody with some Linux experience knows that the file name is not stored on the inode. It's not this part that makes the question bad.
What makes the question bad is that nobody can guess what answer he wants, and anything else, as correct as it may be, will be understood as a mistake (what is evident by the OP's answers that were perfectly correct).
"What number am I thinking right now" may be a really strict question that fails your expected number of people, but it's not a good interview question.
My first linux install was Redhat 5.2 bought at a bookstore in ~1997. I have not always been a primary linux user, but I have been using it in some capacity for over 20 years now- though as a means to an end primarily- in the bad old days I mucked around with drivers and X configs and have even recompiled a custom kernel on occasion. Never once has it come up that the filename is not stored in the inode.
I am actually just curious as to why this would ever even be a thing you come across unless dealing with filesystems directly?
You'd never need to know anything about it as a user. I don't know how anyone could seriously make the argument otherwise.
In fact the only reason I know anything about inode and dentry specifics is because they are 'very clever' interviewer favorites! I've been a professional UNIX admin for 15 years and I've dealt with inode issues literally once in my life lol
Thanks. Its comments like the GPs that makes me wonder how I have avoided learning some very commonplace issue and its these types of comments that foment imposter syndrome.
I have even read books on linux architecture and remember discussions about filesystems and inodes and remember the general structure and form, but a detail around what is and what is not stored in the actual inode... seems like an absurd detail to memorize.
The only way I could see this being commonplace is if I somehow missed out on a widespread bug that somehow caused inodes to be corrupted and requiring manual intervention/surgery to prevent data loss.
Probably the most common case where this comes up is in the context of hard links: two (or more) files with different names that point to the same inode. I guess actual usage of hard links is rare enough that it doesn't come up all that often, but I'm actually surprised you didn't know this – not judging you, just something I thought most more experienced Linux/Unix users knew, but it seems not.
Hard links can be a somewhat notorious footgun due to this by the way; with a soft link you know you're only deleting a link, but with "rm hard-link" this is a bit trickier: if you think there's another link but actually, it turns out you made an error and there's not then you've lost that file. A "hard link" isn't really a thing on its own: it's just another reference to an inode. This is why symbolic links are used in most cases, but you can hard links are still used from time to time in e.g. /bin and some other places.
Google is infamous for jerking people around in the interview process. I had a very similar experience, as did several people I know.
They do it because they know they can get away with it, but I do wonder if they have a backup plan if the lustre of working for Google ever fades, because it's an open secret that their interview process is a fucking nightmare for no reason.
Absolutely! To add, the amount of nit-picking that happens is staggering. I was downgraded from strong-hire to lean-hire because:
1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes"
2. I did not use one of python's standard lib functions and instead I coded it myself (I could not remember it at that instant)
3. I could not spot a scenario in the first 5-7 min of interview. I eventually spotted it and coded it well within the time limit.
Somehow I felt that I am supposed to feel grateful for lean-hire
> 1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes"
Apparently they missed this classic HN discussion:
> I could not spot a scenario in the first 5-7 min of interview.
This is endemic and part of a much wider malignancy in the tech interviews. Cram two medium-to-high difficulty questions in the span of 45 minutes and require the candidates to solve them both on the spot. In other words, you have at most 20 minutes to work out a complete solution to any given problem.
In practice that means that you need to come up with the correct base solution in the first 2-3 minutes, because there is no time to actually work through the problem.
I call these types of interviews Epiphany Lottery.
When people say "grind leetcode" they don't mean it as a tool to get better at these kinds of problem solving. What they basically mean is that if you "grind leetcode" you have a better chance of being asked a question in these interviews that you have solved before and simply write down the solution during the interview.
If they're IQ tests, then why does doing a whole bunch of leetcode questions make me better at it? Isn't IQ supposed to be relatively stable throughout one's lifetime?
I've done hundreds and I have gotten better, but only to a point. At some level it's not pattern recognition anymore, just inspiration. And I'm not smart enough for that.
This one, for instance is expected to be completed in 30 minutes. I spent 2 hours on it yesterday and failed most test cases. I'm a failure.
Do thousands then and get back to me. It's all patterns, this "inspiration", is just patterns, your just not seeing it yet.
Its true on some degree, that you need some intelligence, but I have a few close friends who are FAANG, they are definitely not the best developers I've ever worked with, only difference is they really really cared about getting into FAANG. Getting into FAANG was basically their life ambitions, so they dedicated literally all there spare time to it.
I dedicated a lot of my spare time to it in college (and after) too. What did I get for it? I make just $200k a year at the least impressive FAANG and literally everyone considers me to be a mental defective.
> The feedback I got was "candidate does not know idiomatic use of modules & classes"
Many googlers probably haven't read this blog-post from some time ago [1]: "Python Is Not Java". I mentioned that at my first interview for a Python programmer job ~15 years ago, i got hired (truth be told the interview was for a small-ish startup, not for a behemoth like Google).
It's quite a common pattern these days: I often see candidates who choose a language because they think it's better suited for interviews, not because they know it well (we leave the choice of programming language to the candidate).
Sometimes this works well, sometimes it really backfires on them. Coding is one of key rubrics on which we assess software engineering candidates, and if the only signal I have is that they don't know know their chosen language very well, it's hard to justify scoring that rubric highly.
The root comment is saying the interviewee knows the language well enough to consider one solution better than another solution.
And this was misinterpreted by the interviewer as not knowing the language.
An effective interviewer would have asked "Why are you doing it this way?" instead of assuming - wrongly - it was all the candidate knew.
This actually matters. Before you even get to coding skill you want people who can parse reality accurately, and not make incorrect assumptions about what's happening in front of them - either out of narcissism and arrogance, or because of poor communication skills, or because they're following a set process which is bureaucratic and inflexible and operates with a poor signal to noise ratio. (Among other possible reasons.)
I really well versed with Python, Golang & Rust. I will not choose Rust for interviews. For me, Python is much more productive in an interview setting.
I didn't mean to imply that this applied to your case. Just a general observation (rather frustrating for someone like me, who wants candidates to do well but not that infrequently sees them being let down by their own choices).
Yeah... reminds me of a past coworker. He spent weeks writing weird comments in code, then writing weird code to read comments. From the actual source files. Then when deployments didn't work, he said they worked on his machine the deployment must be broke.
To solve the hiring problem that seems rampant in the industry, I propose for all resumes that get past the auto-filter, we just implement a lottery system. Maybe it'll be even more effective than the current method!
I skip any and all interviews that require math, algorithms, or anything else. First of all, I'm an infra / devops engineer and not a full-time software developer. Secondly, I've never used this stuff.
And thirdly - because it's a proxy for intelligence by people who think they're smart for having memorized sorting algorithms.
Who wants to work in a place where people who memorize things are conceived of as smarter than people who didn't memorize the same thing at the same time interval (i.e. cramming before interview or just out of college?)
Fuck those places, I'd rather work with human beings.
I was a recent grad, around 10 years ago. A Google recruiter called me out of the blue. After a couple of minutes, she started asking technical questions about Linux, which I had just started using.
After a while came the final blow: I was asked what was the fastest way to sum two integers (there were probably some additional specs I don't recall).
I mumbled something. Wrong! The answer is, in fact, using the TLB. I vaguely remembered what the TLB was from my CPU architecture classes, but was aghast at the connection between that and summing two integers.
The recruiter pretty much said I wasn't Google material on the spot and said goodbye. I felt bad for myself at the time, but now I can see this is a ridiculous approach to interviewing.
Every year, Google receives over one million resumes and applications. Only 4,000-6000 applicants will actually be hired — that's less than a 1% hiring rate.
These numbers are misleading af. Most of those applications are just spam, not really relevant and never get read by any human. I’ve done ~150 interviews for backend roles at google and based on my experience 4 years ago if you make it to onsite you have 5-10% of getting an offer
Many people apply to all the FANGS, since the interviewing skillset needed is similar. Moreover, you can reapply every six months. In result, this gives you perhaps 5-10 lottery tickets every year, which means it's very feasible to get in within a year or two (or three).
In other words - don't bother to apply if you actually need a job. And if you have a job already, why would you bother to apply there? It used to be attractive but is it still? With all the scandals and upheaval in the recent years?
>And if you have a job already, why would you bother to apply there? It used to be attractive but is it still? With all the scandals and upheaval in the recent years?
Eh, I've had two offers from Google that were far below the "market rate" I was receiving at some of the largest pre-IPO unicorns of the last decade, and their interview processes were substantially better.
I think i may have given the impression that it’s 10% by pure chance which it most def isn’t. There’s certainly some randomness in the system but if someone is in the bottom 50% by skill they can probably apply like 100 times and still fail every single one.
>Moreover, you can reapply every six months. In result, this gives you perhaps 5-10 lottery tickets every year,
you are aware of the saying that the lottery is a tax on stupidity?
I guess that is perhaps a little harsh, but only a little.
First off, I don't think I would want to work at any place where getting in there is represented as winning a lottery ticket. Think of the poor oompa-loompas enslaved in Willy Wonka's factory.
Second off, perhaps it's just my vantage as a consultant in Denmark but everything I've read about working in Google has made me think it doesn't seem very enticing.
Third off, even when I was not married with kids I would not have wanted to spend so much time twice a year! How many unpaid hours a year are people willing to work for a lottery ticket that essentially pays out a top-paying job?
Somewhere between 0 and infinity? I asked extremely simple questions algorithmically (not anything posted online) and didn’t discount candidates on not knowing the algorithm but about half of the people couldn’t write ~20 lines of code after we’d already talked through it. Another 30% could but the code was total mess. I passed roughly 20% personally of which about half passed the hiring committee.
if you get onsite at most companies for an experienced position the chance is rather 50% to get hired. if i would know the chance is only 5 % i would decline the onsite interview at google.
From my experience 50% couldn’t write code at all. So yeah if you only look for “can code” checkbox then you’d probably extend offers to half. Google chose to place the bar higher and that’s their right to do that
And yet if they ask you for an answer to a quirky question like "why are manhole covers round?", they expect a clever answer like "they can't fall in", rather than a pedestrian answer like "well, probably they just started making them that shape for some simple production reason, and then everyone else just kinda of did the same thing because it worked."
They aren't even all round in the US. Where I live there is a high and rapidly growing number of data centers. In fact there is currently another large data center campus being built for the company famous for asking this question. Among other things this means installation of fiber optic cabling along the roads leading to the data centers. This in turn means the installation of a large number of manholes to service the cables. All the covers for these manholes are rectangular.
Manhole covers come in a variety of shapes. A non-ironic "why are manhole covers round" question speaks more to lack of life and/or travel experience than anything else.
There are triangular[1] and even more exotic-shaped[2] covers.
Lots of man-hole covers are rectangular though. Turns out it isn't very important at all to have manhole covers that don't fall in. They are quite heavy and don't roll around on their own, so having them fall somewhere really is of minor concern.
My guess is it’s also a matter of practical usage: they’re made of heavy iron and a round one will fall in place whatever orientation it’s thrown over the cover, while a different shape needs to be carefully oriented. I suspect this also means less broken fingers.
But round one is easier to steal.. just roll them off. Whereas a square or any such shape, would be very inconvenient to move.
[Edit in response to a question]
Some people have attempted to steal manhole covers in order to sell them for scrap metal. China Daily notes that there has also been a problem with taxi drivers removing manhole covers to "steal water and clean their vehicles".
https://www.bbc.com/news/blogs-news-from-elsewhere-52400235
It's a very common thing to steal. Lots of iron. That's why they use concrete-filled ones. That's why they are stamped so a scrapyard can be checked (or alert authorities).
In my area there are lots of square manhole covers. I have it on my personal to-do list to photograph almost all the older manhole covers from my city and geo-locate them at some point, I think it could be a good indicator of how my city grew and evolved ~100 years ago.
Richard Feynman oversaw the IBM computer's use and programming used in the Manhattan Project. Microsoft also has an R&D department that would probably just give him a budget and a team of assistants to see what he came up with.
I don’t know but I shudder at the thought of what state the world would have to be in for Feynman to be interviewing at Microsoft or any FAANG company for that matter.
A bad interviewer might expect a certain answer but a good interviewer will use it as an opportunity to examine the interviewee's critical thinking skills.
Are there any other reasons the cover would be round? It gives you an insight into their thought process as they come up with more ideas and explanations.
After failing two Google interviews both triggered by being reached directly by Google HR, telling me how my public information and CV was impressive and I should be really at Google, I told them to never ever contact me again.
My feedback was that, if the CV is so impressive, according to them, why do I have to endure such interview processes?
Anyway I never bought into the whole do no evil marketing, nor bothered to apply, if it wasn't for their HR reaching out to me in first place.
I had the same experience, some internal recruiter reaching out that they were super impressed and wanted me for some special group, then a phone call where they never bothered to show up(!) so we rescheduled, then some stupid interview where they asked me to estimate the value of 2^10 or something and then told me they didn't want me for the special group after all. Complete waste of time, especially given I didn't really even want the job, they reached out to me. Taught me a lesson, at least: I'll never work at a big company, no salary is worth that kind of treatment of other people.
Their process may simply be optimized for their particular purposes. Google doesn't need more engineers, but there's a certain kind of hire they don't want to pass up on. No company really needs a genius rockstar coder that's going to quit after two years to become competition. That's why the inode question makes sense. It's a stupid question that deserves a stupid answer. If you're the kind of person that actually gives the stupid answer, you're clearly not a cultural fit. Google is looking for the person that disregards the stupidity of it, who has prepared themselves and gives the "expected" answer.
> The interviewer told me very matter of factly that it was in fact, the filename.
which is not even true in some file systems that can inline data directly into the inode, if the data is small enough.
for the downvoter(s):
> If the data of a file fits in the space allocated for pointers to the data, this space can conveniently be used. For example, ext2 and its successors store the data of symlinks (typically file names) in this way if the data is no more than 60 bytes ("fast symbolic links")
> Ext4 has a file system option called inline_data that allows ext4 to perform inlining if enabled during file system creation. Because an inode's size is limited, this only works for very small files
I had a similar experience with Proton's recruitment. They sent me a dumb IQ test with stupid questions like (how many triangles are in this triangle). I answered with "Way too many", and that was the end for me
I'm not experienced in tech interviews nor knowledgeable about inodes ... but your question and the interviewer's question seem like they're functionally equivalent. They presumably don't just want you to say "names", they're expecting you to talk about what is in a Linux inode, what a directory is, etc., and they can drop in further questions to prompt you if you don't "talk me through the design of a basic filesystem".
If the question is too vacuous surely you ask for clarification -- "well, what happens when you issue the 'mv' command" -- and presumably if you designed file systems you can talk about different implementations, optimisations, and problems crossing filesystem boundaries or whatever.
I think there are multiple things wrong with the original question:
- It's unclear what they're trying to judge. Do they want to know if someone understands filesystems on an intimate level? Do they want to know if someone knows how hardlinks work? Do they want to know if someone knows what fstat returns? Are they trying to trick someone since an inode in many contexts is just a number? This is an unnecessary level of uncertainty for a question and encourages random tangents which may not be the answer the interviewer is looking for or cares about.
- Someone who has studied google's standard questions which this apparently may be one of [1] would be able to answer this without understanding the implications, what does that tell you about the candidate?
- If you want the candidate to go into a tangent about filesystems in order to figure out how well they understand them, this is as mentioned before a really stupidly open ended question.
- If someone did understand you were talking about inodes, they may be of the opinion that the inode contains a reference to the file's contents and as such contains the file contents. In the case of a directory this means that an inode "contains" the file names of files in that directory. This makes the question a leading question which is trying to lead to what would be a wrong answer from that person's point of view. How do you answer a leading question when you disagree with what it's trying to lead you to?
If you want to determine if someone understands filesystems on an intimate level. I think my question would be far better at elucidating that.
If you want to understand if someone knows how hardlinks work, I can't come up with a question off the top of my head but I doubt that "what is not in an inode" is anywhere close to the best one.
If you want to trick someone, go ahead, this is a good question. Likewise if you want to screen for people who have googled "Google SRE Interview Questions" and memorised the answers.
I've spoken to someone who interviewed for an SRE position and she said the questions were very similar to an early phone interview she had. She said the interviewer did not know what they were talking about and were just going off an answer sheet. So I don't think the interview in this case is representative of one for a Director of Engineering but is representative of an early screening interview for SRE. In which case anything BUT the expected answer to the question "What is not in an inode" would be considered incorrect.
It's cruel and inhuman, but if you're Google, there's some cold rationality behind this.
I think the process goes for them like this:
There's 100 people applying for any given position, 10 of which might be good hires.
It's reasonable from their point of view to subject the interviewees to a process that culls 83 bad ones, and 7 good ones so that only 10 people need to be interviewed by expensive on-staff engineers, even though it looks like madness from the outside.
The rationality doesn't reflect the reality of Google being unable to innovate and continually competing with itself. Will another engineer from the same cohort who knows the same trivia and has the same education be able to shake things up?
What happens to the 3 that get rejected, do they try again later and filter through? Or do they tire of the process, give up, and work for competitors?
It's definitely questionable whether the process retains many good engineers. That said, I suppose it works as long as it culls more bad engineers than good engineers.
I remember getting one like that - Googler demanded some random value from a system .h file. Easy enough to grep if necessary, but _no_ it had to be from memory to make one Googley.
That one of my rules I always give to junior devs. Just read the docs again for what you are doing. You may perfectly 'know' them but sometimes there is an extra 'oh if you are doing this do this other thing too'. Or worse the call is similar to some other call but does something slightly weird. Does not come up often but has caught me out a few times. Never hurts to re-read it. You mostly can get away with it but sometimes...
A more human anecdote for example I have movies I know I have seen dozens of times. Yet my recall of what happened in them is not as good as it used to be as the last time I watched them was a few years ago.
This sounds dreadful, on the positive side I had very enjoyable interview rounds in places like Goldman Sachs and Lehman Brothers (obviously this was a few years ago), 3 or 4 interviews hour long plus depending on if they were before or after work. These tested what I new, how I would approach things, and giving me a very good view of the people that worked there from more junior devs, architects and management in the teams I would be working in and those around it.
The best interviews aren't scripted but are created from around the interviewers expertise but based on the skills and qualities needed for the role.
Quite honestly, I am torn. The best jobs I had so far involved multiple interviews (Amazon with a total of 6 one hour interviews and my current employer with 7, the jury is still out on my current job one month in), the worst involved either one or two interviews or multiple, but very easy and yet unpleasant ones. Scripted questions suck, Amazon in my case was good, as there was only on scripted logical question and the rest was STAR-style leadership principles centered questions.
Multiple rounds give you more opportunities to ask questions to multiple people and get a better idea of the company. They can also be a pain in the ass.
Exactly that. I often interview people as part of the team. We have normally one HR person, the team lead and one of the team present.
More often than not I give my spot to a more junior team member if they are available. So that they learn something from watching the interview as well as "just" see if the person interviewed would be a cultural fit. If they could imagine working with them.
Now, the inode question is part of the pre-screen. That's normally _before_ you get put on phone with any engineers. How the heck did you get it in "round 3 or 4"? Was your process started from scratch for some reason?
The question is meant to be asked by a sourcer - a contractor whose list of requirements does not include being answer themselves any of the questions they ask. Famously even if you know the answer pretty well, say because you were the original creator of the thing, but answer in a way that they can't link to the answer key, you still fail.
>Famously even if you know the answer pretty well, say because you were the original creator of the thing, but answer in a way that they can't link to the answer key, you still fail.
Which is the most ridiculous part of it. You are being examined and evaluated over trivia in a subject that the examiner likely has no idea about and where there are only 1-2 possible "correct" answers.
That's like sending a janitor to "source" surgeons by asking questions to people in white coats in a competing hospital about appendectomy.
Yet this is considered effective (and acceptable) somehow ...
What alternative would be more efficient and acceptable? A typical team of 6-8 replaces two persons per year. The number of resumes per opening is measured in thousands.
Internal mobility is strongly encouraged. People typically move after promotion, which is expected after 2 years. Some people don't like to move, bringing it down to about 2/year. All working as intended. Then, people moving out tend to want to join new teams, for the career growth opportunity, while you want new hires in established teams.
Note: that's anecdotal from a couple years of observation. I haven't looked into any Google-wide statistics (and if I did I would not blabber about them). But I'd be surprised if this was way off.
Are you saying a company with the resources of Google, which expects all of its employees to answer trivia and whiteboard answers in interviews - all of that brainpower and money can't invent a better process?
I don't think it's a matter of impossibility. The current process is simply a local optimum. Most practicing software engineers can pass the trivia quiz. Most time wasters can't, unless they googled for the answer key. The result is a pool of candidates that usually can understand a real interview question an engineer will ask. The system works, at the price of being annoying.
If there's only a single correct answer that the interviewer doesn't understand and an expert might get wrong, it's people who google the answers that have the best chance of passing.
I tend to ask open-ended questions. Let them talk about code, and I can probably figure out whether they're full of shit or not. And a real coding challenge proves better whether someone can code than any code question or whiteboard challenge.
If the applicant has graduated from a university, technical school, whatever, then look at the records from their exams there. Also taking into account the average level of the university, technical school in question.
> Famously even if you know the answer pretty well,
Everything above would make sense if the question was "what is an inode?". But it was "what is an inode not?". That wording doesn't make much sense to ask anyone, no matter how you spin it.
> the entire question was: What's not in a Linux inode?
Were they considering you as an experienced developer of a Unix/Posix filesystem, who would almost certainly know what an inode is?
Or were they considering you as someone who had been using a Unix so long and extensively that you had a chance of once having had to configure an older filesystem for huge numbers of inodes. Or a chance that, for some rare reason, you once had occasion to learn that the `ln` command isn't always used in conjunction with `-s`?
In either of those cases, you might then guess at what the question was getting at, in a slightly clever way. If you got it, then both of you could share a bonding moment of both knowing this thing not everyone knows, and it could be a quick warmup to better questions.
Or, if you didn't get it, you could feel thrown off, and insecure or negged, which is also a win for an evil interview process.
If I'm feeling punchy at 3am, an alternative theory is that they could be a recent CS grad, who'd had a class in which they were told to recite, after the professor, "What's not in a Linux inode is the filename," and that's what they think is important about that. (By way of introducing the separation between inode and directory entry in Unix, through catchphrase and rote memorization. Other professors would probably instead explain using a diagram or the code for structs.) (Theory variation: perhaps the only professor who ever said this phrase was at Standford, which would make calling for it an especially transparent shibboleth for frat-like alumni affinity, and an overly-precise filter for socioeconomic class.)
I once cost my employer a bunch of valuable data due to a bug in my code that the second I discovered the data was gone I knew why it was gone because I understand inodes and their relationship to filenames.
That's to say it's information that is useful to have in your head if you're an SRE, just part of understanding Linux fundamentals.
That's not to say it was a good question. Despite my encounter with that bug in my code I still wouldn't have answered the question correctly. Filenames point to inodes, inodes point to data. The word filename might not even pop into my brain when thinking of inodes in isolation.
Also it doesn't show the full picture, I'm not at all sure I have what it takes to be an SRE let alone one at Google, that I sort of know what an inode is says nothing about if I can properly use that information to make architectural decisions.
It was probably an opener for discussion. Assume the best about the interviewer for a minute. What is the best possible interpretation of where they wanted to go with the question?
The fact that the interviewer didn't get the joke and immediately divulged "the answer" makes it hard to assume the best here. If they were really trying to open a dialogue, I'd expect a chuckle and maybe some clarification (like, what _is_ in an inode?)
You may well be right. I'm reading between the lines and could be wrong - but I'd guess the interviewee gave those answers in a frustrated tone. This specific interviewer could have just been a jerk.
There does however seem to be a lot of criticism of FAANG interviews which seems immature.
I'm not 100% certain of this, because I don't know what job they ask a question like that for. It isn't a software engineering interview. However, generally:
The rounds don't build on each other. You have X interviews and the interviewers don't talk to each other and are independent events.
They have gone through phases of having an initial phone screen interview which is a hurdle, but the rest are(/were) as laid out above. There may be exceptions for very senior people, but they are sufficiently rare to exclude.
Google has it's problems to be sure - but by and large the individual people there mean well.
There is asymmetry involved, tho. They judge you as a single individual, while you have to judge an entire company from your experience with one single interviewer. The company can be employing thousands or even tens of thousands of engineers. Also, you don’t get to ask so many questions. The time allotted to your questions is but a small portion of the interview.
I interviewed for a software engineering position with Goldman once (in London). The process spanned several weeks of phone interviews with people in the UK and US (I lost track of the count), followed by a full day of back-to-back interviews on-site with 12 different people - some via video conference with New York. Questions were extremely diverse, both wide and deep. Early on in the process I decided to look at this like a game and try to actually have fun, which I did... I had fairly positive feedback along the way so I thought I was doing well ALL the way until the next-to-last interview with someone in NYC on video link. I was sitting there in a room, waiting for that next interview... the person on the other side was taking longer than the others to show up. About 20 - 30 minutes into my waiting, someone I had not seen before walked into the room and informed me very matter of factly that we will not be proceeding with the last interview and he will escort me on my way out of the building.
To this day I have NO idea what happened. I never heard back from them and the recruiter wasn't able to provide me with any further feedback when I asked.
I thought maybe they saw me on camera taking a photo of the Goldman-branded water bottle on the table while I was bored waiting... Or someone was digging and saw an anti-Trump tweet of mine. Or whatever.
Would have been more fun for me to turn them down after this whole madness (which I fully intended), but I didn't get that pleasure :)
The software industry interview process is such a disaster. The worst part of every job I've ever had (including FAANG) is hitting the LeetCode grind when I want to leave. It's so fucking worthless. Just a giant waste of time. This entire fucking industry has its head up its ass.
I can't think of a single other high-paying profession that pulls this shit.
Totally agree! I've been getting hit up by FAANG recruiters (and other companies) non-stop this year.
I live in Los Angeles where companies never did this type of interview when I last got a new job (4+ years ago) so I had to grind LeetCode for several months then didn't get the job I studied for even though I got all questions right (I was a little slow on some of them). I kind of resent it because I know my time can be much better spent (keeping up on security topics for example).
The process is so bad it makes me hope to be no longer doing software development as a employee sooner than later.
It's not that stupid from company's point of view - they're preselecting for people who really want the job, and have enough energy to pursue it. These are the people you want to for your company.
Strange that this only seems to be necessary in the software industry while literally every other industry seems to be getting along fine without these dehumanizing interview processes.
I think to the fact that other "engineering" industries do have licenses. There is no way legally they could get away with these types of interviews.
I used to be a software developer and an architectural firm (that designs buildings). The architects plus engineers had to go through 5 years of college, do years of on job training, all before they can be licensed.
I felt kind of bad for them though because I made more then most of them before I was 21.
The interviews are crazy though. The last big company I worked at had a "probation" period. For Sr Software Engineers we would only do a single 1 hour interview. But if they did not do well in the first 90 days we could fire them.
Seems much better than telling people to study leetcode hours per day for 2 months prior to an interview.
I once had a weird interview at an investment bank for a backroom sysadmin position. I went to the interview in a smart cotton tennis shirt, black trousers, and was interviewed by a bunch of techie people wearing pretty much the same kind of clothes. The interview covered many technical issues and seemed to go really well.
When I got out and was on my way home, the recruitment consultant phoned me up and quite literally screamed at me for about 5 minutes down the phone about why I hadn't worn a suit. He didn't mention this interview requirement beforehand.
So yeah, weird things happen at investment banks :-) I didn't get the job obviously.
For one of my first job interviews I called to company whether they wore suits. They said yes. I bought a suit and got a haircut, and was interviewed by two techies in smudgy polo and sweater. I felt way overdressed, didn't get hired, and decided to never do this again. A neat button-down shirt is plenty.
Don't feel bad. It's entirely possible that they filled that position somewhere along the way and some departments didn't communicate to figure that out in time.
Or the position was cancelled during the interviews.
Someone, please, write a book “Interview Questions: Linux”. Just questions and answers with short explainers. I got inode question on every second interview! Make it good and expensive af.
Most processes are flawed I found, in most companies, especially bigger ones. They try to come up so arbitrary methods to differentiate between candidates that it has little to do about the position in subject, a persons ability to fulfill that position successfully throughout a prolonged period. What they test if one candidate is better answering a specific question or not. Some random question - usually relevant to the subject. Impossible to cover all the knowledge is necessary for that position, especially the adaptability, capacity to learn (essential), accuracy, work ethics, all much more important than if a specific fact is readily available in the head of the candidate. Testing how good someone is in tests. Or if the candidate can perform well while people are watching and judging (very rare circumstance during the workdays, except for actors or performing artists).
Based on perhaps a dozen intervies here and there I had the conclusion that recruiters have no idea who they are going to employ but practically draw a name from a hat (after filtering out obvious incompetents, if at all). This includes the position I won, and those I did not.
In one occasion I refused a fairly well paid and interesting job because they tried to measure my competence by performing quick basic calculations (related to financial topics), giving impossible amount and urging as many answers as possible. Being an engineering development position it was hopelessly incompetent way to test, which they intended to be the base of future promotions and assignments of roles too. They claimed it is for the sake of fairness, testing every employee equally, regardless of the role. How supid is this for god's sake?! Roles and expectations of the roles are different and cannot be tested the same way. It was just lazyness from the HR, pure lazyness to rely on robotic methods. Robots from the HR (ironic calling themselves !human! resources) pushed through incompetent methods. Destroying fairness under the flag of fairness, crazy. I considered better not be engaged with such an organization.
Maybe these firms prepare for the apocalypse when all technology fails and has to be recreated from scratch, with only a few half-burned books around. Of course, if that were true there should be some blacksmithing and basic herbology questions in the interviews.
The hiring process is like, 80% about marketing hype, right? Like you have to manufacture consent for the public to just accept that a private institution has a monopoly on search and browsers.
It's pretty clever, I'm surprised Microsoft didn't try it (or maybe I was just too young to remember).
The interview-process is a way for engineers (who might feel underappreciated or insecure) to demonstrate how rare they are, by asking questions no one seems to get right.
At one point, why not just drop the pretence and ask "repeat back to me the algorithm on p. 343 in book xyz."
Good for you for having a spine. I had a similar experience (not google). I was expected to do prepwork and the interviewer couldn’t be bothered to think up any questions other than following a script is incredibly rude and telling of that company’s culture
Isn't the question nonsensical ? inodes are a property of some filesystems like ext, xfs..., that you can happen to use on Linux. If you installed Linux, say, on an NTFS partition there would be no inode anywhere, no ?
the inode vs filename distinction is historical unix behavior (but I don't remember whether posix mandates it), and it is quite important and relevant in many system programming scenarios. Of course not all filesystems support it.
The question is still phrased terribly of course and the candidate would have to reverse engineer what the interviewer is actually asking to have a chance to answer it.
does not seem trivial given the differing permission model, but not impossible either. for fat32 I wonder though if the total absence of permissions allows for that.
There's a few things you'd need to patch up because a few important utilities are picky about the permissions of their config files (as a protection against misconfiguration).
Google actually has simplified the process. It turns out that multiple rounds of interviews didn't lead to better-quality hires and just serves to piss people off.
I went through the exact same thing with Google. The interview was very impersonal, never going into if I'd be a great culture fit and it was simply on the basis of if I knew how to do this algorithms problem that doesn't show if I'm a good engineer or not. Ended up in a much better company culturally, and I've never looked back
That's a weirdly phrased question anyway. There's a directory entries reference in the inode that leads to the filename. So the name(s) isn't exactly "not in" an inode.
A lot of those interview questions just seem to test for "how good is their memory", which I don't think correlates to future performance very well.
Amazon pulls something similar with their LP's. I spent more time working with the recruiter and working GP's into my stories/experience than I did actually interviewing. What an incredible waste of time.
FWIW I've been at Google for a decade and I have done interview training twice and each time opted not to do interviews, because I think the interview process is terrible.
So... What does this comment have to do with the posted article? In the article Google claims that 4 rounds is what they see as the max to get a good hire/no hire signal.
Why did the Google interviewer need their potential recruit to know what wasn't in a Linux inode? Was knowing that part of the job? That seems so esoteric.
For all the complaints, people will continue to jump through the hoops given an engineer with 3-5 years experience can make close to 400k in TC/year. That is not happening anywhere else outside of FAANG and certain finance companies. Google can be as picky as they want.
I have some of the correspondence but not others, for some reason. I went digging through my email and found these - this was from 2014. Most were 'Google Research' links.
“Programming Interviews Exposed: Secrets to Landing Your Next Job"
Authors: John Mongan, Noah Suojanen, and Eric Giguère (Wiley Computer Publishing)
While I have never interviewed with Google, my experience with other companies is that.
1. With senior or experienced developer, it is usually pleasant and respectful and they are open to a diverging answer if it is justified.
2. Some of these companies either have an inexperienced person in a senior position or delegate it to an inexperienced developer to do the initial filtering.
3. Inexperienced people are extremely painful to interview with, they have "accomplished" something in their current/previous job but do not realise there are better ways than that. Sometimes it might just be an opportunity to reinforce their own confidence (imposter syndrome).
it is not optimal, but there is no alternative. The interviews should show 1) you want the job, i.e. you put some effort; 2) you can learn, i.e. those ridiculous questions; 3) team fit, i.e. you like them, and they like you. Programmer interviews are the only thing people can do in a reasonable timeframe.
As programmers we always learn, we learn what we need to learn to do the job, there is no reason to reject someone because he does not know the answer to a technical question, but if you are not making the effort to know the answer in order to get the job, maybe you don't want the job.
I have just passed an interview for my new job and it was none of the above. Yet very technical, still very involved - but with competent people on the other side that were showing they are as interested in getting someone hired as I was in getting the job.
There were 2 interview calls in all (normally the second one would have been on-site but Covid ...).
No need for BS scripted questions, no need to ask trivia, there was coding test but on a computer (not paper) and nothing crazy you would need to read books or study for.
Is it perfect? Of course not. But that's why there is a 3 months trial period in the contract during which they can terminate the employee "overnight" if not performing satisfactorily.
That's a much better solution than trying to evaluate everything and the kitchen sink in an interview by asking trivia questions and wasting the candidate's time with reams of books to study. Which, in the end, evaluate only whether the candidate is able to cram for interviews and not whether or not they are actually competent at doing their job.
Software engineers can learn everything and can take on whatever tasks. Small teams may look for specific skillsets they need, big companies can afford to hire people then find something they can work on later. Also, they are more candidates so they are basically doing a filtering rather than looking for the right candidates.
Yes, there are 3 months trial period, but Google will have thousands of candidates every week, they need to quickly filter them rather than evaluating them equally. Many people interviewing don't even know the job they are interviewing for, that's the problem of big organization.
>2) you can learn, i.e. those ridiculous questions;
So why do I have to re-prove this at every new job? It's not obvious enough I can learn if I've learned a programming language or framework in the past? Do companies have some brilliant insight into neuroscience where they know people become incapable of learning at some point?
Any 2/4-year degree should also answer that question as well. Lots of things can answer that question. Ridiculous questions are about the laziest way to test someone for it.
Sounds like a failure of communication on both ends.
The interviewer should perhaps be more explicit in his question, i.e. "What file metadata is not stored in its inode?". He skipped the explicit part, since it probably seemed obvious for him. The failure of communication on your end was not picking up the obvious context of the question.
You have to understand the context of the interviewers. The person may not have really cared. They probably weren't interviewing for their own team. They may have their head in the middle of some problem they are thinking about.
Google is hiring 10's of thousands of engineers a year. It's really hard to do well. Most of the questions are deliberately scripted because they are known to be good questions on some dimension.
So... work with them. Most of them actually want you to do well. Most of them are smart. Some of the questions are an open invitation to just talk and show that you can behave like someone they'd want to work with.
Your answer of "dinosaurs" etc, while the result of frustration more than anything, just said to the interviewer "not someone i want to work with".
In which case they should have teams dedicated purely to technical interviewing, with members regularly rotated in and out to keep them fresh.
When I did technical interviewing for my company for a period, granted it was still on top of my 'day job ' but I had the scope to get really invested in the process, and wrote guidelines for other reviewers. Treat technical interviewing as a respected role in its own right and not as a chore that interferes with 'real' work and it's a better outcome for all parties
That might well be a good idea. I can imagine downsides to it, but it might work.
The long and short of it is though - one has to face the reality of the situation they are in. If you go interview at Google (or any FAANG I would guess), you have to understand what you are in for and do your best to get through. Or, just don't interview there.
One company I interviewed at in late 2019 referred me to an interviewing-as-a-service. I forget the name, but the gist was that this service hired and interview-trained software engineers (at least part-time, maybe full-time) who then conducted interviews and provided feedback to the companies purchasing the interview-as-a-service.
From my perspective as a candidate, it was fine (the interviewer was friendly and asked industry-standard questions) but I do wonder how it goes for companies that essentially outsource their hiring bar.
On the other hand, you'd need to be doing a lot of hiring to make it worth dedicating a software engineer to just interviewing people. Or you have someone who doesn't really understand code—like a recruiter—run the interview, with all the difficulties that creates.
There is no need to "respect" the process, but just to be more thoughtful:
> What's not in a Linux inode?
> My answer was: Lots of things...dinosaurs, the moon...
You can answer that you want more clarification, or even answer that "we can google this".
The "dinosaurs" thing might make the interviewer feel that you are being unprofessional since the interview is to test one's ability to perform in a professional environment. You don't help your colleagues by answering in this way when asked similar questions in work...
As an ex-Googler who interviewed 100+ candidates (mix of phone & onsite interviews) I can tell you that there is a great variance across the company groups in the quality of questions we ask. And the reason is simple: it's up to the interviewer to choose his questions. Questions aren't standardized.
I took great pride in the fact that my questions were unique. I designed them myself, about 30: some quick knowledge tests, some elaborate coding challenges, and everything in between. And for a given candidate I would pick about 6-7 questions of the 30 to ask them.
I didn't care if the candidate didn't know or didn't find an answer. I would entice the candidate to drop it and just move to the next question. Some candidates make it hard because they want to keep persevering, keep thinking, but there is limited time in an interview. As an interviewer, my goal is to (quickly!) find and evaluate what you are good at, not what you don't know.
Unique questions? What's there to be so proud of in selecting questions? Are you playing jeopardy with the candidates careers? Enticing the candidates to moving on and not answering questions in what is probably the biggest interview in their life? "Quickly!"?
> Some candidates make it hard because they want to keep persevering, keep thinking
Yeah, amazing that some candidates want to demonstrate their perseverance even in face of problems that they find challenging. Crazy right?
I'm wary of pushing people to move on to something else because I know that if I was on the receiving end, I would think that I fucked up and the interviewer is trying to get the interview done early.
A candidate who spends far too long on a part of the problem without getting anywhere will get some guidance and nudging. If they take that on board and get back on track then that's great - they're responding to feedback and correcting course. If they remain too committed to their chosen approach and continue to struggle, then we've seen it with our own eyes.
At the end of the day, we're giving candidates the benefit of the doubt and recognising that, a lot of the time, it's their nerves that are doing the talking and you need to work with that.
Well, as evidenced by this thread, candidates are frustrated by the interviewing process at Google, in particular by poor/generic/boring questions that test a narrow/irrelevant topic. So, yes, I took pride in selecting questions that aren't like this in order to find what the candidate is good at, not what they don't know.
And rest assured that I always made it very clear to the candidate that abandoning a question they are stuck on is best to maximize their chance of doing well in the interview. If I have a 45-min time slot to spend on a candidate, I don't want to waste 30 min on a single coding challenge that they do poorly on and have barely 15 min to cover other topics. If I get a sense they won't do well after 10 min, I stop it, move on, and that leaves us 35 min to do other coding challenges. I have more chances of finding what the candidate is good at in 35 min than in 15 min.
Given that you probably had 60 minutes tops, you expected a candidate to answer each question in nine minutes at most? If you left time for candidate questions (I’m assuming you didn’t), there’d only be 7 minutes a question.
I don’t think you learned this style of questioning in interview training. Going off script like this uncallibrates the entire system. In fact, if I was your coworker, let alone manager, I’d recommend you for remedial interview training. This is not how you conduct an interview for any role.
What’s happening is that companies want to completely remove risk from the hiring process.
In the real world, you cannot remove risk. You can manage it, but you cannot remove it. Asking candidates to go through 6 interviews before making a decision and not telling them when a decision will be made signals a risk adverse culture that cannot make decisions.
Companies don't want to do job training anymore. Instead of a general background and attitude check, they need to know if the candidate has all of the individual skills that will be used on the job.
This a hundred times over. I still remember in 2020 multiple places asking me "I see you've used .NET core, what *version* have you used?".
I had a kind of career crisis/breakdown, where I realised no one gave a shit about anything except my utility as a walking set of tech keywords. Accepting that it wasn't working for me was one of the best things I've done for my career.
> where I realised no one gave a shit about anything except my utility as a walking set of tech keywords.
I am genuinely asking. Why is this objectionable?
Why do people find it so horrible that their labour is a commodity? To me that just tells me I should treat my labour like a merchant treats his goods. Always be checking the market to ensure you have something worth selling and while you might sign long term deals, periodically check for the best price to ensure you are getting it.
Why is it important to you that your employer view you as a person?
Because selecting candidates based on tech stack is almost universally the sign of incompetent tech management. Anybody who understands software, knows that intelligence and master of fundamentals trumps tech stack experience without exception. Linus Torvalds would unquestionably become a better Ruby on Rails developer within four weeks than 90% of people with 10 YoE in it.
Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
One of the strongest signals of how good an engineering organization or a tech team is how few specific technologies they list in their job ads.
I've been hired as both a Ruby on Rails and Go developer without prior experience, and managed just fine in both case. Of course there's a bit of ramp-up time, but it's not that bad.
I'm not even an exceptionally talented programmer: just a competent one. Of course there are real differences between languages that matter, but at the end of the day ifs are ifs, ints are ints, functions are functions, etc.
That said: there are some reasonable scenarios when you want to hire someone with prior experience; for example as a first or second hire it's probably a good idea in most cases, or if you really need someone who can hit the ground running.
On the other hand, it would be nice to know the core languages in play. I have no interest in working in Java anymore, I avoid job listings for companies that would expect me to write Java. I don't want to have to go through recruiter screens etc before I can ask someone who will know what language I would be spending the next year of my life working with
Our solution to this is that we are clear that we're looking for Haskell programmers (as in that is what they should expect to do) but we have very modest requirements in terms of prior knowledge. I made sure to relay to HR that almost nothing is required in terms of prior knowledge (language-wise) and that we should expect to teach Haskell to people instead.
I think that in the specific case of Stripe, they specifically mostly use Ruby (from answers I found online). I may be wrong, but I assume that not mentioning Ruby is a way to attract Python/Go/C/etc. developers that might otherwise think that since they don’t code in Ruby, they shouldn’t apply.
Not to pick on Stripe, but why not say this explicitly?
"We mainly use [language X], but you don't need experience in [language X] for us to consider your application" - this is a totally normal thing I've seen in many job postings.
> Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
You can't just go around telling people that: you are going to make hiring harder once everyone figures it out!
When you get a referral for a 10x and you're meeting at Blue Bottle you need an ice breaker; clueless community-college tier HR asking for versions of frameworks makes for an excellent one!
This makes a lot of sense. If a person has good fundamentals and understanding of engineering and CS, then they should be able to master any tech stack. I think in software development, we are in a weird position. In other engineering fields, it is expected to have a base line knowledge and the ability to learn into new processes. Most software companies seem to not want hire engineers who can do that.
The answer to a charitable interpretation of your question: most tech workers don't mind exchanging their labor for money, of course.
The answer to the question as written is...of course people want the entity that has outsize influence on 40 hours of their week to view them as a person instead of a mindless cog in a machine. People get treated better than cogs. Workers want their working hours to be as pleasant as possible, which is much more likely if your employer sees you as a person.
Not a mindless cog, but more as a merchant or even a labour supplying Lambda function. Just simply acknowledge that my employer and I are trading, the arrangement may end at any point for business reasons, and likely will end in a few years as our needs diverge.
Needs can include a nice workplace and you can negotiate specific details about what that means to you. I did not mean to say that it needs to be money.
A screwed hiring system is something most companies appear to be able to afford, given how many have one. When that same experience is flipped around to the employee, they can't afford it and it's a disaster. Few employees want zero job security and an expectation to be wading through the job hire swamp every couple of years.
You're not describing an employee, you're describing a consultant. Not everyone wants to be a consultant, particularly since most people don't get any training in it before they have responsibilities. If proper entrepreneurship was a subject at school, then maybe people would be willing to be their own business, but that's not what the system creates (or wants).
Fair, I can see why this might bother people. I don't think job security is a thing (career security perhaps), but I can get why its absence would be disturbing.
> expectation to be wading through the job hire swamp every couple of years.
The high level of turnover in this industry indicates that people at least tolerate it. The only people I know who make it 24 months in a role are chained by stock options.
But not all of us want to trade at that level of granularity. 'Do you have any mechanical engineering jobs' not 'Do you have any ceramic ball bearing housing design jobs'.
Because a Company expecting a "walking set of tech keywords" is a terrible deal for everyone but charlatans.
It is terrible for inexperienced developers eager to learn on the job as is common in other industries or was in ours in the past.
It's terrible you're an experienced developer that is able to pick technologies quickly, or just wants a proper work-life balance.
It is terrible for developers who are deeply familiar with the technology but expect to work with a team of professionals, rather than with "walking set of tech keywords".
I guess this is how I think of it. I enjoy the fruits of modern society, the airplanes and fast food and nice phones. But to make that happen, you need specialization, you need people know get really good at flying planes then just do that, and people who get good at making fast food and iphones and everything else. And inside that, you need people who specialize at every part of the supply chain, and what you end up with is people who have spent basically their whole lives fixing bugs in webservers used to sell analytics software to businesses etc. etc. and it becomes so abstract and you’re so disconnected from the feeling that you’re actually helping anyone or worth anything to society that it doesn’t really matter that intellectually you know the whole system would collapse if you don’t have people doing jobs like yours. And you should have friends outside of work, but many of us don’t really, at least not to the extent that way like, and even then work is literally most of your waking day most days of the week, and the knowledge that not even your coworkers or superiors or anyone else really cares about you in this grand societal project called modern civilization that you’re basically dedicating your life to maintaining, I can see how that would get to someone.
Dear god, that was beautiful but also depressing to read. I think this is it, exactly. I also think that it explains a large part of why so much software is bad. Specialization is a powerful thing, but without a unifying concept of the end goal, it's easy to become trapped by local maxima.
In short, employers have some degree of power over you, and if you perceive people who wield power over you as wielding that power arbitrarily, that is nearly universally experienced as frustrating.
In GP's case, the arbitrariness originates from their potential employer not taking the effort to really evaluate GP's relevant skills in software engineering, but instead resorting to lazily ticking boxes on a checklist. And what's on the checklist isn't even particularly relevant.
What I imagine this does to GP's view of the world (based on what it would do to mine) is: "I believe I am competent because I've built up a set of subtle skills in software engineering over many years, and this is what I take pride in. But from an employment point of view, this is wasted time: I should instead have focused on optimizing the checklist (and I only found this out after years in the industry)."
Great response. This is why I ended up not becoming a teacher, despite everyone and their brother telling me that that's my calling (I still hear this at work constantly from people I train). I could have absolutely dedicated my life to something with low pay. What I would not do is accept an environment where I was not treated as a professional. As far as I can tell, the modern American education system treats its educators like crap and hamstrings them every step of the way. No thanks.
Because people have brains, can learn new things and technologists don't need experience with particular technology to be successful using or working on it.
"I am genuinely asking. Why is this objectionable?"
Software engineering is at a schizophrenic point where it is very hard to categorize in either of traditional "blue collar" vocational job (given people seem to be employed close to very little formal schooling) or as a "white collar" professional job (given some roles need a CS degree level understanding of the fundamentals).
Some roles are more the other than the other.
I'd say listing a very specific tech stack signals the employer is looking for "blue collar" "commoditized" labour.
White collar "professional" types probably feel treating their contribution as "commoditized labour" is a category error.
More than anything else software engineering most closely resembles a trade.
The majority of useful education comes from mentorship and on-the-job experience. Sure, you can get a formal education, and sure it helps, but it doesn't make you a useful software engineer. It just gives you a foundation to build upon through mentorship and experience.
IMO, because the different .NET Core versions the commenter talks about aren’t that different and one can easily learn another version if they are already well-versed in one if them.
Also I am wondering: if management eventually decides (advised by external consultants of course) to switch to a newer version, then what do they plan to do? Hiring a new team?
Because the buzzwords are never even coherent. "Puppet or Ansible" - well no, those are not even slightly the same thing, which one are you using? GCP or AWS or Azure - same thing. Which one are you using, not what are you imagining?
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
Minimum four slice toaster with proven experience to deliver results and work autonomously in a fast-paced family kitchen. Ability to cook eggs a plus. Must comply with government product safety laws.
> Why is it important to you that your employer view you as a person?
Because we, generally speaking, are people and not robots ;)
That being said, I agree with your point : people would have less issues if they just felt happy about whatever makes logical sense. That's just way too hard to live by for most people.
> Why is this objectionable? [to reduce an employee to "utility as a walking set of tech keywords"]
> Why is it important to you that your employer view you as a person?
If what you mean is that it can be rewarding (intrinsically and extrinsically) to think about skill, craftsmanship, and other ways to make your labor a great value add, sure. Most of us benefit by thinking about that.
If you're really asking about why keywordification is a problem, well... keywordification of job roles indicates a way in which companies are quite possibly struggling to actually model the roles they're hiring for and identify what makes make an individual productive within them.
This happens on at least two levels:
1) Technological. Engineering decisions are sometimes "we have a specific problem, specific tech is the solution to our problem, therefore we need expertise in specific tech." In that case, the keywords regarding that tech are meaningful. But for non-trivial use cases, engineering problems are very, very rarely just that, they're commonly the aggregation of off-the-shelf + consideration of how to mix them with what tradeoffs + in-house custom solutions embedded in an organization attempting to understand and model its domain problems and fit/reshape all those solutions to those models. This is not exactly a keyword-driven process. Keywords represent the shallow end of the pool.
2) Human. While labor clearly is something bought and sold on the market, even from a point of view of a value system which is OK thinking of humans primarily as industrial inputs, it turns out that's a significantly leaky abstraction and most of us have all kinds of "compiler flags" or other inputs of our own that make us more or less productive. Some might consider this to be too warm and fuzzy; they might find it comforting that it can be approached from as a-humane and manipulative point of view as one might approach tweaking a database to get it to perform better: https://www.youtube.com/watch?v=HkFztAgK-8U
As for whether it's OK to think of humans primarily as inputs to any process on a moral level... like Terry Pratchett's character Granny Weatherwax said “Sin, young man, is when you treat people like things. Including yourself. That’s what sin is.” What are the consequences when social institutions consideration human beings primarily as inputs to institutional purposes? Generally, individual life, liberty, and pursuit of happiness become valued less, and individual suffering is more freely disregarded. Not super desirable under my value system. YMMV.
It’s not about humanism but mutual investment. I am investing my (very limited) time into your company to make you profit, you can invest in training me or helping me get up to speed on your specific needs.
But that is just trade and you can negotiate for those things. The employer benefits from getting you up to speed in the same way that someone might offer to send a truck to a store to get something delivered faster.
Wasn't working. I was not in demand. I had to constantly reach out to people, just to get interviews at places I didn't really want to work for. And even then they'd usually reject me.
It was a wake up call that I was on the fast track to nowhere, and something had to change.
Ended up specialising in an industry and doing contract work. I'm not super successful yet, but there's a lot more interest in me. My work days are much less frustrating and I'm earning more.
Looks like I am on a similar path to you but you are a couple of steps ahead of me. Is there a place I can contact you with a few questions. I'd really appreciate it.
Is it possible the interviewer was asking this question because they wanted to get a sense of if you were aware of which version was being used? And as follow on, were you part of the decision to update or not update, and your thoughts on the trade offs in that kind of scenario? Just a possibility. Certainly if the recruiter is asking you that, that’s a bad sign (although recruiters are often very detached from the thinking of the teams they’re hiring for).
Yeah it could be a lazy way for an interviewer to check a requirements box that says ".NET Core 3.1 experience". But there is a chance that this is a way to determine whether any upcoming questions are relevant - like if you haven't used .NET Core 3.x, it's probably pointless to ask a question relating to some feature introduced in C# 8.0.
It's a contrived example of course (particularly if the end goal was just to check the "knows feature X from C# 8" box!) and I wasn't at those interviews so I've no way to know what their intent was. I'm occasionally on the other side of the interviewing table though so I'm just trying to reason through why this might come up. FWIW I hate the "what isn't in a linux inode" type questions, or situations designed to fuck with the interviewees.
Asking what version of a tool was used, actually reveals a lot about the candidate. It's not about knowing if you know the exact same version as the company.
First probe is if the candidate doesn't have slightest clue what version they were using, that's a big red flag. This is more common than you would believe.
Second probe, candidate knows, but they only used a 25 year old version (also more common than you would believe when it comes to c++), this can be a warning flag that they are not interested in learning new things. But doesn't have to be if it was company policy, which is also interesting if they were in position to change this.
Third probe, ask follow up questions on differences since version N-1, this shows if candidate is staying up to date with latest trends or not.
The fact that they ask this question does show some bias but it may not be as much as you think. I can interview a person and be interested in finding out how much he/she fits like a glove for the tech stack and still put more focus on other qualities. Moreover, I expect a capable dev to not be too judgmental/unconfident and just answer something along the lines:
"No, I'm not familiar with this, but I have done [market themselves, mention relevant experience, ask relevant questions] and I'm confident I can get the job done"
I think this is a problem for the greater .NET community in general. I've participated in dozens of interviews where the "technical" interview is them asking obscure .NET or C# related questions like your some kind of technical glossary. What's worse is these questions are likely related to the one or two instances it's ever used in their entire codebase(s).
It's not that I wanted them to love me for who I am as a human or anything.
It's that I firmly believe that there's more to software dev than just knowing a 'stack'. And even then, fair enough if they were curious about my .NET skills. But them asking about specific versions of .NET core really woke me up into how much of a commodity labourer they were trying to turn me into.
I think the bigger issue here is that this process has made it too random and dilutive of the candidate pool.
Many software engineers have accepted that they have to continually learn and will do so.
This process though, makes it impossible to know what to learn with an impossible random and unknown credential set. It's not the same as something like elevator attendants having an obsoleted skillset. It's a combination of not having time in a lifetime to even try to specialize in the random employer chosen skillset. When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
> When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
At the risk of suggesting you might be dating yourself, I think this is an outdated model. It's simply no longer realistic. I personally believe that having personal expectations of what my adversaries or those outside of my control "should" do will inevitably result in sadness on my part.
Corporations will aim to do what they must to increase profits (given, by definition). Any additional assumptions from that are liable to be faulty. Perhaps you are used to the times when they needed to train staff but that's simply a symptom of the circumstances as opposed to a duty.
People change jobs at the drop of a hat for reasons that are well within companies' control. It's not like people want all that stress and hassle, they do it because they're incentivized to do so.
Sometimes. Other times they are just sampling what's out there to see what suits them the best, or playing the comp boost game until even their best face forward isn't able to garner a higher offer.
The former happens, I’m not convinced that it’s a common occurrence. Changing jobs is genuinely stressful, I don’t think people do it lightly. The latter is usually something the company could fix, but won’t.
Even still, it’s obvious that comp alone isn’t enough to retain employees. Even FAANG companies, which pay extremely well, have pretty low retention numbers. Facebook does best here, at an average job length of only 2.02 years. If comp was enough, people would stay there longer. This implies that people are changing jobs for reasons aside from “this other company will pay more”.
It’s not just about absolute comp. If google will pay you more, then maybe you leave facebook. That’s not because google pays more than facebook, just that it’s easier to get a “promotion” by taking a hire role elsewhere than it is to get an actual promotion. It doesn’t mean you don’t pay market wages, but it does mean you don’t pay that person their market wage.
That’s exactly something companies have under their control. If people are leaving because it is seen as the sure route to a promotion, then perhaps providing clear advancement opportunities internal would reduce this phenomenon and help keep your high performing talent.
The present employer and prospective employer have a different perspective on the individual. It's entirely possible, and indeed somewhat common, that individuals are hired to levels to new employers beyond what they would be able to justify promotion at their existing employer. The only way to eliminate this is prolonged and comprehensive interview process, which is what TFA is railing against.
I disagree that this is the only way to eliminate this problem. Companies could loosen promotion criteria to be more in line with what external candidates bring. Ultimately the cost of lost knowledge and backfilling is quite high, and could easily justify faster promotion cycles on a monetary basis alone.
Even if some of them genuinely get promoted before they’re ready and wash out, you’re not really that much worse off than if you’d lost them before. Besides, there’s always the risk that your new hire is unprepared too, which is a much harder thing to quantify.
Incredible that you're the first person I've seen mention a second-order effect in this conversation.
I don't know what it is but I feel like people have forgotten just like basic truths about how humans work. Maybe it's because managerialism has infected everything.
That works if this is a "one time game" (game theory) as opposed to a repeated game.
If an employer does do training, it means they'll probably continue to do more training over time, which helps the employee become more valuable.
If the employer doesn't do training, yes they may be able to allocate the training budget to salary, but they are not going to spend anything training you or letting you work on projects to increase your skills while you're there, unless they absolutely must.
I think people also have some human perception of how they're being treated, and prefer to work for people that invest in them.
Not necessarily. It's not easy to find a boss who you genuinely trust to consider your best interests, for example.
Out of curiosity, what sort of "non-monetary" benefits were you thinking about? There's usually not a reliable way to turn (small amounts of) money into the sorts of things that really build loyalty.
So the answer is to not spend the money at all? How much are you costing your company by putting candidates through 8 hours of interviews only to reject them. Rinse. Repeat.
All the while, productivity suffers as the remaining team falls further behind due to short-staffing and being pulled away from their real jobs to interview.
Professions mandate training minimums per year in order to maintain credentialled status. They're low, sure, but they at least create a need for ongoing professional education.
I literally said it isn't all about money. Most people leave because managers[0]
> In general, people leave their jobs because they don’t like their boss, don’t see opportunities for promotion or growth, or are offered a better gig (and often higher pay); these reasons have held steady for years.
And if it is about money, then this is called paying competitively.
But lastly, recognize that if everyone is training employees you're still not really losing out unless you're only hiring entry level employees. Sure, you might be training someone that leaves, but so does your competitor. But if you're only hiring junior engineers then you're probably doing something wrong that's much bigger.
That works when you're employing a bunch of Wordpress monkeys who do nothing all day but mess with CSS and install plugins. Not so much when you've got a mature SAAS product, parts of the system are tricky to work with, and stakeholders are breathing down your neck to implement new features so you don't have time to cross-train your teams.
Losing people who are experts within the domain of the software they're maintaining because you refuse to invest in them is going to cost you thousands of dollars... the only question is whether that's tens or hundreds times that amount... and in some cases it can cause you to lose your entire business.
Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
Basically there’s two types of efficiency, investment efficiency and allocative efficiency. (There may also be other types I don’t know about.)
Investment efficiency means people are incentivized to make positive-expected-value investments. Think about how people are incentivized to invest in their house, e.g. preventative maintenance, because if the expected value is positive then they will recoup that value when they sell the house. If you’re renting you don’t have this with respect to where you live - water damage or no, not really the renter’s problem. Investment efficiency is maximized by private property, where you know that no one will take your property without your consent.
Allocative efficiency means things go to whoever is willing/able to pay the most for them. Renting does have this property - if both of us want to rent a house, and I’m willing to pay more, in most cases I’ll end up getting the house. This is why gentrification can cause displacement - when wealthier people come into a city and are able to outbid the current renters, they win and the current renters lose. Allocative efficiency is maximized by auctions and things like them, where the good goes to whoever is willing to pay the most.
Bringing it back to your comment, job training isn’t worth it because our careers as programmers are dominated by allocative efficiency, not investment efficiency. If you can train a programmer create $50,000/year more value in general (i.e. it’s not training that would only be useful to your company), they can now get paid about that much more from any of your competitors, and you will have to pay them about that much more to stop them from leaving. So you gain nothing from giving them general-skills training.
Another way of solving this problem is with sectoral bargaining. If you have a sector-wide union, they can make all companies start training simultaneously, or assume some of the costs themselves. It’s a win-win for the industry and for the programmers, but it doesn’t happen nearly as much as it could because of that coordination problem.
>Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
But it makes Reginald the investor angry that his ROI isn't exactly 20% each quarter, so they jettison apprenticeships and start cooking the books to make that possible.
So, in this hypothetical, the sector-wide union is preventing individuals who learn to create an additional $50K/yr in value from realizing the increase in pay which would otherwise accrue to them?
In return for wasting training on employees that will leave for other companies, the company is getting its employees trained for free by other companies in the same way. In aggregate everyone wins because employees now get training.
The union is ensuring that no company can ruin it for everyone.
Yeah, or at least they aren’t able to capture the entire $50k/year in value. It kind of sounds bad but it’s a trade and there has to be something in it for both sides for it to happen.
You say that and I’ve seen several companies in practice echo what you’re saying. However, I fail to understand why they don’t simply make better use of contracts and probationary periods to solve that specific problem.
The problem of a probationary period is that it pushes all the risk to the employee.
While I agree interviewing has gotten ridiculous with all the leetcoding and ten rounds of interviews and FAANG cargo-culting and whatnot, one small advantage - assuming I'm not desperate for a paycheck - is that it gives me, as a prospective employee, time to consider and withdraw my application if I see too many red flags or I just prefer the devil I know.
A short interview process with a probation period on the other hand is a big roll of the dice. Maybe I'm not able to ramp up on time, or make a silly mistake due to unfamiliarity with the codebase or underlying business logic. Maybe I don't get on with the team or manager. Maybe I'm going to be dumped into a doomed death march project on day 1. I could find myself unemployed a month later with an embarrassing gap in the resume. Perhaps on the other hand a better interview process (not longer, just have properly trained people and constantly improve the process with feedback) would save us all that pain.
In a world where short, high-risk interviews dominated, you could just go roll the dice again. It would be a negative signal (why is @foo interviewing after only 60 days?), but nowhere near as bad as “why is @foo still interviewing after 6 months in this job market?!”.
Probationary periods could work but it's a coordination problem. Such periods are the norm in Europe (coz it's very hard to fire someone) but for an at-will place like the US, given that the industry doesn't really do probationary periods in general, any employer who starts doing it would be at a disadvantage.
In reality nobody knows what skills will be needed for the position. Quite often not even the people who do the job. You can let them write down what skills are needed for the job, hire somebody who checks all boxes, and it could still be a catastrophic failure.
If that's true, then the interview process would focus more on skills. From what I hear, faang companies are all about the leetcode on the Whiteboard oh, and they don't seem to ask specific questions about domain knowledge. In fact, you often don't know which department or project you're going to be put on when you get hired by one of those companies. And apparently the interviewers don't know either.
At least a few years ago, Google made it a point that the interview process was generic, not specific to any position or team. More like an undergraduate admissions process.
I left a hedgefund interview loop for this reason.
I finished the 7th on-site interview. After I left NYC and flew back home, they wanted a 8th ( phone screen ) interview because one the interviewers lost the results.
On the one hand, this space’s modus operandi is more data is always better.
On the other hand, they have to trade and make decisions in a fast paced environment with imperfect information.
funny same experience here. I interviewed for four months at a very select and under the radar fund. Once a week I would go in from 730 am to 9 am and speak with a member of the fund. I got all the way to the end, and in a bout of emotional torment, I turned the offer down. In hindsight, its one of the biggest regrets I have. Would have retired long ago
Why did you turn it down if I may ask? I’ve made the decision several times to go with lower paying offers because I ended up deciding there was more to life than just a paycheck.
I don't know if you've been through the firing process on either side, but after you go through a couple of dozen of these, and the hit to the morale/performance they entail, not to mention emotions involved, you tend to at least try to vet better to avoid such huge distractions in the future (a lose-lose for everyone involved!)
I was going to say that there are tons of parallels with how some fund managers approach investment. I have met lots of people who have this trait for over-analysis, not one has ever made consistently profitable investments. Over-analysis is a failure to understand what information is important.
This is going to become more and more common though. In fund management, there has been a huge move towards "professionalisation"...which, ofc, means doing lots of pointless exams that select for the wrong thing. MBAs are the same. It is very hard to solve because the system selects for people who will play into this self-image (in my experience, this isn't solvable...you can either handle the risk of being wrong or you can't).
This also overlaps with a lot of the issues that a lot of companies are having with hiring. A company which frames hiring as a risk rather than opportunity and has these very long, negative process of hiring (be real, the point is to uncover "weakness", not learn more about someone) is going to fail to hire people of different backgrounds. The amazing thing about the "candidate shortage" is that it isn't more severe. Companies are so bad at hiring, it is surprising they end up making any decisions at all.
Almost every single tech company I've interviewed at (ranging from medium-sized startups to FAANG), I've given at least 5 interviews, going up to 7. The only exceptions were very small startups and a couple of large Chinese organizations, where they stopped at 3.
I remember interviewing for some grad roles. No hackerrank, no bullshit, very straightforward companies with "easy processes". Both had one "interview day", and five/six interviews total.
I read your comment and I was thinking in my head...wow, five seems like a lot, and then I realised that even these places I liked went pretty hard...I think they call this conditioning.
I didn't get either job btw, the work was trivial but I get terrible interview nerves so tanked both of them...in both cases, I also had a 6-hour take home...the results of which were largely ignored. Neither company is ever fully staffed...ofc.
To me, rounds imply a decision point (and delay) in between.
If I talk to HR on Monday, take a phone screen with an engineer on Wednesday, and come on-site (or Zoom now) with 4 engineers next Monday, that’s 2 rounds and 5 interviews (or 3 and 6 if you count HR)
> To me, rounds imply a decision point (and delay) in between.
My experience has been that if you clear the engineering phone screen the company asks you to go through all the rest of the (4-6) interviews, even if your performance in one or more of them has been sub-par. And at least here in India the post-screen interviews are spread out over several days to 2-3 weeks - there is no "onsite" as such, even over Zoom.
And this is why the distinction is important. You could have an offer by Wednesday. That's a 10-day turnaround, and no one was stringing the other party along. When you consider scheduling, unless both parties are desperate, the process couldn't reasonably go much faster.
They'll miss most of the good talent if they're doing 6 interviews for a standard role. The candidates with skills and options will go elsewhere and you'll be left with the desperate dregs.
I don't think it's that at all. It's very easy to fire people in US. I think they are trying to hire cultists. The harder it is to get in the more people think they're special once they do and the less likely they are to leave.
Do you have probation period where you work? i.e. if an employee doesn't live up to expectation, release with short notice? Where I am, a 3 year contract typically carries a 3 month probation period, and a 1 year contract carries a 1 month probation period.
The problem is management are often too busy or overwhelmed with other stuff to observe and provide feedback until someone's passed the probation period then releasing them becomes a bureaucratic nightmare - and when the new hire's not getting feedback, you can be sure not a lot of the rest of the team are.
Probation periods in the US are rare, especially for white collar positions like software engineers. Of course, that’s mostly because of at will employment where either side can choose to part ways at any time.
It's a bit like the good-books/bad-movies phenomenon.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
Fire fast. Use that 90 day try out period. Contract-to-hire.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
Just personally I would never accept an offer that was contract for hire and think it's downright insulting a suggestion. My family needs health insurance and the market has never been so cold that I'd be desperate enough to take such a garbage offer.
Nothing about contracting precludes having health insurance though? For the roles and situations I'm talking about this would all just be factored into the rates.
Even if they can just pay for health insurance out of pocket, they’d be switching plans twice, and each time they’d reset their deductible and possibly need to find a new doctor.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
> Fire fast. Use that 90 day try out period. Contract-to-hire.
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.
There's probably not a single one-size-fits-all solution - what works for FAANG and their millions of applicants is lunacy when you're a three-person startup, much like adopting Kubernetes to run an internal web app with half a dozen users. It probably starts with proper training in conducting interviews, a respect for candidates' time, a realistic appraisal of your needs and budget, and constant feedback-driven refinement of your process.
I would also suspect that any filtering mechanism that cuts out the truly destructive people might well be either unacceptable or illegal at this point.
The solution is to accept that shitty candidates can't always be filtered out and to have a probation period to remove them before they do too much damage to your codebase/morale.
How? I have seen people with 25 years service (electrical engineer) walked out with zero notice. Unless you are unionized, you can be fired on the spot.
Increasing risk of liability for firing is real, as is increasing oversight of discrimination law. You can be fired on the spot for breaking company policy, or doing something illegal. Without more info, that’s what I might assume you saw. But getting fired for mildly low performance without notice is not normal, at least not among engineers in large companies, and assuming it’s not because a division or the company is being shuttered. Companies have to give people feedback and give them time to respond. Failure to do that can and sometimes does result in legal action compelling the company to prove the employee was failing and that the company did not unfairly discriminate even unknowingly, which is costly, difficult, and risky. Plus, most companies aren’t capricious with firing engineers, and are also aware that hiring is expensive and employee ROI can take time.
> result in legal action compelling the company to prove the employee was failing
The company doesn’t have to prove that the employee was failing. It’s perfectly legal for a company to fire an employee because they the employee likes the wrong football team.
The employee or people pursuing legal action on behalf of multiple employees has to prove that the company fires the employee(s) because they were a member of a protected class.
Assuming there are no incriminating emails stating that that was the reason, the only realistic way to do that is to show a pattern.
If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
> The company doesn’t have to prove that the employee was failing.
They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination. When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
> If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
>They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination.
They don't have to show anything. The employee has to prove that it's age discrimination.
>When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
Without a pattern of discrimination this isn't a problem. If there is pattern of discrimination then it is. However, if that's the case it doesn't matter how much documentation they have.
>It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
You can't discriminate arbitrarily. Discrimination in this context means firing someone because they are part of a protected class.
>gave the employee notice and a chance to improve the situation.
Whether you gave someone the chance to correct the situation or not isn't relevant.
>BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
"At the same time, FY2020 saw the lowest number of charges received from workers in more than two decades. The agency received 67,448 charges—continuing the steady downward trend since 2017 in the numbers of discrimination charges filed with the EEOC."
> The number of charges filed with the EEOC has gone down over the last 20 years
Yes that’s a compelling data point for decreasing legal actions (and it’s interesting, thanks for including it), but not all actions and not all fears end up in front of the EEOC, right? This data point alone is likely due to decreasing union membership over the last 20 years, but is also explained by the increasing prevalence of mandatory arbitration clauses. What it doesn’t explain is why HR departments nationwide are increasing efforts to educate employees about anti-harassment policies. If they are legally in the clear, why is that happening? Twenty or thirty years ago it was hardly a thing, today it’s the norm.
> They don’t have to show anything. The employee has to prove that it’s age discrimination.
You are right about the legal burden of proof in court, absolutely. Court isn’t the only possible outcome of a discrimination claim, though, and the one specific example you gave is a defense against a discrimination claim that would not hold up in court (firing a long-time employee for claiming to not like the right football team).
I agree with everything you’re saying about what is required in court, and what are the legal rights for all employers in the US, not just tech companies. That’s just not exactly what I was talking about.
I find attitudes towards risk in hiring very strange. Many companies seem to treat it like an opportunity for massive downside without much thought to the potential upside. I think the downside potential is mostly less than companies seem to worry (an argument against me is that a ‘bad’ employee negatively affects their teammates too). I also think the normal interview processes aren’t even very good at filtering out those feared candidates.
Instead I think companies, especially large companies where small numbers of employees aren’t a massive proportion of spending, should try to see the potential for upside more. Especially in a world where everyone does a similar interviewing process, a candidate who performs poorly at those interviews could be cheap and an excellent hire who is undervalued by the market because of their poor interviewing skills.
Salesforce have ever green roles which they casually do interviews for but never actually act on. The roles can be easily spotted as they’ll be posted and reposted on job boards like LinkedIn every 4 days.
I think this is a problem our whole society will have to learn. Reducing risk is probably good, but we have to reach the point where trying to eliminate is universally seen as a pathology. It's already kind of a meme in consumer products ("warning labels these days, right?"), but it crops up in hiring, movie production, etc.
This is actually true. A bad hire, once in the door, can be very expensive and time consuming for an employer to rectify. This is what leads to all sorts of weirdness like “contract to hire”.
Ah Amazon... 14 interviews, an additional 5 hour technical test, spanning a total of 3+ months. Only to be informed at the end that I was too technical for the role they had in mind but they were offering me a Senior Principal SDE role instead.
By the time we got to the end of the process I'd already concluded that the hiring process was a reflection of their internal decision making and that this was not a company (or department) I wanted to work for.
Then I was hired elsewhere and I saw something similar happen to a candidate and realised that this was truly an indication of the indecision. We had lots of roles, just none shaped in a way that fitted the person, and what we should've done is reject the person but on that occasion we hired and it was a terrible decision. They were a good person and very capable, but not a fit for the role finally offered. I had the sense that if I had accepted the Amazon role that would've been true for me too.
An interview process of more than 3-4 defined steps that takes longer than a month to schedule, is a bad sign.
Top tip for candidates: Ask what the process is, if they cannot conclusively tell you then double down on interviewing at a company that can.
Sr principal is like L8 so you’re easily taking close to 1M/year salary.. 14 interviews is still a bit much, but you’re basically one step away from distinguished engineer which is pretty much end of the road for the engineering track at amazon
I can't say on the money front I didn't kick myself after I had declined, and the interviewing was at a very high level. At the time I was focused on finding a role that had my requirements for high job satisfaction and money wasn't an important part of that (I'm not rich, but money wasn't important then and isn't now, we only have one life to live).
I've known a lot of far better engineers than I am. We've all been in this game a long time. Titles, companies and package aren't the most important thing to any of them. I'm sure most will look back and even though our titles and roles appear to have changed it feels like we still do much the same as we always did, just at a different scope and what's important is whether the work is engaging, there's as little politics as possible, and you're setup for success.
I honestly think this is a product of large corporations being essentially incapable of firing bad resources. Companies are terrified of litigation and bad PR so the only control mechanism is the interview process.
Why are companies afraid of litigation?
My understanding has been that, excluding discrimination on the basis of a few protected categories, sexual harassment retaliation, and whistle-blower protections, in the US private employers can fire non-union employees at any time without cause. (IANAL)
Are large companies really afraid of PR in firing individuals? If a company with many thousands of employees fires one person, outside of the C-level officers is that a news story? Even if disgruntled former employee tries to say anything disparaging, doesn't that immediately make them less credible as a source?
The more people who interview, the more average the candidate has to be to succeed.
For all the talk of "hire fast, fire fast" the reality is that most companies do not know how to evaluate someone within the probation time period in which they could let go of someone with ease (usually under 60 days) and after that they then fear doing so even when it's miserable for both the person (candidate) and team involved.
I hire a lot, and some of my thoughts on the process:
1. The interview process should be short and sweet. 3 steps is enough, if you can't make a decision in 3 steps then the decision is to decline.
2. The hiring manager should be the first to interview. We have a good idea of what we're looking for in a team and what other roles other managers have open, we can speak of most teams and can spare both the candidate and ICs from interviews that cannot realistically result in a hire. Likewise, we can increase the chance of a successful hire by having the people from the team the candidate would be joining conduct the interview.
3. Some of the best candidates get love/hate feedback, a candidate who consistently gets "hire" feedback is seldom as good as those who get "strong hire" mixed with "no hire" feedback. The consistent "hire" usually typifies an "on the fence but don't want to take responsibility for declining so will wave through"... opinions should be stronger, interviewers should be excited for people - challenge whether a consistent stream of "hire" feedback actually means "hire". All that said, always listen to "strong no hire" when it turns up.
4. To increase diversity you only need to interview people who aren't already over-represented in your org... you will hire those people at exactly the same rate as you hire everyone else. If you don't have these people in your pipeline you have a sourcing or branding/reputation problem so focus on those things. If you do have those people and aren't hiring at the same rate, you have a bias problem and should root it out with urgency.
5. Degrees are not a signal, so absence of a degree is not a signal.
6. Don't hire based on what someone has done as it only reflects what their employers asked them to do, instead hire on what they can potentially do - if it lines up with what you want to achieve it's a win-win.
Most of the above can be summed up as: Have an opinion and care about what you're doing.
> the probation time period in which they could let go of someone with ease (usually under 60 days)
Is this a thing? I would certainly judge a company doing this, and likely leave a manager who hired someone with an expectation that the beginning is just a probationary period, if I’m understanding you correctly (I hope i’m not).
Leaving a safe job for a probationary period puts too much risk on the employee that the employer doesn’t really share.
Some companies do "hire fast, fire fast"... so yes.
But I choose not to work for those companies, instead I prefer a strongly opinionated hiring process that won't play with anyone's life like that.
That said, treating probation as probation is definitely a thing. Especially in legal domains such as France and Germany. In the USA it's far less of a thing as employers can mostly let go of people at almost any time if they wish to and it's not a pattern of discrimination (though this is the fear of course, that a pattern could be formed).
This is not the case at Amazon. They are known for PIPing engineers. They’re not shy about it.
Also all of these big tech companies can just not refresh your stock if they don’t want to bother with firing you, which effectively halves your compensation.
What's GP? Gaussian process? General practitioner? Or, most commonly on HN, grandparent [post]? Or maybe the whole point of using that abbreviation is to exclude those outside Amazon?
On my team, I inherited an interview process with 7 steps. It's a long one for sure, and it's not a process I can change. But as a hiring manager I mitigate issues brought up in this article by doing a few really easy things:
1. On my first chat with a candidate, I layout the entire interview process. I acknowledge that it is long and I preemptively thank them for going through the process and say that we value their time. I make sure our recruiters can reiterate the process as clearly as I can.
2. I let the candidate know that at any time if they want to pull out, that is a-ok, and that they are welcome to apply again in the future in good standing. I also tell them that during our coding assignment, we really mean it when we say it's ok to ask for more time, and that we don't judge them negatively.
3. I tell the candidate that if at any point we decide to decline, that I will send them a written letter of feedback so as to make the process worth their time. This isn't always easy, but it's always been appreciated. Sometimes it is hard to write these letters, how do you tell someone multiple interviewers didn't like them? I do it by pressing our interviewers to state clearly what didn't come across well, and then I relay those things to the candidate. Sometimes even still the letters probably aren't super satisfying to the declined candidates, but I do my best and hope everyone realizes that job hunting in general is rarely satisfying.
Basically, transparency, honesty and specifically thanking them have gone a long way for me. I fully understand that an underfunded/understaffed startup might balk at the feedback part, especially when lawyers can get involved. But offering up items #1 and #2 to candidates should just be table stakes of your hiring process.
I liked that. I was a manager for 25 years. I think I did OK with my decisions (for the most part).
One thing that I noticed at my company:
When I first got hired (in 1990), it was made clear that I was a desired and valued employee. They were a very picky company, and might well have rejected me, but I felt respected and valued, from my first interview (I was flown out to the West Coast, and interviewed by two managers at a trade show).
As the years have gone by, I noticed that our HR department started to have a very different posture. They had to be the ones in charge. Applicants were supplicants. The company was doing them a favor, by considering them for this position.
Also, the HR department started to project this attitude to current employees, to a visibly increasing degree, over the 27 years that I was at that company. By the time I left, the HR posture was that employees were little more than serfs. There was no illusion that employment was a two-way relationship. They started to impose some really draconian policies on employees, with "termination of employment" as the only choice, if the new policy was not acceptable. No negotiations.
I think that this is an attitude that has become a standard in HR, these days, and that part of the reason for this interview process, is to filter for people that won't talk back to HR, and are willing to abase themselves for the company.
I like your approach and I think it really makes the process much better. However, this one thing stands out to me:
> I acknowledge that it is long [...] and say that we value their time.
I dislike this communication style. Maybe it's a cultural difference. I've heard several times from an American speaker that they "value my time/comfort/satisfaction". At the same time their act clearly showed that they valued something else much more.
For me, your sentence would sound much more personal if you just omitted this last part and kept only the explanation.
I'll keep that in mind. My original comment didn't quite clarify, but when I say those things I make an effort to not come across as insincere or like I'm reading a canned statement. Also, I try and clearly say what I value-- which is both of us learning more about each other and figuring out if them joining us is a good fit. And I encourage them to assess if we're a good fit for them too. I often talk to candidates before making an offer about the trade-offs of taking our role over roles at differently-sized companies.
Nice, I like the way you think about it. And take my comment with a grain of salt, please. It's impossible to judge the full context over an internet discussion with a stranger. :-)
Just a rejection letter is something, and in a reasonable amount of time. Many times I would just hear nothing. No response at all. Just a simple 'no thank you' is better than what many get from most companies. It is amazing how many companies do not do this one thing. They just leave people hanging. I had one dude who thought to finally send a 'no' letter. It was 2 years later. That should have been closed out ages ago.
Thank you for doing that sort of thing. It really helps.
I'd really appreciate a letter with feedback after a lengthy interviewing process, I think that's really valuable.
However, I don't think I'd value it after more than 3 interviews. Candidates are applying after work hours and there's a time / energy limit to how many processes they can take at a time. After a given point, you're wasting not hours but possibly months of their life.
That's a fair concern. We really try and avoid advancing anyone when we suspect might be rejected in the middle or end of our process. It has only happened once since I've been here. Again though, I have to lean back on that everyone should be aware that job hunting isn't an ideal process. Occasionally someone can really ace one part of an interview and really not be a fit in a different part. It's unfortunate when it happens, and that's when I lean on my principles of offering constructive feedback.
I didn't really realise it until I was on the other end, but if you don't get any feedback you can totally ask for it and there's a decent chance you'll get some.
But I agree, it's usually pretty obvious if you just weren't good enough, or you had a bad day, or they just didn't like you for some random reason.
Any response is better than nothing and it is sad that is the line to be above. But I know I appreciate letters actually explaining why I was declined, if they are informative it can actually be helpful for me to improve.
Especially if there is an assignment with the interviews I really think that feedback should be required. I spent about a week on an assignment like this with 3 interviews and just got back a "nope, sorry". And it wasn't even from anyone I had interviewed with, just the original recruiter.
If your application process starts with a human being—even better a technical human being—reaching out to me, followed by 2-3 interviews, followed by an offer, I am already on your side. If your application process starts with a HackerRank, followed by 2 phone interviews followed by on-site, followed by team matching, I will not be on your side. Oh and if there's random month long gaps in between stages, I will especially be uninterested.
I've noticed though that as I've gotten more specialized to compilers and programming languages, my application experience has improved significantly. It's not a large sample size but the last few processes I've gone through have been fewer interviews that usually involve going over a project of mine or doing a problem that's related to compilers. It's really refreshing to have an interview where I actually learn something about my field of interest during it. I know that doesn't scale because we shouldn't expect compilers knowledge for junior compilers jobs but it's a very nice change of pace for me.
Is HackerRank so bad? If one does "whiteboard problems", HackerRank says, "boo, whiteboard interviews, just let me code and be able to search on Google, whiteboard is unrealistic!". Now if the company starts with a HackerRank test, that's also bad? I don't get it.
Look, a lot of people have good-looking CVs and can't code shit. I don't know about you but my experience was that one really can't hire based on CV alone. Also, I've seen "architects" that are smart and fairly knowledgeable people that failed to code very very basic stuff (as in, merge 2 sorted arrays).... I get it that at some companies you are expected to draw diagrams in Confluence as a main job, and might no longer have actual coding skills; but we want even the most senior people to actually code, and that doesn't seem unreasonable to me. So just because you're a very-senior FAANG employee doesn't automatically mean you'd be a good fit. I'm not saying they're bad employees, but maybe they just wouldn't be a good fit and wouldn't enjoy the job if they expect to just design stuff instead of actually implementing, too.
The main problem with some of these things is that:
1) you're expected to spend 3 or 4 hours on some HackerRank test before you've even spoken to anyone. Some of these tests (outside HackerRank) can actually be projects that take a day or more to get right. The issue is that at this point I don't know if the attitude is "hey, this seems like it might be a good hire, let's check if he can actually code" or if it's "let's send anyone this test and discard anyone who doesn't pass". I suspect that in a lot of cases it's the latter. I'm not opposed to investing time, but it quickly becomes unmanageable if everyone just asks you to pass their several-hour tests just to be considered for application. There is very little time investment from the company, and it feels almost like a dDoS attack on my time.
and 2), that a lot of these tests are asking you to solve some hard problem that you will rarely face in real life and where people have quite literally won Turing awards for finding solutions to them. Many previous discussions about this on HN in the past.
I don't think it's even all that much more effective at actually weeding out bad programmers than a simple test. We used to ask people to write a CSV address book importer with some very basic requirements; nothing fancy, you could do it in 30 minutes. It worked well enough, and a lot of the results we got back were horrible.
HackerRank isn't inherently bad. It's actually pretty good. It's that receiving a 1-2 hour automated algo contest to every job application is bad.
If I applied to 10 companies, and every single one of them asked me to come onsite for whiteboarding as the first step, that would also suck tremendously, but at least it would be limited in scope by the employer's time as well. As it stands, arbitrary companies can expect a large time investment without any of their staff ever having to speak to anyone.
I'll take a calculated stab at Amazon's once every 6 months I guess, because if I pass (which I haven't) I can potentially earn a hell of a lot more than any other place. I get it, whatever. If every company is doing it (they are)? I might just leave the industry if I can't find a way to be specifically good at remembering the implementation details of every data structure and algorithm. Sucks to be someone with pointless skills I guess.
A lot of the issue with HackerRank is just how early it is in the process. I don't object to it. But there companies out there that just have every applicant do it indiscriminately.
I agree it's subjective. Some people may prefer HackerRanks because it lets them do the work on their own time without someone watching them. For me, HackerRank problems almost always have nothing to do with my work, require passing an arbitrary test suite, and provide the interviewer with no insight into my problem solving ability. Who would you rather hire, someone who reasoned through the solution on their own, then dropped a hidden test case, or someone who saw this question before and just rote wrote it from memory? Perhaps both, but HackerRank won't give the former a chance.
Besides, if someone is duplicitous enough to have a good looking CV and no coding ability, what's stopping them from just cheating on the HackerRank?
TBH that's another argument I don't really get. Almost everyone agrees that basic CS knowledge trumps specific technology knowledge (I'd rather hire someone with strong CS fundamentals that didn't use Java before than someone who is a "Spring Boot expert" but lacks basic CS knowledge, even if I actually use Spring Boot right now).
But then, why complain that you don't do that in your work? Surely you need to traverse data structures from time to time, yeah it won't be the exotic tree traversal that I'd ask you to write but that's exactly the point - to test that you can be put in a novel situation that can't be directly-pasted from StackOverflow and you're able to write a recursive function that takes _a little bit_ of skill).
The hidden test case is opportunity for discussion during actual interview. And this answers your "what's stopping them" question, too - regardless of problem, I can tweak the input slightly so that your solution doesn't work - and more often than not, I don't even tweak the input, I just provide an additional testcase where your solution doesn't work. If you can quickly fix it ("oh, yeah, I forgot that URLs may have a fragment appended to it, let me quickly adjust my log-parsing condition") then it's awesome, it's exactly the signal I'm looking for, and we can go on to discuss system design and your relevant experience (but honestly, at that point my mind is likely ~80% made up, from CV + how you explain/modify your hackerrank solution).
If there are teams interviewing candidates that are surprised to find that some applicants can't write basic code, then there must also be candidates that are surprised by that as well.
The longer a candidate has worked on very capable teams the more surprised they will be to have those problems presented in a job interview.
You assume the interviewer is ideal: infinitely competent, infinitely great at judging other engineers' skills etc. This is practically never the case.
I am not one for LC type of problems, but at the least I have to admit they have the potential of being more objective than everything else during the interview process. You get the specs, you write the code and it gets tested via multiple test cases. It does not matter if the interviewer agrees your solution will work or not, and the interviewer won't have to copy&paste your code, compile and run it (like someone else mentioned in this thread).
On the other hand, what I particularly dislike about the LC problems is that many of them are essentially trick questions and brain teasers. Can't we just stick to problems that are relevant to an SWE?
I agree actually, I've had a similar experience except in the mobile engineering space.
Currently I'm going through the interview process with a ton of companies (because my company is really dumb and is forcing everyone to move back to a certain bay area city post-covid), and I have been happily surprised to find that most of my interviews are very practical, project based, ones instead of straight whiteboarding leetcode problems. I've received several take-home projects that are followed up with a simple add-on interview to sit down and explain the choices made during the take-home. They have all been specifically focused on domain knowledge to the mobile platform that I'm interviewing for. Its really nice! I hope this trend continues.
That said, I am still reviewing leetcode problems for the stupid faang interviews I have coming up as well.
I just went through this with a company. They sent me a generic packet with 3 projects to choose from. With a simple Google search I was able to find all of the answers to all 3 sample projects implemented in different languages.
This was after a 10 minute conversation with the company's recruiter. To top it off, nothing in the job listing said anything about software. Just Cloud and Devops management role.
I am absolutely ok with take home or some presentation of my skills. However, I expect to know that I am being taken seriously as a candidate by that point. I don't want to waste my time on something with no investment from the company.
As you can guess, I bowed out of the running explaining that I didn't think it was appropriate for me to give them so much of my time with no commitment from their end. I also told them I could tell their take home project took them less than 5 minutes to generate for me as it was everywhere on the internet. How can I trust a process where the answers to the interview are everywhere? How can they really know my skills as a candidate if I can just steal the answers off of GitHub? Worse, how can I know how I will stack up to someone who might be less scrupulous than I and steal those answers when I tried in earnest and actually burned an afternoon trying to solve their test?
Agree totally. I recently accepted a position where an officer reached out to me, followed by a really great discussion with them. A call with two engineers and a team call later, I was offered, and we were all confident it was a great fit. The interested was consistently maintained on all sides evenly and communication was fluid. Great experience.
I applied to a company recently whose first interview was a tech test. I turned them down before I even spoke to a human. I don't want to work for any company that puts so little value on people.
Honestly, I understand the whole send the tech test first. Having wasted time on talking to people who clearly weren't able to do the job I would rather waste their time than mines. For me, it's when I talk to their developers and it's clear they know I know what I'm talking about and they then try to tech test me. At that point, no. I just impressed the hell out of some of the people you consider to be your best and you think I can't code? Nah.
The tech test seems often like it's cargo cult. It's on Joel's list so everyone thinks it is a must do. Instead of realising that the entire point of the tech test was to make sure people could actually code. With some of the original tech tests being do FizzBuzz or do something really simple in a short amount of time. Not, build me a production ready toy project using techincal DDD aspects.
Having wasted time on talking to people who clearly weren't able to do the job I would rather waste their time than mines.
Of course. But consider how that attitude looks from the perspective of a candidate - you'd rather waste my time that yours is a really good reason for me to drop out of the interview process.
This is essentially what's wrong with hiring right now. Companies don't want to have anyone "waste their time", so they have many levels of filtering to reject candidates as early as possible while doing as little work as possible to make hiring good for candidates. In other words, companies have largely forgotten that candidates are people, and wasting anyone's time is a pretty bad idea.
Well, being the candidate I would rather they did a tech test first than talk to me and then do a tech test. Actually, if someone technical has spoken to me and then they ask me to do a tech test. I'm very likely to say no because they've already got a feel for my abilities and that is the point of a tech test.
I think sometimes people forget people working at these companies are people too and noone wants to have their time wasted. This isn't companies deciding these things. It's people. It's the person on the otherside that doesn't want their time wasted.
To be honest, I think I'd agree with you if job adverts included all the information necessary. Doing a tech test for a job when you don't even know the salary range, or what the role consists of, or what the company really even does ... that's what annoys me. If companies wrote transparent, clear job adverts I'd be a lot happier with their interview processes.
compilers are 101 of CS with coding a major part of compiler being just a course project. Honestly, one of the most straightforward and simple things in the industry. At one of my previous jobs several senior undergrads (beside fresh grads which were frequently hired) were hired full-time to work on a major compiler suite. A nearby company doing a lesser known kind of bit more narrow specialized compiler suite were hiring even more of senior undergrads and fresh grads.
I recently agreed to go through a 5-round process which totaled to about 6 hours. I'm the first person to bitch about the ineffectiveness of leetcode/hackerrank bullshit for people with 10+ of verifiable experience, but I went through this one because it was a field I had never worked in before, and the personnel I was speaking with were truly interesting.
Sans all of those qualifiers, anything more than 3 rounds is a deal breaker for me. If you don't know if I'm the right fit after 3 hours, verifiable experience, a public body of work, and a list of references, then your company culture isn't a good fit for me.
It's interesting to hear of these experiences because my own job applications have usually taken four steps:
* See the advert online, and send an email/fill out a form to apply.
* Have a quick phone-chat with a HR-person, where they ask about salary, history, and try to decide if I'm a chancer, or I have some somewhat useful skills.
* Have a 30-60 minute interview with some technical people, in-person.
* Optionally have a second interview with a tech-lead, or somebody else higher up the chain.
* Receive offer, rejection, or get ghosted.
Smaller companies sometimes have different processes. More than once I've sent an email/CV in to apply and been invited out for beer/food, and received a verbal offer the following morning. No other interviews, or tests.
I do research assistant work in biology. The best way to get one of these rare jobs is to email the professor directly. They then have a "chat" with you (don't be fooled, this is the formal interview!) and then several weeks later they get around to bypassing the Uni's hiring process and you get a job.
I really am not looking forward to going through a formal interview process, because it will be so jarring compared to what I am used to!
Fwiw I also work in molecular biology and did a recent round of interviews (summer 2020).
Started with applications over a web form on the university careers website, then chatted over email with the hiring manager. Eventually got set up with some interviews with current lab people, and eventually the PI.
Mirrored in industry, although that was back in 2018. So all in all the “regular” route at least for this level of work in biotech/biology is pretty sane.
That being said, I’ve used your method in the past as well to great success, and is one of my secret techniques to get more traction when I’m looking ;)
Thought your comment was interesting, so went to check out your profile.
That was also clean and well made, so followed through to your website.
Found this:
"I published a simple tool to all your repository details from Github, self-hosted Github Enterprise installations, and other compatible systems."
Do you mean:
...to [pull] all your repository details
Since you have such a nice profile and everything I thought maybe you intended to include this word in there.
Hope this is helpful.
Somewhat related to interviewing and getting hired.
If it's in an appropriate comment for this threat then please remove it. @admin
Yes, same for me. I was going through my past interviews, and the most I’ve had before an offer has been two, both scheduled on the same day. And I’ve worked in agencies and big orgs, in both private and public sector. Maybe we’ve just been lucky?
I wonder if this is a way to crowd out competitors. Take up so much of a candidate's time that they can only interview at a handful of places successfully. Either the candidate goes all in on you or they pass without using your resources. Kinda the grocery store shelving model of competition.
And it’s to weed out people who value their own time and who won’t take part in pointless company mandated bullshit.
If someone sits though 6 hours of interviews and pointless exercises that should instead be solved by consulting the documentation, they will probably just do what they are told without fuss, will work overtime for free and will let the company walk all over them with regards to sick pay, holidays, etc.
Every bad hire costs the company $50,000 - 200,000. Sometimes more. They can also sink or demoralize teams.
Many of the people conducting interviews are new to the process and don't know how to extract signal. Sometimes scales don't line up.
When you have a revolving door of employees (because that's the way things are these days), have trouble scheduling interviews (busy engineers trying to get their own work done), and can't get enough skilled interviewers on a panel, then of course the process will be a suboptimal experience for candidates.
To a degree, companies would rather a good candidate was passed over than a bad candidate was accepted. Type I and II errors.
Companies also don't like telling candidates how they did because that opens them up to lawsuit liabilities.
You have to do enough interviews to get signal yet not piss off candidates. (Or your employees in the interview pool!)
This is mostly management speak for: don't blame us, we're just incompetent.
If you run a company and you have a "revolving door of employees" (ie: we can't retain talent), your managers "are new to the process" and don't know what they're looking for (ie: we hire inexperienced managers), and you "can't get enough skilled interviewers on a panel" (ie: "we don't hire enough engineers and we're too cheap and shortsighted to put them on tasks like hiring")... then yeah, you should expect your hiring costs to go up, have a revolving door of employees (because you don't know how to hire), and your teams to be demoralized.
The consequences of that are your (company's) fault. You should own up to your shortcomings and work on your hiring process... don't just punish the candidates indefinitely so that you can ignore your problems.
(I say this as a serial founder, and hopefully never need to be on the other end of the hiring process.)
A lot of IT positions at Universities. To the point where it can be a problem as in a Junior Position, it can be really hard to be promoted internally unless someone decides to leave, which they rarely do because people in Senior level Uni positions get good pay and they tend to be very chill environments.
Why is nothing done about this? As turnover soars and tenure plummets, I am willing to buy that companies do not value codebase knowledge, domain knowledge, or believe that it takes time for an engineer to get going. I can buy them seeing us engineers as replaceable widgets.
But we are at the point where a lot of companies cannot replace us and yet nothing is done about the endless parade out the door. The focus is entirely on shovelling new people in.
I think most engineers overestimate their irreplaceability. If a company actually wants you to stay, they'll fight for you. They just choose not to for >90% of engineers leaving.
Chances are, the new hire replacements will be in the same 90%, so it is a wash (minus ramp-up time), but maybe the company gets lucky and finds someone in the other 10%.
I get them being replaceable, but there must be companies would be getting to the point where there aren't replacements, or at least not good ones as the demand for engineers grows.
Yes, every bad hire is really bad. However, companies generally don't put in any effort into seriously evaluating your publicly available work. I have reams and reams of open source code companies can take a look at, and I've never seen any evidence that any company I've ever interviewed at has looked at that work. That's a result of companies being completely incompetent at evaluation and disrespecting their candidates time. Its wasteful and stupid. Its honestly flabbergasting how many companies don't put in the effort to make their hiring process passible, much less anything near "good".
Well the obvious issue here is...how do they truly know you wrote the code? Its pretty much impossible to source where OS code comes from, and it sure wouldn't be hard to find an obscure OS project and pass off the code as yours, if you were that sort of person.
And this takes me to my 2nd point, and that is they current hiring model totally leads to companies hiring people who are good at interviewing not necessarily people who are good at doing the work required. There is no doubt t that interviewing for a job is a skill that can be learned and improved upon, and lots of crappy programmers have learned to be damn good at being I interviewed.
If a person has a history of giving talks, writing books, or creating content around code they've written there's probably a high likely hood they are capable workers and can code.
Being on the hiring end, it’s less out of incompetence and more of not enough time, and open source code is low signal that the candidate can actually solve problems.
If I submit some “open source” code as some proof that I can code, how do you know I didn’t copy the code from somewhere?
Also, writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process. It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
Writing code can be a hobby, sure, but that’s only a small part of a software job and no amount of open source code can tell a company if the candidate can work with others and solve problems.
> no amount of open source code can tell a company if the candidate can work with others and solve problems.
Balderdash.
When was the last time an interview task involved working with others? I'd offer that open source PRs show this way better, and in an appropriate context (as a collaborator) rather than what we have now: adversarial interview{er,ee}s.
I agree on your open source comments as far as, the only open sourced code a person has is personal pet projects. However, if you see someone has PRs and commits into something like the Linux repository or a major well known project, then their open source contributions could be very meaningful. As an example. If you are hiring for a position for a developer to work on garage band at Apple, if an applicant is an audio dev for FreeBSD, that is a pretty good sign the candidate knows what they are doing.
> how do you know I didn’t copy the code from somewhere?
You can ask your candidate to explain the code... Is that not obvious?
> writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process
Kind of sounds like you don't know what open source software is.
> excuse my language, shit out code for the sake of appearing productive
I won't excuse your language. You sound like you're part of the problem buddy. I don't think you have any idea how to evaluate a programmer.
> You can ask your candidate to explain the code... Is that not obvious?
Asking about projects is the obvious thing, but only substantial and interesting projects really provide any interview value. Yet another Todo app doesn’t fit that criteria. Neither is another scaffolded crud app.
A PR to fix a bug in a semi-popular library is worth. But saying “I have a lot of repos” is def not.
I don't know why you're assuming my or most good programmers' githubs are filled up with todo apps and other worthless garbage.
> saying “I have a lot of repos” is def not.
When did I say that? I didn't. They should be looking at the repos and asking about them, not just taking your number of repos and using that as some kind of metric.
> It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
It sounds like you have a serious misunderstanding of open source at a basic level. It would have been questionable enough in 2000 but I’m not sure why anyone in 2021 would think that way.
I’d argue the other way - open source in 2000s to central libraries were of decent quality. The quantity of code now these days is so much and of questionable quality - everyone and their bootcamp writes code to GitHub and call it open source, just to show they have open source.
Hell, I have public code on GitHub, but I’d never put it on my resume.
There may be a signal-to-noise problem, but the amount of useful open source projects and the extent to which we rely upon them has only increased in the past 20 years. “Open source” includes projects like Go and NodeJS, which are hardly trivial, disposable projects like you’re referring to. Pretty much all crypto is open source and people have invested tens of billions in that ecosystem. I could continue and list at least half a dozen projects that are considered critical infrastructure which are developed in that fashion.
They least they could do is let you know up front what the interview process is going to be like. From what I've seen the candidate often has no idea if the second interview is the final interview or just the next in a long series. And I've even seen employers wait weeks befor calling back to inform the candidate they qualify for a third interview.
And if you have a revolving door of workers, that suggests something else is wrong. Maybe you should focus on retaining existing workers rather than acquiring new ones.
If someone is new to the interviewing process, then they shouldn't be doing interviews alone. If they don't know how to gather information from a resume, then they shouldn't be reading resumes alone.
You say that a bad hire is worth tens of thousands of dollars, but if that's the case, then most of what you said is irrelevant because a company that is smart enough to recognize this would be smart enough to never put a junior manager in a situation to make a terrible decision.
So they can learn from experienced interviewers who just make you leetcode and answer dumb stock questions (my biggest weakness is…)? What we need is for people to interview with zero experience and figure out a better way on their own, not copy a bunch of bad processes out of insecurity
If you've surrounded yourself with incompetent people, then you still shouldn't assume that everyone else is equally incompetent. Cynicism isn't wisdom.
It's either important and expensive or it isn't. I wouldn't be "shocked" by anything. I used to be a recruiter. In my current dev position, I have absolutely nuked candidates by asking basic questions that the managers (who were eager to hire someone to fill a spot) and other devs (who would feel uncomfortable if they asked the question and hence didn't) failed to ask. A candidate who will try to bullshit me about something he doesn't actually know is someone who will waste time on projects by not using all the resources available to him to find the correct solution (this usually involves being brave enough to ask questions if you don't understand something). If my future depends on your success, then I'm going to ask questions that will make me feel like I can trust my future in your hands.
If a manager is getting paid $150K a year and it costs $200K to fire a bad employee, then "when they're ready" is the correct metric to use.
Your response is the voice of the company. The person you're responding to, and lots of candidates, don't really care about the voice of the company. From a company's perspective, sure waste all the time you want, you want to be _sure_. But to candidates, getting dragged around sucks, and is usually a waste
I’d like to add time aspect as well. If selected, candidate will spend next 12-18 months with the team, 5 days a week. I look at those 5-6 hrs as worth an upfront investment from both the sides just ensure those days months aren’t miserable and you don’t end up parting ways on bad terms.
I’m saying this as an interviewee as well as hiring manager who has conducted more than a thousand interviews.
Nothing frustrates a team and hiring manager more than a mishire. It’s the same for candidate, they have to go through the charade of interviewing at tens of places again.
The lower end of that, and honestly, the higher end, is just about complete rounding error to any FAANGM+ caliber company.
I have seen a fairly small amount of employees hit the lower end on a singular dining bill when they had a company card and were meeting with business partners they were trying to "impress"
(obviously, the joke is free nice food and drink for all involved at the companies expense)
If you were fickle you could perhaps justify that as priced in to keeping good relations... but in the same light I'd call your figures priced into the talent acquisition process.
If you go to an interview, you can probably suss out which are stringing you along and which want to hire quickly. Ask if they need a candidate immediately or are taking their time. Ask if your qualifications are exactly what they're looking for, and if you feel like a cultural fit for them. Ask if they have the budget and headcount to hire you immediately. Ask which teams the people interviewing you are on, to find out if they are all in different teams/departments or the same. Ask if each interviewer even knows who the the previous interviewer is in the company ("Frank who?"). Ask if they know exactly what they want you to work on. Follow up periodically to see if they are responding to you in a timely manner.
It's common for there to be some uncertainty with one or two of these things, but if there's a lot of uncertainty, you are being strung along. Best case they are waiting you out trying to find a better candidate, worst case they don't even have the budget for you and are playing politics within their company using you as leverage.
Interview multiple places in parallel, and don't cancel any interviews until you've got a signed piece of paper. But of course, prioritize the ones that aren't jerking your chain.
I am actually going through the hiring process now. I was a hiring manager at my last shop and I tried to be very respectful of the candidates time.
The process was first interview was 30 mins and basically a getting to know you and us session. Second interview was a two hour technical interview with debugging/fix this function type question and a single from scratch example question in the candidates language of choice. The final round was purely optional if the CTO or CEO wanted to meet the candidate (they rarely did).
If you made it through all that you got an offer. Of all the candidates I hired only 1 didn't work out long term.
Now that I am on the other end, I don't understand the need for this overly complex and generally noncommittal (on the employer side) process. If it's FAANG I am lucky if I can even get a fucking job description these days. They want to interview me for jobs I can't know about and best fit me for their needs. What about my needs? What about my time? If I can't even get a job description, why do you think I want to waste 3 hours doing "homework" before I can even talk to anyone for more than 10 minutes about what possible job I could be actually doing for you?
Hiring in Tech is broken and I don't know what we can do to fix it.
The FAANG's are throwing around so much money that people are willing to put up with almost any amount of abuse to be on the other side of the line. The FAANGs can deal out any amount of abuse and they will still have a line of applicants around the block--there is no negative feedback in the interview process no matter how bad they make it.
> Hiring in Tech is broken and I don't know what we can do to fix it.
Software hiring in the Valley is broken--possibly.
Hardware folks I know still go through the same old, same old. Single phone call with an engineer to make sure you're not simply a waste of oxygen. One on-site with 4-6 people (and 6 would be an unusually long day--generally that would mean you're doing well and some extra people want to talk to you). One week to response--two weeks MAX.
I've interviewed for ME, EE, FW, and SW roles. It's not better in hardware. There's an equivalent to all the things people are complaining about here. Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software. I got a FW challenge once that assumed I had two different dev boards on hand. Spot the bugs in this printed out code? Find everything wrong with this schematic in 5 minutes. Now quick what's the transfer function of this filter? I have a dozen more questions to get through.
I had an ME friend who got into an argument with an interviewer about the convection equation. The interviewer was completely wrong, eventually my friend admitted "Ok I literally have it pulled up on my screen right now, I think you're mistaken."
> Spot the bugs in this printed out code? Find everything wrong with this schematic in 5 minutes.
I don't consider those terribly unfair. Depending upon how the discussion goes, I could see myself doing something like this.
For example, one of my standard questions for firmware people is a state machine in Verilog (for those who claim to know Verilog). What I'm looking for is whether you know the difference between blocking and non-blocking assignment.
> Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software.
> I have a dozen more questions to get through.
These are not fine, though.
> The interviewer was completely wrong
This, sadly, happens. I have had an interviewer cite incorrect information about semiconductor device physics.
Quite often, though, it happens in more junior interviewers with "standard" questions that are passed around because the interviewer doesn't fully grasp the question. When I was a junior engineer, I was always terrified that I would make that screwup. I used to do review study on my own questions and area before every interview to make sure that didn't happen.
For example, I had an interviewer who gave me a question of "clock a binary number in serially and use a state machine to divide it by 3." It's a really cool question and was passed around between engineers of a certain company. But ...
This is either a really easy question or a really hard question depending upon your choice of direction to clock the number in. If you pick the easy way, it's something like 3 states and it's obvious. If you pick the hard way, it's 6 states and takes a somewhat subtle inductive proof to show that you're right. If the interviewer doesn't know that this can happen, he can't dig the candidate out if they pick the hard direction.
Of course, you know which direction I picked in the interview. LOL.
I have no problem with spotting schematic issues (or spotting code issues) given appropriate time to do it. I actually prefer these to rushed questions where you have to implement the solution because it lets me get into the design considerations without spending time drawing symbols or stumbling through syntax.
Last time I got that question it was a schematic large enough that I would have put it on multiple pages and I only had a few minutes to get through it, which was a problem. Brought it up because it seems to be a touch point for others.
I think it stems from the fact that software is "soft" i.e. highly malleable and flexible. This improves time-to-market considerably and there is an inherent expectation built-in to "move"/"execute" quickly.
This also creates problems. Now the same thing can be done in multiple ways. There is a "my-company" way of doing. There is "my-way" of doing. Throw in personal tastes, likes-dislikes for testing, syntax, editors to name a few. Over the time, people take on multiple identities (e.g. FAANG, language fraternities, clubs of certain technology, editor fraternities etc). These mix and match in at best interesting ways and at worst in toxic ways.
I think we can teach people how to hire. The way I would do it is three-part:
1. An exam. You literally take a test. This mostly takes care of the technical portion, evaluates your cognitive skills, IQ, EQ, whatever. The idea is to get a general idea of what you "know" and gives some baseline reference numbers. You could also do a "coding test" as part of the exam, but I would not lean too heavily on those as they are subjective too. You would need to look at the results to see where they were strong/weak, as for some roles it's fine to be weak one place and strong another.
2. A veteran/senior (or two) interviews the candidate, asking deep questions to probe into the person's actual experience - because experience is 1000% more important than "what you know". The way I do this is a "binary search" of questions both simple and very specific, and based on responses I get more general or more specific. I can very quickly discover how much real-world experience the person has this way.
3. An interview with the team. This is actually for the team, not the candidate. The team can see whether the candidate is a mesh for their particular culture. It's just as important that the candidate fits the team as whether they're capable of "performing".
Within this system, you wouldn't ever do more than 5 rounds (3 on average), you get a mix of "impartial facts" (the exam) and "gut feeling", and you still have the human factor both evaluating the person's experience/responses and checking for culture fit.
> If it's FAANG I am lucky if I can even get a fucking job description these days. They want to interview me for jobs and best fit me for their needs. What about my needs? What about my time? If I can't even get a job description, why do you think I want to waste 3 hours doing "homework" before I can even talk to anyone for more than 10 minutes?
Why don't you find people working on a problem you like, then ask them if they have open positions?
Working though engineers is almost always better than filtering though company recruiters. You'll wind up with a role you like rather than being stuffed into open head count.
> Why don't you find people working on a problem you like, then ask them if they have open positions?
That's not always straight forward. Once you get patched over to HR, it's their process.
I am glad to hear that this is still working for you, hopefully a serendipitous moment will occur soon to open a door for me as well.
> Working though engineers is almost always better than filtering though company recruiters.
Doesn't this say something about hiring being broken when you have to dig through profiles on a company website or linkedin and cold contact devs to get your foot in the door?
I am by no means suggesting that what you are saying is a bad idea, just that this reeks of poor and inefficient hiring policies.
I don't mind going through a single day with many rounds, but when it's spread out it's super frustrating. It feels really disrespectful of my time. I interviewed at Apple and had like 3 onsites with different teams all in one week and got the results quite quickly. It was such a good experience compared to some companies where it's such a chore.
I also think the attitude of companies during interviews really sucks. Many feel like they're doing you a favor or you're wasting their time. That was a distinct feeling I got when interviewing at Google, but not at Apple and I really think it's why I passed those and not google. They were collaborative and fun at Apple. I put a lot of effort into making candidates at my company feel welcomed and like they are already part of the team and IMO it really helps them succeed.
I once applied for a job at an oil trading hedge fund in London. The company was small, and everyone who worked there became a partner in the firm once they joined. There were about 23 people there IIRC. I did a 1 hour interview with one guy, a bit technical, a bit of random trivia. Then another guy, similar thing. Then the third guy.
After that I asked how many more interviews I should expect. To my horror the answer I got was "we only hire people if all the partners agree to hire you, we all have veto power, so you should expect to see everyone"... so TWENTY more interviews. I rather abruptly told the guy that was insane and I didn't have time for that, shook his hand and walked out. He seemed perplexed.
It can get very demoralising as an interviewer when you interview dozens of candidates, and none meet the bar - and even the ones you rate hire or leaning hire get rejected by the hiring committee. When I first started interviewing (at Google) I was like the Apple interviewers you admire, but I have slowly become inured the process and now I probably give candidates the impression that I've seen it all before and I would rather be doing something else - because it's true.
But the alternative is more filtering before the main round of interviews, to increase the base success rate of candidates, which many people hate (see many other comment threads on this post). And too much would turn off the best candidates probably more than the worse candidates, as they have more outside options.
Part of the problem is that Manton the interview panel do feel like they're wasting their time. It is valuable to the company but for the engineers, they want to get back to coding or whatever else they are working on.
It isn't fair to the person applying because they didn't pick the people on the panel, but if the one doing the interviewing doesn't hide their feeling it's obviously not great.
That's true. I want to say that that's Google's fault right? Because not everybody is on the team you're interviewing for (I might be wrong)? At Apple you are interviewed by the team, who presumably needs another person to assist them.
Also, regardless of whether or not they want to be there, it's a bad look for the company. Somebody took a day off to talk to you, it's only fair that an interviewer reciprocates
Can confirm everything you said is true and that at Google you'll likely never see your interviewers once you start working there but at Apple you'll be working with your interviewers on a daily basis.
It has upsides and downsides, like as you said you had to go through 3 different on-sites (one for each team), but you'll get a good sense of the team before getting an offer (and they'll get a good sense of you). I like the Apple method much better but I had an unusually bad Google interview process so it's possible other people had better experiences.
> at Google you'll likely never see your interviewers once you start working there
Can confirm that this is largely true, with an asterisk.
The interview panel (for SWE candidates) is indeed drawn at random, but it's becoming more and more common to conduct fit interviews for specific roles. This is usually done by the hiring manager, in rare cases also involving other people (e.g. the tech lead).
The good thing about interviewing with your teammates is they will be invested in making it success if they recommended you. If you never see the interviewer again then they have no skin in the game.
Some of the difficulty is that the team may be hiring people because they're currently under-staffed. I've been on teams before where we're 3 engineers on a team that we're trying to hire up to 6 people. It's really hard to both try to keep up the work of 2 people, even in maintenance, and spend hours every week on trying to hire the replacements. Even if the company is good about reducing demands for new work after a departure, it's generally true that you're hiring BECAUSE you need more people on the team, which often means that team is overworked already.
I work at Big Ass Corporation, Inc. in the US (there’s a very strong chance you use one or more of our services). Hiring is fucking awful. First of all it’s nearly impossible to get approval for a req in the first place. I’m actively looking to leave just because of that…but that’s a different rant than this one.
Once a req is approved then it goes out to the team to disperse as well as hr. Some roles get handed off to the critical search team if the hiring manager pushes hard enough. But that doesn’t really matter.
We get flooded with candidates. Almost every one of them could probably do the job so we have to figure out who could do it best through the interview process. I personally never ask stupid gotcha puzzle questions because those annoy me as much as they do most folks here. I ask people to talk about their experience as it relates to the role. Usually this means I ask about how they solved a truly difficult problem at work, what made it difficult and how they were able to overcome it. Then I like to get into the technical stuff of what they implemented and why. Mostly I just like letting people who are proud of something they’ve done get a chance to talk about it.
Anyway we’re supposed to score people based on these arbitrary metrics like longevity (how long we think they will stay) and communication ability (this is very, very close to being racist…draw your own conclusions).
I never score people. Managers ask me why and I say because I don’t interview spreadsheets.
Anyway I’m one of usually 4 interviews. I interview by myself and the rest are all panel interviews. And once you finish the last panel that’s the last you hear from us unless you get an offer. I hate it.
> communication ability (this is very, very close to being racist…draw your own conclusions)
I'm trying to draw my own conclusion but I'm confused. Communication ability is very important for developers and other technical roles. We need to be able to talk to each other about our work, and in many organizations we also need to be able to work effectively with other non-technical staff.
Of course, this doesn't mean that you have to speak or write the company's primary language in some particular way, as long as you can make yourself understood. Nor does it require that you speak that language as your first language.
Is there something specific about _how_ Big Ass Corporation is evaluating communication ability that is racist?
The way I read it is that "communication ability" is something people can use to justify racist hiring decisions. For example, labeling non-white speaking patterns as "unprofessional", or non-American accents as "poor communication skills".
When in fact, these candidates may have excellent communication skills, and in a blind interview situation the same interviewer might praise their writing abilities.
But you don't really know, because the interviewer is rating communication skills in a scenario that can easily bring out a lot of hidden biases.
I think it's really important to spell out what "communication ability" means so that all the interviewers know what they're looking for. And more generally, it's very important that before you start the hiring process, you have a clearly defined set of criteria that everyone participating in the hiring process agrees on.
It sounds like you do what you can. Unfortunately, people like you leave as they can't put up with it any longer and the company is just left with people who are happy with the status quo.
People are getting less and less willing to deal with bullshit when they're in massive demand and there is a talent shortage in $x industry. And they're finding out they can move around easily now too in this remote-first world.
Something is going to have to change - really a lot of things. One of them is going to be that companies need to learn to figure out how to hire people without putting them through a grind-fest. Figure out how to deal with bad hires after-the-fact, but don't let yourself get screwed not hiring good talent because you made the interview process a giant pain in the ass to catch the crap.
Oh and compensation needs to go up to make some of these interview grinds worth it.
Nothing's going to change at FAANG until average, non-FAANG companies can compete on TC (never). I doubt things will change outside of FAANG - because most companies are merely emulating the FAANGs and hoping they emulate the success.
> until average, non-FAANG companies can compete on TC (never).
And that's the rub. Not only do they struggle to value my skillset, they also can't compensate it accurately. And sadly, FAANGs don't even have the roles in a lot of niches.
When you can make 3x what a FAANG would offer, annually, but the companies building in your same niche are too immature and pay 1/3rd of what FAANGs do, its tricky to want to tolerate any of it!
Solo. Right now I can make 3x FAANG comp on a new idea annually without reaching out to my network or needing outside capital.
Given how many ways there are to do that and much more, I would like the structure of someone else’s idea to focus (aka being an employee). Doing things solo has overhead costs and liability risks, whereas employment has almost none but half to 3/4ths of your compensation is withheld the whole time. So there is a limit to what comp I’ll accept, given the opportunity costs. Would be great if that comp was FAANG level.
You know that it's pretty easy for senior engineers take make >$500k at FAANG atm, right?
Can you share some things in the past that were easy money that netted you $1.5M in a year? I'm genuinely curious.
I used to have a ton of ideas that I thought if I did everything right I could've maybe made $300-600k. But then you can just get that as a paycheck at FAANG.
None of my ideas ever were easy and could realistically generate more than that. Plus there was always a risk they would generate $0.
Yes, I am talking about $500k annual vs making at least $1.5 million in a couple of months and doing something else
Hm, worst case, people on HN debate an irrelevant understanding of what I say is possible
Best case, they copy it en masse and dilute the opportunities faster
No thanks
I would take $500k doing the same stuff for a tech employer but nobody is offering that right now. Some contracting firms do, kind of, don’t really want hourly though and also want the benefits. I want to focus on someone else's visions, get paid on days off, no risk. Also want a ton of equity I wouldn’t go and purchase myself. Or private equity that I wouldn't have the opportunity of purchasing in addition to an attractive cash compensation. (These are all things I could do in just frontend/fullstack work.)
Some smaller companies are going above the 125-150k range, to double that. But not quite and they’re still few and far between.
> You can launch DAOs that automate anything these days and take a small percentage from the users of it. Just automate any small aspect of what people do and auto-liquidate proceeds for USD* so that you aren't accidentally speculating on anything, your users can pay for the liquidation too.
> *Your oracle server/cron job can incorporate a broker's API to get actual USD, your DAO can only get surrogates such as USDC which is redeemable 1:1 for USD at certain brokerages.
> It's a boom town. Anybody can make 3x more than what a FAANG would pay annually, and that's being generous.
One of many things you can do, Just didn’t want to people working on ads for a living to derail a conversation because they think crypto anything is a waste of time and mindshare
which obviously applies more to the person asking about what I've done because their ideas and execution made them nothing. good luck ya'll.
this is a thread about the conundrum of leveraging this experience without losing freedom or opportunity costs, not about being miffed that someone won't share how to make money, its like you all want to be scammed into purchasing an some youtuber's outdated amazon dropshipping masterclass.
Consider we've had a labor shortage since BEFORE the pandemic. The gotcha here is companies have a shortage of people they can lowball into a sweatshop "startup" environment.
Nothing changed regarding that one as far as I can see so interview processes getting longer isn't all that surprising. After all that's one surefire way to optimize for getting desperate people.
I was semi-actively hunting for a role a year ago.
The worst offender was a company I had five meetings with, 3 of which were identical code reviews for the same code test. None of the reviewers realized I already had the code review with their peers. None knew what the next step was.
Most companies just didn't have an organized funnel for candidates.
The one that did I quickly took the job offer at. Here's what they did right:
1. The recruiter prepped me for each interview as if they were a good friend looking out for me. They told me who I was talking with and what hobbies they had so I could relate to them.
2. I knew of each meeting and its format in advance. It's weird I'm calling this out as it seems simple, but here we are :-)
3. The code review was paid. And actually quite fun. The previous company code review was unpaid and 20 hours of 'implement a REST API'
4. The engineering team was actually trained on recruiting. Each one had read my resume and asked detailed questions about my hobbies, experiences, etc. Engineers elsewhere hadn't read my resume at all.
5. I always had quick feedback on technical meetings and didn't have more than three.
The most important difference I noticed is that most companies were ambivalent seeing me fail.. a select few even seemed to crave that.
I've seen the same thing. It makes no sense. I keep telling myself the incentives can't really be such that your hiring process be actively antagonistic...not if we want anything good right?
But perhaps the market can stay irrational longer than I can go without income. Hold strong to the companies that bother to acknowledge you're a person.
>I've seen the same thing. It makes no sense. I keep telling myself the incentives can't really be such that your hiring process be actively antagonistic...not if we want anything good right?
See, if your test is so difficult that people are failing, then it must mean that you are being selective and only hiring the best!!!!!
The paid code review or paid technical is a big one for me. If a company is willing to actually value my time during the interview process then I'm going to be much more interested in them. Instead of just inventing steps and adding seemingly worthless technicals
Currently investing 2 hours of my time per job offer:
- investigating the role, the company, their stupid website, their made up culture
- doing the unpaid take home tests (currently investing 8 hours doing a technical test for yet another stupid startup)
- answering dumb questions ("why do you want to work for $neverheardofstartup?") on fancy js forms
- having to register to their stupid career backend, thanks for yet another chance of having my inbox filled with spam because you don't know how to encrypt data
- uploading hours and hours of video presentations (as if cover letters weren't dumb enough)
only to be canned with a copy-paste "due to the amount of curricula we received unfortunately we cannot provide feedback - good luck with your job search" nonsense.
And if I'm lucky enough not to be weeded out by a bored-to-death HR person with the attention span of a starving kitten, this was just interview step 1/5
Interviewing these days is not a technical challenge. It’s a fraternity/sorority rushing week.
Technically I was qualified and able to answer their questions. But ultimately was turned down after 6 rounds of interviewing. I think I was heavily dinged because I wasn’t entirely familiar with their product in the wild, and was never given any hint as to what product I would be working on.
I'm surprised good programmers have the time/patience for 6 interviews. I think 3, maybe 4 is my max. If you can't figure out my skills in that amount of time, your process is broken.
I also disagree that interviewing is not a technical challenge. For most programmers it is. There are very few who can breeze through FAANG-level technical interviews.
2 total interviews. Maybe 3 if they have questions. But if they have questions, they should have figured it out between the first and second interview.
For me, if the 2nd interview is not me talking to someone from their company that I might work with and if I cannot ask questions about the problems they solved, their approach to programming or building teams (depending on their role), I just say to the recruiter that I'm not interested.
The only reason why I'd come somewhere is if I like the engineers or if I'm in need of money. If I need the money, I won't ask a thing.
At one startup I did a couple rounds of phone interviews and a full day of in person interviews. Lastly I got to chatting with the co-founder. I can't remember the precise question I asked about how they were building out the team, but I clearly remember the answer. They made the interview process longer and more involved in an effort to narrow the field of candidates.
I understand the reasoning: if you think you have a special mission and want people dedicated to that mission, filter by dedication. But I'm not really sure there is a way for any one candidate to consume as much time interviewing for a role as that company could consume out of a pool of candidates. And that includes my smart-ass idea of trying to interview at Pinterest and stopping in the middle of the interview saying "please sign up to see the rest of this whiteboard solution".
> Five companies told him they had to delay hiring because of Covid-19 – but only after he’d done the final round of interviews.
This is a typical HR strategy to keep themselves busy so they don't get laid off. HR is not a revenue generating department, so even if they aren't hiring, then they still need to push paper.
I work for a big 4 consulting firm and I think our process works well and is extremely short. We hire financial engineers (quants) and data scientists. I’ve lived through working with hundreds of hires and can say from actual experience it works quite well. This is our process:
1. Review resumes to see who meets the criteria based on credentials.
2. Recruiter phone screen to screen for any glaring issues
3. We conduct an interview day and the candidate interviews with 3-4 people (30 minutes each). We have a mix of levels conducting interviews but make sure to have at least 2 leaders from our practice. We try to make sure we collectively poke around all areas (technical, cultural, communication).
4. That same day or the following day (want to make sure candidate is fresh in our heads) we discuss candidate.
5. Each interviewer (starting with the most junior) has to speak about candidate and rate them from 1-3. It can be any decimal rating but cannot be a 1.5 (an “I don’t know” answer).
6. Interestingly, we are mostly in the same ballpark on these calls and when we move forward, we are generally happy with that person.
I can’t speak for the candidate who may have to wait a bit between application, recruiter conversation, and interviews. But at the very least, the interview to decision process is pretty painless and you’ll have a decision within 2 days max.
Having recently won the google hiring lottery, I wanted to add my experience
total length of time ~ 7 months
emails sent/received ~ 50
phone calls ~ 20
technical interviews: 7 (1 with screen with recruiter, 6 with engineers)
team match interviews: 3 (for me at least these were real interviews, in that I "flunked" the first 2, and decided to take the 3rd one very seriously before getting an offer)
Before getting hiring approval, I honestly felt that I would get rejected, and I can honestly say that being more "personable" and very "communicative" probably had a lot to do with why I made it through.
My honest advice would be to stop thinking of these long interview processes in terms of a a binary outcome that you have complete control over. Instead, think of it as trying to maximize some hidden parameter of a binomial distribution, where every interaction slightly increases your odds in the final coin flip.
However, I wholeheartedly could not disagree more w/ "having won the <insert_x_silicon_valley_company_here> hiring lottery". 80+ hours of interviewing? No offense, that doesn't sound like winning the lottery. That sounds like you don't value your time. Unless you're getting paid for that many hours of interviewing or receive a signing bonus to make up for it, any company that does 10+ hours of interviewing can take a rusted iron rod and shove it up their own arse.
In a market where software engineers are in super high demand, if a company cannot refine the technical interview(s) down to a max of 3 hours for any specific role, then why waste your time? I understand wanting to gauge a candidate's technical abilities. But there's a balance between understanding the candidate's technical abilities, the technical knowledge required for the job, and (the most important bit) what can be learned on the job for the role.
Agreed that the hour invested may not be worth it for a large percentage of people (again I got lucky, I would feel so differently if I was rejected after 7 interviews).
Google's point is just that they prefer to avoid false positives at the cost of (potentially) a lot of false negatives. The current interview process is probably some local optimum;
I haven't worked at a company yet that is actually good at interviewing. Where good is optimized over high recall and accuracy and a small time investment.
I know that Google does have one big advantage, in that a good percentage of people that get the offer end up accepting. That (unfortunately) gives Google a lot more leeway and possibly less incentive to further optimize the interview process. Software engineers are in high demand, but also Google is in high demand among software engineers.
At my previous job, trying to find a candidate for a role essentially involved lowering the bar until somebody was no longer in demand, since we weren't "in demand".
For what's its worth, I really didn't think the technical interviews were nightmares. It was mostly talking with very intelligent people who were volunteering their time to screen candidates. Though how much one enjoys brain teasers over productive work is of course a matter of personal perference. Everything else (emails, phonecalls, etc) were definitely tedious.
As for working at Google, I think it really depends on the person. For me it was a good gamble in terms of both immediate learning and future opportunities; for others it won't be. I do find the opportunity to have my code (or what's left of it after reviews anyways) reach billions of people a thrill like no other though.
I think the post-covid wfh job market has clouded something a bit which is that the tech industry in particular is becoming increasing oversaturated.
There is so many people applying for positions now that companies are resorting to these more and more annoying filtering processes.
My first job in this field 14 years ago was one interview and I got the job the next day. That would be almost impossible today.
I blame it on two things, oversaturation of the "learn to code" meme and the rise and growth of recruitment agencies and their influence on HR practices. They have to justify their own jobs after all - just 10 years ago there wasn't really much of a concept of an HR or IT recruiter as far as I recall - or it was just emerging.
I've said this before but I believe this field is becoming increasingly commodified. Soon you will be either a "white-collar" fang or a blue-collar "independent contractor".
As someone who is stuck with a "junior developer" who hasn't produced a single line of working code during past 1.5years in my team the "one interview and done" isn't working these days.
Yes, I'm in the same boat. I often interview people who should not be labelling themselves as developers. I think this is just a reflection of the oversaturation of this market. The answer to everyone's problem seems to be "learn to code". But what % of those people actually have an aptitude for coding or a desire for it.
We have too good employee laws. As long as you are trying your best it is really hard to fire anyone. There needs to be evidence that they aren't capable and even then they need to be given multiple chances over multiple months to correct this problem.
Only way to fire someone on the spot is if they are breaking law or refusing to do the work
If this person is literally not producing anything useful, then set them a basic piece of work and tell them to complete it. If they can't give them a warning, tell them to upskill. Repeat after a month. And again a month after that. If they still can't do it then you have plenty of evidence to justify firing them, anywhere in the world.
Google took 3 months. 1 month was from the virtual onsite final interviews to the Hiring Committee decision. It was a miserable month and even my wife hated Google by the end.
Second was for a Director of Engg position at a mid sized company. It took 2 months and finally I had to force them to answer. It was a company with weak leadership and it showed in their inability to make a decision.
It's odd. I'm tending to think going through recruiters is the answer. The recruiter can be the bad guy and actually get a yes or no by putting pressure on otherwise I'm emailing multiple times and lucky to even get a response. If you weren't sure what the next steps were then why are you even hiring?
I interviewed with four companies back in May for staff engineer roles(or staff equiv). Based on that experience and my current employers process a somewhat baseline expectation can be:
* Phone screen with recruiter that reached out to you
* Screen with the hiring manager
* Behavioral interview with multiple peeps
* Code pairing session with multiple peeps
* System design session with multiple peeps
So AT LEAST 5 hours time commitment just on interviews. Add time to research the company, its employees, and etc. Maybe the code pairing is instead an at-home test of some sort. This could potentially add hours(or in the case of Teleport like 20+ hours). Just engaging with a handful of companies was a huge amount of extra work and stress on top of existing responsibilities.
I pulled out of three voluntarily and declined an offer from the last for various reasons, opting to stick out till my RSU cliff in October. For the next round of engagements I may start toying with filtering out companies based on their hiring process as well and giving push back on it to see what happens.
I had the same experience earlier in the year and ended up bailing out/declining offers because the process was giving me bad feelings about the work cultures at said companies.
I did actually tell one that the schedule of phone interviews (2) and video call rounds (4) was too much commitment without more details about the role and salary range. They responded with "if that's too much commitment the position is too".
IMO, for new grads and career changers in particular, it would make good sense for Google and other companies that have to interview vast quantities of candidates to develop and publish some rigorous MOOC sequences that candidates can complete on their own schedule to develop and demonstrate relevant competencies in a way the companies can trust more than they trust 3rd party degrees. Candidates who complete the MOOC sequences successfully could be fast-tracked into an expedited interview process. Plus they get a marketable, public credential out of it, rather than just going through a super long interview process with nothing to show the world / other companies for it
Google is already kinda doing this with Grow With Google, so I am just thinking of an even more extensive and rigorous version of this
And/or just ask people about their best Factorio factories and EXAPUNKS solutions :)
Once you realise that they are trying to leverage the 'sunk cost fallacy' to try and get cheaper staff, you tend to bin these earlier.
This is nothing to do with removing risk from hiring processes. It's to filter for those who want to be in the fraternity so much they will do anything to get there - including being chronically underpaid and badly treated.
There is still a shortage of good people. Let these companies have the less good people.
They can also drop you in the middle of the process. With just an email saying thank you.
I had a long interaction at Amazon where the recruiter told me they are trying something new. Their goal is to keep the candidates mental health in mind and create a welcoming and open process.
I spent 2 hours in the phone where she presented me with different process and what not. I even learned the name of her grand daughter, and her dog, and how she had to raise the grand kids when the mother was going through a phase, and how she had to paint her hair pink to keep up with the new generation. She gave me her personal cell, and we communicated everyday until my assessment test.
I passed the coding challenge. But that cultural or psychological test? No idea. Anyway, never heard from her again despite emailing and texting.
I had an interview with a YC company last year. I went through -- not exaggerating -- 8 interviews, almost all of which aside from the initial phone screen were an hour or more in length. 2 of them were technical interviews. I had finally gotten to the take home project, naturally a project in Ruby on Rails despite the fact that I haven't written a lick of Ruby in my life. Anyway, I was rejected after this step. To be fair, the take home step was paid, which was nice, but not nearly enough for the time it took me to learn enough Rails to be productive, learn best practices / idiomatic Ruby, and solve the problem they gave me.
Incidentally I've noticed that the Ruby community has this weird thing about insisting on either N years of Ruby experience or requiring interviewees use Ruby during technical interviews or take home projects. Ruby shops were the only places where I've ever been required to use a particular language during an interview. I suppose it's because there's so much magic happening in DSLs like Rails that they assume it'll take too long for even experienced engineers to come up to speed?
Obviously there's risk involved in the hiring process. But I think there's a lot more risk involved in procedurally treating people like garbage.
Anyway, after that ordeal I'm going to insist on being allowed to interview in a language I'm familiar with. They'll judge me on my best work or not at all.
I interviewed with a company out of SV that did this. They started with 3, added another 3, one hour interviews and finally another 3. 9 interviews over the course of almost a month.
I was being interviewed for a principal engineer. I was very clear and kept saying I wanted a management track position. They kept saying we love your background we can work with you on this. Ninth interview was with the CTO. He said the same. Them ghosted. Wouldn't answer my emails or calls. 9 hours, plus prep time wasted.
The company I ended up getting hired by also did a large number of interviews, 8. And they took even longer. Just over three months from initial contact. They're fantastic to work for, but I do think there comes a point where if you keep digging you're going to find something you don't like.
I'm too shy to name and shame, but my former company would ask us to advertise and interview for jobs, but only after countless hours of interviews decide they didn't want to increase headcount. I lost about 1 day week for months doing our best to find great people. We would fly them in from all over the place. This happened multiple times. I think I left to make indie games after the third time.
Yeah it really bugs me when companies reach out to experienced people, put you through multiple rounds, only to ghost and ignore you after. I'm looking at you Glassdoor.
I got recruited for a an interview at a fund management firm. Went through four interviews and got rejected a week later after the 4th interview. Companies don't realise some of as are so burnt out and have worked so hard during the pandemic. I removed myself from LinkedIn because of it. No hard working dedicated dev should be treated like the past didn't happen. I know what you guy's and girls are going through and I just want you to remind you you are more precious than gold and diamonds and you don't need beaurocrazy to validate determine your value. We will continue to build a better world and treat our future candidates with respect they deserve and not make them jump through impossible hoops designed for idealist machinemen
I had a friend who had a similar experience to the candidate in the article, but at T-Mobile.
He was unemployed. They interviewed him 5 times over a month and a half, and tried to get him on site for a 6th interview loop roughly 2 months after starting the whole process. They were most put out when he told them he'd already got another job. He was amazed at how offended they were, especially that he'd wasted their time.
He was, apparently, supposed to just sit around and wait for them to make a decision, because who needs money to pay for things like rent, food etc?
Redhat: This one was for you. From the moment I applied through a recruiter until I got an offer letter was about 13 months.
In that time, I had already started my new job -- I didn't actually take the role at RedHat, but, I was able to use their offer letter as leverage to increase my salary.
I've worked for YC companies, I've worked for large companies. The larger companies seem to be a little bit easier to get into: my only interview at Luxottica was literally someone asking me about some retail experience I had about 20 years ago and some very basic Linux questions (retail technical architect position), but, I've had YC companies have a multi-month long interview process where I've been told after 10 or 11 interviews that they thought I was "Too senior for the role," which, just kinda blew my mind.
The whole process is broken, but, there's not really a good solution to fix it.
I think the biggest give-away from the article and from the comments written here is that companies neglect recruiting as a chance to generate positive brand impressions and in general, use it for marketing. If people walk away from your interviews feeling disappointed or mistreated there's a good chance they won't recommend or advocate for that company in the future.
You'd think spending some executive muscle to smoothen out the warts in the process would be beneficial to any company trying to recruit smart people. But I guess having regular engineers or other employees with whatever ineptitudes in empathy or social skills won't be fixed by somebody telling them to "be sensible and nice." If that's how they were treated and think it's ok to treat others the same way, that's how it will be.
All you complaining about the length of FAANG interviews... One of my family members was recently applying for a job to stack shelves in a supermarket. They had to do a tricky 3-hours long multiple choice questions test. After that, they got an email asking to record a video about themselves. No idea what would come after that, but they gave up at this point. All this is also very difficult to go through if you are older and not technologically well-versed.
A big part of what prompted me to become a contractor. When I last did this, everything was at least 3 interviews, + sometimes even the recruiters wanted to meet with you first.
Finding your own clients doesn't start looking as bad, and a discussion to see if you'll work together is much better than an interview.
The trouble with interviews these days is that there is no penalty for false negatives.
Long, multiple interviews are great for those who are already in the group - it provides legitimate excuse to hold off doing actual work, feel smug with their peers about how difficult the job is, and also provides acceptable excuse for project delays.
As a senior engineer, it's amusing being interviewed by intelligent but very junior engineers who clearly cannot understand the scope of what's in the resume. This usually happens with a quick scan of the resume followed by a realization (there is this peculiar look) that they don't have any relevant questions to ask about the experience, and finally landing on their favourite puzzle questions because what they really want to know is how my thought process works.
> The National Business Research Institute study shows that a bad hire can have significant costs to an
organization – between $25,000 and $300,000 5 . Asking a candidate to partake in four interviews may seem like overkill, but it seems trivial compared to the cost of a “bad hire.” Organizations that hire the best data science talent ensure they spend the time to use the best hiring practices.[0]
No one is doubting the risk mitigation, which is why the process exists in first place. But the BS of wasting someones time also needs to be addressed. The reason most companies waste peoples time is because they are too busy with abstract concepts tangentally related to the actual job, and theoretical models by some "expert" of HR management. Software engineering has become a psuedo-religious exercise in computing witchcraft.
If you want a backend engineer - book a few hours, even on a weekend, set up an IDE and get on a real world project. No bullshit. Build a small API to these requirements, using these technologies but take care of edge cases and deploy that bad boy.
Are you (or they) suggesting that the 4th interview meaningfully reduces the number of bad hires?
I’m guessing not.
It’s poorly designed and/or poorly implemented hiring strategies that lead to bad hires, mostly through a lot of noise being collected during the interview process.
This is a very solvable problem.
Edit: I will add that this is an ad for Booz hiring, so of course they want more process.
6 interviews increase the chances of a bad hire (or at least decreases the chances of a great one). It restricts your hiring pool to those who are willing to be abused by the company. That's not the top-tier talent.
That’s quite the range. It suggests a strategy: worry less about hiring false positives (with all the concomitant issues not hiring anyone brings) and worry more about reducing the cost of those false positives.
I remember the one time I worked at a design agency. 6 separate interviews in one day. The account managers were thrilled with me and absolutely did not want anybody else. The technical people were far less confident because nobody in their right mind could possibly hate jQuery. That meant some more interviews.
What’s maddening about that is that this was for a consulting position not a developer position. It didn’t matter though because the contract written one way, the management at the client refused to accept the terms of the signed contract, and the developers I was there to help thought I was their subordinate to dictate.
Next time you hear a hiring manager complain about shortage of engineers, ask them why haven't they changed the process with recruiting instead of just trying to fan out and sending automated tests and take home assignments.
This is a major red flag that the firm isn't sufficiently serious about hiring and I would always walk away from a firm without a clear idea of their needs and the number of rounds.
My experience with a firm that started with three, then paused, had an "open evening" for interviews and then wanted more (which I politely declined and privately blacklisted them) reminds me of the lucky escape I had: the firm went through this mess only to uncover (a little later) an operational error that left them refunding several billion to clients, trundling on as a zombie firm!
A family member went through five interviews for blockchain.com at 4-5am (they were in England). For the last one they (blockchain) were asked to do 6-7pm their time but couldn't be assed to have a call after hours and suggested another 4:30am (to us) interview, yet they had no problem asking people who didn't work there to be up at ridiculous hours week after week. The cherry on top was being offered the job at half of what the position should have paid and at a $20k pay cut from what they were told my family member was already making.
It's just such a waste of time, too - you toss out so many other potential opportunities when doing these. I've heard of this being done to interns, people that only have so much time to get a job. Six interviews until a rejection. If you can't start your career without this going on I don't really know what you can do. I can't imagine the recruiters conducting these in the same position, going for six interviews to get that job. For software engineers you just need it, apparently.
For everyone saying that it's risk mitigation, I recently asked about something similar[0] for a junior position, and the process still hasn't finished. For context, the company is a medium-size tech company with presence mostly in Europe and Asia.
I don't know these things well enough but it makes no sense to me. For starters, in the tech sector in my country the salary for fresh grads like me actually come mostly from the government. Moreover, these companies are all secretive about compensation, and they probably think they can get away with it by dangling their "reputation" in front of you like a carrot. In most cases the salary is about the same as a small startup because, again, they get the money from the government.
People can argue about spending time and resources on training and what not but basically every job ad, from "top" companies to the web dev garage down the road, expects us to learn by ourselves anyway?
It's frustrating for early career starters that most of my friends and I are going through. It's such a huge waste of everyone's time and people are just churning because of this crap. Please get rid of non-technical HR and interviewers.
Sorry for the emotional rant. I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
> I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
It's harder to deal with emotional kids than it is to deal with incompetent engineers. Maybe that's why those non-technical HRs might not be as useless as you think.
> You made the mistake to assume that we are idiotic enough to be emotional for job interviews.
And that's a risk that could potentially be spotted by a competent HR.
> It's harder to deal with people who think they are competent and know it all than emotional kids.
Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
> And that's a risk that could potentially be spotted by a competent HR.
It's a risk that could only be spotted be HR, don't know about the "competent" part. There would be no emotional-kid risks to speak of if it weren't for useless HR.
> Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's making even less sense now. If we are commodities and it's all about uniformity and standard, why do we see senior engineers complaining about this, too? It also makes no economic sense to spend so much time and effort on elaborate bullshit on "commodities". I don't mind being a commodity if the standards that you speak of exist, and I don't want to be unique. But guess what? It's the HR that wants us to be the unique commodities.
The most difficult people I've worked with were not because of technical reasons, but due to reasons outside of that: inability to disagree constructively, unwillingness to compromise, or just general assholes. That kind of stuff.
Someone without the required technical chops can be useless, which isn't good, but these people can be worse than useless as they can derail and/or demoralize an entire team. I've seen it happen; it's not pretty.
This isn't unique to younger people, but in my experience the risk is quite a bit higher in younger people. I say this also as someone who, in hindsight, was quite difficult to work with when I was younger for various reasons. As I've grown older, I've learned a thing or two and I think that now I'm actually a fairly nice person to work with (I hope so, anyway...)
Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
> Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
I agree, I've even had to reverse my own team's policy on this at work : I used to think the technical stuff was the most important and pushed my team towards hiring exclusively the technically smart people, but I have been proven wrong over and over again by those "smart" engineers I vouched for.
"Smart" isn't just technical skills anyway. You can have all the technical chops in the world, but if you never listen to anyone else, insist on doing things the One True Right Way™, and are unable to admit that you're wrong, then effectively you're not actually all that smart, are you? "Smart" is really a combination of skill and attitude.
Indeed, the smartest people I've met are the nicest people to chat with and always ask questions instead of affirming themselves. As you point out, skills + attitude is the smart way since everyone wants to be around a nice and skilled person.
On all job responses you should spell out your minimum salary requirements before you agree to the interview, unless you are ok with wasting time on interviews only to get low balled on the salary side or it doesn't match your minimum requirements.
Most of us don't have the privilege to negotiate, we are fresh grads. Who doesn't want to work for larger companies in the hope for a better career path? And don't forget about power asymmetry.
Aren't FAANG companies doing at least 4-5 interviews now?
More and more companies are doing this now in tech space (AU) as well. My last 4-5 job app contains 5 interviews, even the medium sized one.
It is super annoying for me, but I'm not sure what to do about it, some of my dream big tech companies are like that so I have to go through that. I'm pretty sure a lot of people go through with that because that's their dream job too, not because they liked it
I would have thought in 2021 companies would say "if it's a 'not sure', then it's a no", but I've worked at some places recently where "not sure" would get additional interviews. That's one problem.
Another problem is in certain companies, senior management don't trust their own staff and want to be involved in the recruitment process.
Yet another problem is poor CV vetting. You really can tell a lot about a candidate just from the CV. Even if (in the UK) an agency has mangled the CV into its own 'template' for companies.
Demonstrating knowledge of algorithms is fine. Having to implement a red-black tree in an interview, or some arcane template corner of C++'s standard library from scratch, is not a good use of anyone's time.
If companies don't keep consistent interview processes, if they have two 'yes' candidates for one role, they can't fairly compare them and choose.
My worst/most lengthy interview was for a certain bank, that famously expects employees to work 12-14 hr days, and weekends. Total interview time: 24 hours. The result boiled down to the MD/partner interviewing me last, and having the yes/no decision.
I’m usually OK with doing more than three calls after a recruiter call (which are ideally with a hiring manager, peer manager, and a prospective peer), but that is usually because I quite like getting a feel for company culture.
More than that is just silly and contrived (although I usually end up talking to a VP or similar these days on account of my seniority).
There are usually three major red flags that make me step away (or at least curb my expectations):
- Any kind of automated coding test (I have a GitHub profile and plenty of public code, plus HackerRank and the like can be gamed if you have enough free time)
- Whiteboard or live coding interviews (I find contrived discussions about algorithms stupid when I can reach into my actual, physical bookshelf to a well thumbed-through copy of Skiena, get a tested approach going and _then_ figure out how best to optimize things)
- When I am asked for compensation on the very first interview. I see it as culturally rude, and if they read through my CV at all and have a target for the role they are interviewing me for they should have already done the math.
But as I am edging towards 50, a lot of the above just doesn’t happen. Instead I have long, rambling conversations about company values, people culture, and even end up doing free corporate strategy consultations, in which I am obviously expected to utter the right buzzwords that fit the interviewers’ worldview.
I quite enjoy those conversations for the insights they provide into how completely broken some companies are - instead of getting down to brass tacks and discussing their challenges, many startups end up coming across as cargo culting FAANG concepts without addressing their actual pain points (how to grow, how to retain employees, how to actually deliver product, etc.).
Hear, Hear! For me it's when they put junior people doing interviews to senior roles. I get the point - not enough resources, culture check, etc - but at a certain level we're not even talking the same language or even working experience.
On the other hand, any Amazon interview has tons of people :)
regarding the last point, nowadays what I see is the opposite where candidates still struggle with getting a clear salary range before engaging into time wasting exercises.
I once interviewed for a large game company. Their main office in Europe is in Dublin, but at the time they were opening an outpost in Brighton, UK (where I am) and were hiring a server engineer for their e-sports division.
There were a lot of interviews. For the fourth or fifth they flew me out for a whole day of interviews in Dublin. These included at least three different departments that I remember with separate coding interviews, and I had to give an hour long presentation.
I didn't get the role, and shortly after the Brighton outpost was axed. In hindsight I'm pretty sure that I didn't get the role because someone high up didn't want the outpost office to exist (it was only there because someone important they wanted was determined to live here).
I'm not sore though. Not long after the company hit the news for having a toxic culture (amongst other issues), particularly toward women.
Think of it this way. Company A is hiring for role X. They get 100 candidates, interview 10, with each candidate going through a 5 interviews at an average of an hour each, assuming they hire 1 candidate, that's 45 hours of people's lives that have now been utterly wasted.
The problem is companies don't care about you and your time until you are their employee. They'll gladly waste hours and hours and hours of your time, because doing so costs them nothing.
There's actually a super simple solution to this problem.
Require interviews be paid. Doesn't have to be a lot, a simple honorarium scaled to the role's salary would suffice.
If your time has a cost to companies, they'll stop wasting it and start optimizing to minimize the time hiring takes instead of optimizing for other factors and ignoring the negative externality of wasting peoples time.
I can relate to the whole "never-ending job interviews" as described in the article.
Two months ago, in June, a company reached out to me regarding a senior level back/front hybrid role. This company previously ghosted me two years ago but still had my resume and were now willing to hire me right away for a substantial increase in pay.
Before I accepted any offer, I shopped myself out on Indeed and found there is a huge demand for folks like myself right now. Here's a taste of how it went:
Company #1: Fintech startup. Two separate 30 minute, non-technical interviews. Third interview was a four-hour long interview involving multiple LeetCode problems. Fourth interview they wanted to discuss my performance during the third interview, and then schedule a fifth interview. I declined because a) I felt this was overkill and unnecessary, and b) one of their developers was rude and condescending because I am self-taught. He went out of his way for 8 minutes to berate me. I had never experienced anything like it.
Company #2: AI-focused firm in analytics. Hiring for a management-level role. Went through three interviews. First was a 30 minute screening. Second was an hour long overview of my technical background. Third was mostly a follow-up to the discussion that took place during the second interview. And at the end of the third interview they informed me there would be four more interviews to meet the team, write code, and a whiteboarding session. I declined and said I'm not interested, again because of the time factor mostly.
And I noticed this process repeat itself for most companies. It's mentally exhausting, plus I have a family, my current job requirements, and other responsibilities.
The interview process is really unpredictable to a degree. Some folks want to see substantially more coding than others, taking into account similar job roles and descriptions.
I see a lot of folks who have interviewed with FAANG companies, and while I don't have any experience with them, the process sounds somewhat similar.
I am fine that up to the ~3 interviews covering the different aspects (say HR person checking the general personality, IT guy for i.e. Linux sysadmin knowledge mini-test, the team manager).
In 2020 after the Covid started, I got into the endless spiral of I believe 6 interviews spaced over a month or so, then the long wait and getting shorter contract with same salary but different from the advert job title. With the back against the wall I took the job. Within 3 months or so (including a 1 month training) they re-posted a job advert for my position. I had to extract from them an info that my contract described as "with almost automatic extension" will not be extended ("we run out of funds").
I work off my posterior for months to get this.
I would say that's the worst person to do the personality check. Instead, engineers the hire would actually work with should probably do the personality check.
Often HR is either a bureaucrat with a non-technical degree, or an inexperienced young "internal recruiter" with a non-technical degree and a pleasant appearance meant to attract responses on LinkedIn. Neither of those are uniquely well suited to judging personalities. (Unless this is another case of, #wontfix, we want to screen out engineers who have personality characteristics that random 24 year old sociology students don't like.)
Exactly this! They are probably the most incompetent people included in the hiring process, and yet they will take part in the decision making with their ‘magic’ personality judgement and culture fit skills, always making the wrongest decision ever. I had candidates rejected by HR because they were too charming, too lively, too <insert random characteristic>, to find them later employed in way better companies and roles. Well done HR, now you have your culture and team fit, for a team and culture you are not even managing.
Ah and your professionalism stops as soon as you hire someone. The rest of candidates might be left without a response even in their 3rd reminder. I guess it’s tough to even setup the auto email notification in the ATS tool you are using.
I remember over a decade ago interviewing at a bank and being asked how much experience I had with [insert list of systems] and integrating data specifically between two of those systems. I had never even heard of any of the systems on the list. Got home and Googled them, nothing. Called up a friend who worked there and he told me those were internal names for their systems, no one who did not work there would have any idea what they were, and he was shocked they were asking about them using their internal names during interviews. Oddly enough, one was just an Oracle data warehouse fed by Informatica ETL and generating Cognos reports, and I had experience with all of that technology, but answered "no" when asked if I had experience with "the Pulsar system".
We are a mid/small-sized company (~3K) which is hungry for "freshers" (those just out of college). We are out competed by the big sharks who pick the best of the students and we have to search among the remaining. Our hiring pipeline involves a written test (coding - mix of Multiple choice and coding - in favour of only MC nowadays and analytical skills) provided to us by a third party. The test isn't really great (fixed small set of questions which doesnt change, some arcane C coding questions (the likes of https://news.ycombinator.com/item?id=28034019), etc.). So we have 2 rounds of TA (technical assessment) and 1 HR round at the end. This is resulting in a lot of filtering and we get a success ratio of about 4-5 per 1K students.
Management does not like this and blames the assessment team for having "high standards" and feels that we are wasting previous time (of assessors) and not getting desired results. The assessment team feels that the written tests are not a good indicator of coding skill and that most applicants fail in the basics of coding (logic, for loops, pointers etc.). Management has given a new target to reduce the time to hire and increase our hit rate.
The solution will mostly consist of removing HR round (no value add, can be assessed in TA), reducing or eliminating TA (!) and relying solely on the written test. Given the written test quality (though it has mininal configurability in terms of the split between MC and coding questions) this seems likely to get in a lot of "false positives".
My questions - is it really feasible to use only a online automated assessment (not specifically the one we are using) to get a right coding assessment done for freshers? is there a "good" (efficient and effective) "standardized" framework/solution for fresher assessment which one can follow which you have used? (Note: we are a software company providing solutions and consulting in domains like automotive, networks, devices, embedded, etc.)
Preferably one. Perhaps two if there are unanswered questions. You're really, really pushing it at three, however. Unless I'm compensated for the time I'm about to waste, I might not bother meeting up to a third interview.
Since I finished college I was on a interview loop. I'm so tired, at this point making my own company and freelancing seem more reasonable.
I don't understand why there must be 4 different persons asking me the same questions just so in the final to give me a lower offer than we previously discussed or to ghost me.
I had a bad opinion about HR when I was a student and didn't work based on how a few of my friends and family treated, now that I'm looking for work and have to deal with their bullshit daily I literally started to hate the people working on this dep and their lack of respect.
It's endless, every little bit of concern about personality or "We did this at X." place and "Need this guys input." are added and has zero proven value, but it is added.
At one company I worked at it wasn't uncommon for a department to decide to hire someone and HR or the recruiters somehow were able to hold things up for months.
My most recent job was at a smaller (not a start up) company and as an applicant I was talking to people I would work with and was asked legitimate questions and etc.
I think a big part of the problem is how much software engineers are being paid now. 4, 5 or more rounds is not unheard of for a VP/CTO role. Companies are acting like that Intermediate Developer is a critical role because the pay is making it seem like a critical role, they are making what would have been a Director salary within institutional memory.
I just had candidate that was already getting paid what would have been an insane amount a few years ago, get a counter offer that included a 20% raise and significant equity.
I've had this experience too. Including with a 10-person YC backed company. I'm glad it's not just software engineers experiencing this. I suppose hiring is broken everywhere...
I think there should be initial round with HR just to see that you aren't out right lying on your application and/or CV. Then you should have at home coding exam (still time limited to an hour or two) and if your code looks good then there should be the final interview with the team/manager where you are going to work.
EDIT: now that I think about it there probably needs to be one more where you can negotiate the sallary and benefits and actually sign the contract.
I’ve interviewed with Google twice. It’s not that many separate rounds: You have the recruiter sell Google to you, then there are two phone screens, then it’s the all day interview (with multiple people). Which is reasonable. I didn’t get the Google job, but, looking back, my life is better because I didn’t relocate back to Silicon Valley to work for Google.
I’ve never had a company string me along. Four separate phone screens or interviews seems to be the limit. I’ve even been hired after one video conference interview.
I once was given a “we want to hire you, but we need to get the funds together before we can give you the offer” spiel during the great post-mortgage economic recession, but they did hire me after about a month.
After five separate rounds (again, talking to multiple teams on the same day after one or two technical phone screens and one recruiter call doesn’t count; that’s standard practice with many companies), I would tell a company they need to either, as my father put it, “shit or get off the pot”.
In terms of take home assignments, I have no problem doing them, as long as the employer has no problem having me put my answers on a public GitHub repo. I will not do Codility tests, because my experience is that employers who do those kinds of tests are Unicorn hunters.
When I lost my job during the pandemic, I had multiple jobs I was interviewing for, each took maybe a month to get through all of the interviews. Do they really expect unemployed people to suffer through a month of interviews? Some people actually need a job fairly urgently!
And these companies I was interviewing with, they all had a fake air of superiority, like they were the next Google. This interview culture needs to change back to how it was.
So much time and money is spent interviewing it seems like it would be cheaper to just subcontract the candidate to do a real task as a trial run. That would give a much more meaningful signal. People say it's a risk mitigation strategy to do so much interviewing; but, is it? Are we sure it isn't just making us feel like we are mitigating our risk? Do we have any data that hire quality goes up with each incremental interview?
I've never understood this. The first interview exists to sell me on the company, and for me to express my desire to work there. It's for alignment.
Three questions I always ask are 1. What's your hiring process, 2. What's the base salary range, 3. How does the company demonstrate its commitment to ongoing learning. Any reticence to discuss these items means that I learned about how the company just isn't for me.
A lot of jobs will put you through multiple interviews then ghost you. I interviewed at several tech companies last year and it was crazy how few would email a simple letter saying they had moved on in their search. It's like they want the option to put you on the back burner for weeks and then reach out again if things fall through with others. Really gross and selfish.
I read this article yesterday. Then literally two companies rejected me with the follwoing reasons today! I found it a funny coincidence so posted it here :)
(a) You are clearly too technical, we need a more managerial experience for this role
(b) You have too much managerial experience but for this role we need a more technical person.
Similar roles in leadership area, different companies.
Aside from being tech lead for my project I am also technical interviewer and I regularly interview candidates.
Recently I have asked my HR if they could set up longer meetings with candidates because, honestly, 1.5h is in my opinion not enough to evaluate candidate. I would like to ask some technical questions, I would like to see the candidate write some code, I would like to have a discussion on general tech topics just to get the feel of the candidate. And also have time to respond to questions that the candidate may have.
Usually it is the coderpad part that overflows and takes more time but it is also hugely helpful in understanding how candidate works and deals with problems.
So the response from HR was that they "don't want to scare the candidate". And if I need, maybe they will set up follow up with the candidate "just don't tell the candidate upfront to not scare them".
I had a round at accenture about 8 months ago, multiple interviews over a month and a half maybe; and it went first interview with a manager wanted me to go forward, second interview someone who okayed me for tech interview and what position I should be looking at, third interview tech interview said fine now you need to talk to HR head and she will make final determination, HR head said send you info later in day some days later still nothing, about a week later message from HR needed to have another interview with someone, consulting offer came in I figured well this isn't going anywhere took consulting offer.
1 week later the managerial guy called up and said ok everything went through now we can talk about the job I said "sorry, I took a job". He wished me good luck but I'm not sure from his voice if he really meant it.
Every quality job I've had consisted of 6-8 different interviews. However, all of those jobs also send me a schedule and list of job titles of who I will be interviewing with, and conducted all of them on the same day. At this point I consider it a big red flag if a company excessively spreads them out.
Here most of them seems to be pointing at number of interviews that's being conducted for a candidate by the companies and how emotionally torment it can be.
I can tell you it's not an easy job to take interviews as well. I have been interviewing candidates for my company for past 4-5 years. It drains your brain a lot than giving interviews IMO. Sometimes I get exhausted and frustrated for the day after taking 4-5 interviews. start to feel, brain stops functionating. And frustrating thing is you have to provide feedback for audit purposes in more than 100 words. Especially rounds like System Design, Hands On coding, Knowledge of Technologies, Resume drilling.
Also interviews been happening continuously at least for past 2 years due to attrition issues linked of pandemic. So never ending process now a days to take interviews in the company.
Technical interviews are high pressure situations that don't just check someone's technical proficiency but rather their ability to cope with pressure, communicate effectively while under that pressure and their willingness / unwillingness to ask for help or recognise their own weaknesses as soon as they realise they can't do something.
All are essential, day-to-day situations any developer will find themselves in. It's difficult to replicate that in anything other than a technical interview.
Having said that, tech employers don't hold the same power they once did. Decent developers with people skills know they can always find work or just make work for themselves if need be. We're entering an era where these guys will set their own hours and pay and the employer will be the interviewee.
The last two jobs I applied for were like this. The first one had 8 interview rounds on 8 separate days. It was a remote company, and I was working in an office at the time, so I had to figure out 8 separate excuses for sneaking away from work for an hour to take video calls. It was ridiculous.
I refuse to engage in long interview processes or technical/programming tests.
My CV goes back 20 years and it is quite clear about what my technical skills are. For me the most I will do is one phone interview, one HR interview and one technical interview. If the recruiter has any questions about my skills they can ask them in the technical interview and I can also put them in touch with people who can vouch for me as well.
I've experienced a few recruitment processes where there were multiple round and also take home tests that took up way to much of my time. To me the time investment required to go though these is too high as the risk of coming away with nothing is too great.
If a potential employer can't figure me out from my CV and a few interviews then I don't think that is a place I would want to work.
I once had a 3 hours live coding session (without any previous warning it was a live coding session) on a problem described by some examples, while the 3 interviewers were clearly watching me and commenting my code or what I said in their chat.
The expectation was that I made the example exercise + tests.
If you can’t make a decision after 3 rounds then you have no business recruiting anyone and should just give up. You’ll not only irritate and push away all your good candidates, but you’ll also make your staff angry that they’re always wasting time interviewing people.
>According to a survey from global staffing firm Robert Half, 62% of US professionals say they lose interest in a job if they don’t hear back from the employer within two weeks – or 10 business days – after the initial interview. That number jumps to 77% if there is no status update within three weeks.
Ha, that's familiar. I'm not in the US but, during my last job hunt, I'd already accepted a job offer before some of the companies I'd applied to replied to me. Companies that are paying recruiters to bombard my inbox or paying staff bonuses to refer me.
Hiring is a very human, very broken process. There's little incentive for an individual to do it well short term but fatal repercussions if the group do it badly long term.
I've done two long ones - McKinsey Digital (~7 interviews over 3 months) and Bloomberg (~5 interviews over 1 month).
Whilst it was dragging, I do feel they were both adequate processes for me to learn about the companies and the role, and for them to get to know me and my fit for the team. I ended up learning quite a lot about myself, too, and got useful feedback out of the process.
It also was during the pandemic where organisations where finding their feet with remote hiring; I reckon in a pre-pandemic session, they would've been compressed into sessions together.
The scheduling, and comms about it weren't always amazing, but that's down to the recruiters rather than the hiring team, imho.
Long interview rounds are not only a significant cost for companies, but also for individuals.
Each hour of interview costs a company ~$100, in the time of the interview alone, not to mention scheduling overhead, frustration and recruiter's time spent. 5 rounds for 5 candidates == $2,500 (1 week's salary on average at big tech beginner roles).
For each candidate, that's 5 * (whatever they are getting paid, let's say $50) == $250.
If companies think of it this way, they might as well get some candidates for short amount of time to see a fit, instead of countless rounds spanning months.
Ideally, they should also compensate interviewees for their time, which I doubt will ever happen.
the best jobs I've had were at most three or four interviews and then hired. The worst ones were more than 5 interviews and they still couldnt make a decision or one guy out of six didn't like you so you don't get hired...
I get so jealous of my mechanical/structural engineering friends who's interviews usually span one or two rounds, and they're never asked for anything resembling spec work.
Hiring should never take more than a day or two of interviews.
I know BBC is writing this from the perspective of a new interviewer. However anybody who is preparing for FAANG or even hangs out on Blind knows that getting into any of these big companies, now includes multiple leetcode style programming tests and system design interviews . Just as a point of reference, CTCI is now on its 6th edition and it is still playing catch up to the ever changing interview processes at these companies.
In fact if you spend time on leetcode , you would get a fair idea of what companies ask LC medium/hard, which ones ask Dynamic Programming and which one will specifically ask questions that are not on LC
While interviewing with a start up, I was asked to do an assignment which took almost a week to complete. After the assignment, I went through 6 rounds of interview.
Then they kept me hanging for a week, only so send me a rejection mail.
Not a "tech" job, but I found that the best hires were people who worked on contract for a few months. They did not necessarily have the skills when they started, but you could see drive, diligence and competence in those few months. This attitude needs to be maintained every day and cannot be faked as easily as you can an interview. A bonus is that they get paid for their time while getting valuable job experience.
It might only work for low-level entrants. For higher positions you are hiring the person for their experience, not on how well they can jump through arbitrary hoops.
I talked to a company for three weeks — I went over and would talk to a couple of people, a couple of times a week — and then decided they wouldn’t get their act together.
I didn’t mind the way it unfolded — people were busy, I wasn’t working, and it was only a couple of minutes away from me, so really it was only perhaps 8 hours. But after three weeks I felt I wasn’t getting the answers I needed and they didn’t seem to be making progress on the hire. So I said no thanks.
This was a company with 50 or so people — I have no idea how they managed to hire them.
One of the most interesting interview processes I went through was for a VFX house as a systems administrator. I had been into their offices for multiple interviews, done video interviews with their HR manager who worked in a different country, and was told that I was their preferred candidate.
Six weeks later, I was told I was still their preferred candidate. However they still did not offer me the job. I think they were waiting for me to make a lowball offer since the industry typically doesn't pay well for artists or the systems people.
Decision fatigue, one of the biggest problem of this century.
There is a lot of pressure, if you hire the wrong person, someone has to be responsible. That's why they developed a lot of processes. So if the person turns out to be the wrong person for the job, you can tell everyone you thoroughly vetted them, and it's not your fault.
From my perspective the only way is: Interview people once or twice, hire them as quickly as possible, work with them for a few days/weeks and make a quick decision (together with the person) if it is going to work out.
So, I have been hiring a lot for 2 startups i was involved one was a kind of bootcamp which involved basically a never ending hiring process.
I learned a lot about hiring there and how incredibly stupid and broken the standard hiring process is of big comps.
If anyone tells me to invert a binary tree now i just get up an leave haha.
But my main takeaway there was that this is actually a huuuge competitive edge Startups have. They dont have to adhere to the BS standard process and can snatch up a lot of good talent which falls out of the standard metrics.
> Research shows that if interview processes drag on, good candidates lose interest - and go elsewhere
I certainly would! More than one hour of interviewing is a sure sign of a diseased company that probably suffers from massive management overhead, internal conflict resulting in inability to make decisions or someone's complete paralysis out of fear of making wrong decisions.
You'd have to be pretty desperate wanting to start work at such a place. If not, better to keep looking and not waste your time.
Can't confirm. Not at all. I interviewed during COVID, around summer 2020, and really preferred the adjusted interview process. I interviewed w/ Facebook, NVIDIA, TwoSigma, Citadel, Google, Apple, Cerebras, Rivian, and Amazon. I usually got feedback a week or two after the final interview. It's quiet common in this industry that hiring managers and headhunters "ghost" you instead of sending a message if they think you're not worth their time.
This trend is absolutely ridiculous. I'm currently in "Round 3" and have FIVE interviews this week, four of which are technical. I already passed the technical in Round 2.
As someone with 10+ years experience in the industry, I've about had it with these technicals. I'm just going to start refusing. I'm happy to have a long technical discussion on my work experience and to provide you with portfolio examples. Take your hacker rank problems and get out of here.
The hiring process is fundamentally broken, but not always in the ways that job-seekers think.
It's hard to establish during the interview process that someone will be able to do the job you need them to do. Hiring them is a huge risk, both legal and cultural. It's not easy to fire people, and lawsuits/arbitration are common.
The endless interview process, which costs companies many good candidates, is there because they fear the bad ones they can't recognize.
I think the third party screening companies will eventually win here. There will be an objective measure of skill at the job, plus some culture/fit interviews.
It does seem like the obvious efficient solution hypothetically. Right now we have proxies "Well he worked at FAANG so he's probably good enough for us" on the company side and glass-door (horribly subjective) on the individual side. But really no way for extremely-qualified individuals to say "show me all job offers within X miles that pay more than $y for position $z" (closest thing I'm aware of is indeed).
That said, for whatever reason the startups that tried to be intermediaries (and also various recruiters) tend not do very well in my experience.
Just recently experienced this. Interviewed at a FAANG company, process started 5 months ago, about 50 emails exchanged, a dozen or so phone calls of various kinds. 6 interviews, they came back and asked to re-do 1 of them, which I obliged. Then, they were silent for about 2 weeks, I asked about the status and they said they want to re-do 2 more interviews. I kindly refused and they said they wouldn't move forward.
I once interviewed at a very well-known computer manufacturer, with 21 people over two full days. But it was known by all that after the two days, you got an offer or you were never going to get an offer. It was fine, no problem, I enjoyed it.
It was respectful of my time. They were serious. I felt valued.
Don’t know why today’s tech companies have abandoned something that so obviously promotes good will in the new employee as well as the one passed by.
I developed software professionally over 20 years and I get impression that I would not have survived any of these interviews. I remember the times in 90's when I had most of the Java classes & methods in my "working memory", but after that came syntax helpers and search engines. That ruined whole concept of programming with just text editor. I don't know if anyone else has similar experiences.
> That ruined whole concept of programming with just text editor.
What "ruined" it for you, "made" it for me :)
I absolutely hated my CS courses in undergrad and dropped the major after 2 classes. Didn't get back around to programming until a few years later - using Google makes it way more doable.
Actually I agree with you as I would not be able to program much without Google today. But many reported here about interview situations where they had like white paper and task to develop something. It is something they never face in real work.
I don't recognize this at all in my country (Netherlands). I have 2 interviews max. My current employer I actually had one interview with the boss in a restaurant. We had a nice chat and he offered a job on the spot. I signed and never left. As I am a consultant I ofter do interviews and I always stear the conversation to the most important part of IT: communications.
I'm starting to think these interviews are not about skill, but about resiliency. It filters out people with (occasional) physical/mental health issues, difficult/many kids or other difficult life situations etc. Which is fair I suppose, companies would prefer perfectly healthy 26 year-olds that can dedicate their life to the company without burning out.
I think "resiliency" is a positive way of phrasing it. In my opinion, it's more of a case of checking if you can fit in and put up with corporate BS.
I also doubt that companies are on purpose designing the interviews to be this long. It's probably more of the case of "more is better" thinking and no one being able to make a decision by themselves to streamline the process.
That's not about selecting the most qualified, the extra "lunch", "coffee", "working habits", "cultural fit" ..., it's a way found by companies to involve the maximum number of people in the hiring process to make people in the team feel confortable with the new hire. It's a very expensive team bounding exercice.
I've never been interesting enough to have gone through that many interviews.
I suspect that these companies have structural problems that inhibit their decision making. Possibly also personal problems.
I also suspect that if they can't say yes after a third interview then the candidate is non-judgmentally not a good fit, by demonstration. Both parties should consider that.
I actively tell career switchers to avoid coming with more then 3 rounds unless they really really want to work for that company.
I did 5 rounds over 7 hours with a top tier company recently only to loose out for my solution to one of the 3 coding tests not being as elegant as the interviewer would have liked.
I’ve been told to speak to them again in 6 months, we’ll see.
Two months ago there was a news that raised some eye-brows, "Amazon has a quota for the number of employees it would be happy to see leave (businessinsider.com)" [1]. Some of the comments were quite negative, reading it as a dehumanizing practice with no clear upsides. Re-upping my reply [2]:
The article paints a needlessly bleak picture.
The neutral reading of the practice is, "managers are able to take riskier hiring decisions, because they are given an allowed turnover rate".
Which surprisingly enough is a solution to the ever-growing worry of false negatives in hiring - i.e., overlooking good candidates whos resume or interview did not shine strongly enough, or who perhaps are from a shunned, misunderstood culture, or who otherwise did not fit the generic hiring practice prevalent in the society. This solution allows an organization to make riskier hiring decisions at a well understood rate - hopefully catching the false negatives that did slip through competing organizations' hiring process.
The issue is with setting a quota as “must” vs “acceptable”
If you “must” find a way to pick fault with your employees because you can only give out 1 “exceeds expectations” and at least 1 “meets most” then you’re likely creating a toxic environment from that.
Similar to telling managers that they “probably should” thin the herd.
In 2007 I had 13 interviews with Microsoft before finally being rejected at the last step. Reason invoked was "Not enough corporate spirit".
That was my last rounds of interviews, since then I have my own consulting company and never regretted this failure, quite the opposite in fact :)
I had fourteen (14) interviews at my current employer, with a similar "how about this position instead?" switch in the middle, including redoing a whiteboard coding interview.
I've been there 8 years and counting now, and my current job bears virtually no resemblance to what I was hired to do.
I have a lot of friends got FB offers and most of them spend between 3 months to 6 months to prepare for the interview. With that level of preparation, some of them have to sacrifice their responsibilities on their day job. It's tough. (you can read some stories from my blog).
Indeed, almost nothing is available without investing 5 or more hours of your time.
I have seen interview 1,2 plus full day on site development with senior dev for a front end job and something like 10 hours worth of assessments at FAANG.
These are not high paying jobs btw.
In-house recruiting have few incentives to provide a fast and efficient hiring pipeline.
Slow pipelines mean low conversion rates (survival of the most pain tolerant), generating more internal demand. Natural reaction to to widen the pipe (more recruiters) not speed it up.
I’ve applied to and been rejected by Codecademy 3 times. After the 3rd time I decided to build my own just to prove to myself that I could and that the interview process is broken:
I was paid $300 to complete a take-home project for the final interview round at the company I currently work at. Give candidates a 1-2 day take-home project and pay them for their time.
Outcome: You learn how they work, while showing that you value their time.
Meanwhile you can go down the street and make 70% as much money with less hassle. Companies with grueling interview processes are inadvertently weeding out people who value their time, which seems like a good kind of employee to have.
Yep. This interview process is pretty much why I'm out of the market. Could I increase my comp? Probably. But the hours of my life are slipping by, and those never come back. I used to enjoy the hours I spent learning to code. Absolutely loved it. Doing this Leetcode crap just to jump through hoops is a miserable waste of life, though.
“Google, for example, recently examined its past interview data and determined that four interviews was enough to make a hiring decision with 86% confidence, …”
Does this mean that 14% of Google hires are incompetent for their role at Google?
I run a company. When I need to hire someone it’s because I need someone to do something, and either do it now or really soon.
I have never had the time (or inclination) to do any more than two interviews
There might be a psychological part in it to seek candidates that are willing to go through degrading interview meat grinders. I am not sure those candidates would be what a humane society needs.
problem, is as an industry we're treating software engineering as a science only. forgetting it's part science part art. now you can be smart, but not be artistic. which is a major problem, google n other faangs have notorious interviews which wannabes copy. yet can't make software that works half the time.
maybe it's high time, the software industry looks at how creatives get hired.
coz after all we're a creative industry - just only using engineering principles to create art
I have a small startup. We try to be super responsive when someone applies to a job. Generally within 2 weeks of an resume being submitted we can have an offer letter to the person.
I’ve pointed out, before, that one advantage I have, is a huge portfolio (check my SO story[0]).
It’s tens of thousands of lines of code, in multiple shipping product form. All you need to do is clone a repo, hit “Archive,” and you have a built and App Store-ready app. Some of these apps are still on the App Store (most have been deprecated, over the years). I have full source for shipping apps (over 20), going back to 2012. I've been writing Swift -every single day-, since the day it was announced, in 2014, and have released quite a few apps, written entirely in native Swift. I'm working on a big one, right now.
Here’s an example of a repo for a currently shipping free app that is available as an iOS/iPadOS app, a Mac app, a Watch app, and a TV app. It’s a Bluetooth BLE explorer app (yes, you can sniff Bluetooth on an Apple Watch)[1], [2], [3], [4]. It uses this cross-platform Swift BLE SPM module[5].
All of the repos also include things like graphic asset originals (usually Adobe Illustrator). I’m a passably good designer. At one time, I considered becoming a professional artist.
All of my work is localizable and accessible. A number of my apps have been localized in multiple languages. These days, I also tend to do things like support Dark Mode.
I have a ton of SPM modules, tested, documented, tagged and available for immediate integration. I use most of them in my own work.
I have full source for a couple of server systems, that are in heavy use, today (I use them in my own work, and one is a worldwide standard, in use by thousands, daily).
I have dozens of blog posts, articles, tutorials, explorations and other online writings[6]. I go into great detail, how I design, test, architect, and think. Most of this stuff is extremely detailed, and comes with supporting playgrounds. I’m a fairly good writer. There’s a lot there, but it’s quite readable.
I have given instruction on technical stuff for years. The most recent one was a Zoom class on intro to Core Bluetooth, using Swift[7]. It was received well.
I don’t know if I have a single fork. I’m the original author of all of it. Since I have over a decade of commit history, across multiple public repository systems, that’s easy to prove. I also tend to have fairly informative (and frequent) checkins. It’s simple to see how I work. My GH Activity Graph is solid green[8].
My technical ability is not a matter for debate, it’s easy to see what I bring to the table (including limitations). I'm satisfied that there's lots of stuff I can do. I won't bother trying to claim abilities that I don't have.
Any interview should be only determining whether or not I’d get along, and whether or not I would be a good “personality fit.” Since I spent decades at my jobs, including at one of the most famous brands on Earth, that should also be easy to figure out. I could definitely see that some companies would not want me, but that should be simple to determine. I’m a completely open book. My LinkedIn profile is full of testimonials, by former managers, coworkers, employees, and open-source project partners.
It’s been my experience that all this has been completely ignored, in favor of ridiculous 50-line binary tree tests.
In one interview, I sent the recruiter links to several public repos of code for shipped applications, that pretty much exactly fit the requirements of the job they contacted me for. This was ignored. Instead, I was passed to an obviously bored tester, who gave me a binary tree test in a language not used by the open position, and I was dinged for not using a formulaic approach, unique to that language (which, did I mention?, was not the one used for the posted job). The repos that I had sent, were in the language that was specified in the opening.
After a few of these broken, insulting, awkward, hazing rituals, I simply gave up looking. It’s plain that no one wants me, and I won’t go where I’m not wanted. I'm fine, doing my own thing.
Do diversity hires have never-ending job interviews? Or are they just streamlined in?
It would be considered oppression if black candidate where given as many interviews as white candidates.
Actually it is a serious question. When diversity is apparent what is the difference in the number of interviews required?
Are white and asian males more scrutinized to make up for the logical shortfall of affirmative action hires that just get to mess stuff up while the asians clean up their mess?
Before pandemic, I was contacted by a recruiter for a position in a growing security startup for a role in technical pre sales.
It start with a call with the recruiter, then a call with the VP that sent me an exercise to make in a short time (4 days). I had a full time job, so I worked hard during the weekend and in the night to finish the task and I was not able to finish everything (just last step was missing). Then I presented everything to VP and he gave me more time to finish and last step and schedule another meeting to discuss everything.
After this time I was contacted by recruiter, that told me that I was in the very short list of two candidates. He then arrange an interview with the VP of HR and the VP of sales.
After those two interview they completely disappeared and ghosting me. I had other job opportunities, then I tried several times to ping them and they never replied back.
After 5 emails without reply, I told them that I was going to accept another job offer and the recruiter replied that this was the right decision, because the company made other choices.
I lost so many hours on this interview process that I would like to send them an invoice :)
In domains in which the underlying domain is complex, with an irreducible informational complexity, as well as rich and frequently highly significant interactions, there's a frequent emergence of faddish, or ritual-driven, behaviours. Both seek to reduce risks and accountability, as well as to increase credible signalling of traits.
Both sides of the technical recruiting transaction (job-seeking and recruiting) exhibit these behaviours and tendencies (what to wear, how to format resumes, presentation, side projects, for seekers, interviewing, tests and screens, and other filtering practices for hiring teams).
The consequence is a tremendous amount of friction, inefficiency, and fear-driven lore. Some years ago a senior Google staffer commented that they'd found a guaranteed hiring heuristic: "No". That is, reject all candidates.
My response was that if this was serious (and it was at least partially), that this was a profound sign of weakness within Google: an inability to seek out and onboard talent successfully.
There are other possibilities.
It could be that the notion of private firms hiring highly-skilled talent is inherently flawed.
I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
One of the functions of writing a book, a notoriously unremunerative practice, is as a credible signalling of skill and ability. (And of book-writing capabilities, for what that's worth.) Books are very fat sales brochures.
In a tech world in which typical tenures are measured in months or single-digit years (2--3 years being typical from what I understand), and correlations between any hiring practices and actual performance ... at best weak, there's an inherent issue.
There's also the question of equitability of a process in which employers have vastly greater access to information on individual prospects than prospects do on companies or hiring managers / management teams. George Akerlof's "Market for Lemons" suggests that more information makes markets more efficient, though my fear is that highly asymmetric information access further tilts the employment market in the hiring firms' favour.
> I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you're living in a domain in which your core competency is in constructing complex stone structures, then leaking that capacity to another kingdom or empire would be a risk.
Pharonic Egypt circa 2580 was not without neighbours and there was both trade and warfare in North Africa and across the Levant and Mediterranian, notably with Syria, Canaan, Lebanon ("cedars of Lebanon" are a significant reference, as Egypt had virtually no timber), Ethiopia, and Nubia, amongst others. There's also the prospect of defection to internal factions. The Old Kingdom seems to have been generally peaceful with little internal or foreign warfare, at least until the First Intermediate Period, which was largely an internal rivalry. But it wasn't entirely without defence concerns.
I'm very happy to admit that my hypothesis is just that, and that there's no evidence and only a very little external support, though there is some. But if you're going to develop an advanced skill that would be of use throughout the region, it might be advisable to find ways to hold on to it, and as a pragmatic explanation for what was an absolutely immense effort ... there's some sense in the concept.
> If you're living in a domain in which your core competency is in constructing complex stone structures, then leaking that capacity to another kingdom or empire would be a risk.
How? The only military use of large stone structures is as fortifications; their primary feature is that they can never move.
And Egypt isn't even known for its city walls. That's the other civilization of the time, ancient Mesopotamia.
But on top of all of that, none of that is a brain drain issue. You're talking about a hypothetical issue of loss of state secrets. Brain drain is the concern that the local population of skilled workers will all emigrate, leaving the country unable to do skilled work. It's not the concern that other countries may develop the technology to do the same things that you can do.
Building pyramids isn't simply piling rocks on top of one another.
There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
Too: once you've got those capabilities, there are numerous other abilities which derive from them. Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts, again, which can prove useful in either foreign or civil war.
Take some time to think through possiblities, consequences, options, risks, and opportunities here.
> you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits
Well, yeah. Look at my comment, in its entirety:
>>>> Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you can't defend that, then... don't? Make the argument that isn't obvious nonsense; you don't get more credible by throwing in a laundry list of "concepts that sound bad".
> There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
There would have been no lost opportunities to exercise these skills in the absence of pyramidal efforts. They built temples, palaces, and cities on a continuous basis. Surveying is a constant need of anyone who collects taxes. (And it's particularly important in Egypt, where everyone's property lines move every year to match the extent of the flooding of the Nile.)
As far as I've read, the Old Kingdom pyramids stopped being built when the colossal economic strain they involved nearly collapsed the state. That doesn't suggest that they were useful in employing otherwise idle technicians. It also doesn't suggest that the system governing them was especially capable at logistics and planning. Planning would have involved noticing "this pyramid will cost X amount to build, which is more than we can afford".
> Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts
I think this is backwards to a certain extent; I'd run causation from grain storage -> large structures, not the other way around.
I'm not interested in litigating minutia. I've addressed the point. I've admitted, repeatedly, that this is a very weakly-supported hypothesis, though not entirely without merits. Substantive proof is unlikely to emerge from a tendentious HN debate.
You're the one constructing a far more magnificant pyramid of this than I'd ever intended.
DAOs are fixing this in the crypto world. You contribute to the protocol and get paid by the DAO. Everything is transparent and open. If you do this enough and earn the respect of the dev team it could even turn into a full-time role.
Fuck these pretentious companies, almost everyone with average intelligence can work in the role and just pick things up rather than making you run through a maze just for an entry level position.
I completely broke down and put in all my sick leave. I haven't cried like this in years and I have to go through therapy and all the things. I'm going to be ohkay at least my code still works and is still making the company I currently work for a lot of money. So I am just taking some time off to heal myself and address my burnout at the same time. There is hope after falling hard like that.
During my maths phd time in France I really enjoyed so-called "colles". It was a 1h long 1 on 1 conversation with the student where (s)he was given a complex problem (way too difficult to simply solve in an hour) and a sequence of hints and smaller, easier tasks, leading to the solution. I would often help the interviewee when stuck/correct computations, let them follow the wrong path to make them realize why it was wrong and generally allow for unsupervised exploration of the task. Even though quite often students were not able to get to the end, or even close, I could get a decent idea about their knowledge and understanding of the matter. When I first did it, I instantly thought that's a good way to do a job interview -- being prepared and interactive, have a conversation instead of one way question-answer traffic.
The caveat: I needed to really think through the problems beforehand, understand other possible solutions, traps and potential dead ends (ie. spend time on it).
When a few years later I was asked to do some recruiting at my company (DS/R&D positions, not SE), first thing I did was to prepare a few sets of interconnected problems, to gauge the person's knowledge and how does (s)he think when encountering a new problem with all necessary tools at hand. The problems were difficult but I never expected anyone to actually solve them.
I did dome technical interviews as a candidate, being asked about random math puzzles/algos one can google in 30 sec and which are already implemented in standard libraries -- even though I usually could solve most of them I sincerely wish such interviewers would ef off and stop wasting my time. We are grown-ups, I already spent my fair share of time solving elementary riddles during high school math competitions and I'd like to be treated like a serious professional. During my years as a ML Engineer/dev I never EVER needed to implement a single tree/graph/whatever algorithm from scratch. Also, many adults have a life, family, other full-time job and grinding leetcode is not something anyone should be expected to do.
To be honest, quite a few times I doubted that the interviewer would know how to solve a similar problem without having the solution checked in company's interview problems database. Also, time pressure and stress are a buzzkiller.
As for multiple interview rounds -- a non-starter. Recently, while exploring the market, a top-tier betting company asked me to do a take home, 4h technical interview and then another long take-home (unpaid, of course). I told them that they are ridiculous and asked to never contact me again. I'm at liberty to do so as I have a job I'm happy with and zero need to actually change it, but if someone has been laid off I can see people get grinded to death -- both mentally and physically -- by such interview processes.
>
That’s a question Mike Conley, 49, grappled with earlier this year. The software engineer, based in Indiana, US, had been seeking a new role after losing his job during the pandemic
This is ageism. I hope he realized this after 10 6 rounds of interviews.
Ageism absolutely is a problem in our field (I've seen/heard many people even openly boast of ageist hiring practices), but I don't know that ageism was the reason in that quoted case.
Not to invalidate ageism, there are many threads about younger people's interviewing experience that match this. The competition (other candidates) are doing much more than that, and also studying and practicing leetcode much longer than I am willing to.
Well, one way that this works, is that older folks, that have gotten used to working in an environment of mutual respect, and have some modicum of self-respect, are less likely to put up with BS, as opposed to someone younger, who may have come from a ... less professional climate.
The idea is to drive out older, less-pliant potential employees, in favor of newer ones, who can be molded into a shape the corporation prefers.
Have you ever seen a couple that has gotten married later in life? Many times, it may be a second (or more) time for one or both of them.
They need to make massive compromises. Both have gotten used to supporting themselves, and keeping their own counsel. They generally both have a lot of property, maybe grown kids, careers, etc. Usually, they don't actually need each other, for more than emotional support. They each do fine, on their own. It's a relationship of equals.
It can be a challenge to make it work, but when it does, it's amazing. I have known many couples like that.
I understand why corporations don't want to put effort into working with older folks, but it can be well worth it.
So many times, when I see these awful, Jurassic-scale disasters, made by companies that are staffed exclusively by younger folks, I say to myself "That was a really great idea, but they completely pooched the release. Why didn't anybody raise any red flags?"
The answer is generally, that no one on staff had enough experience to understand the ramifications of many decisions, and often, they were afraid to countermand ideas put forth by their superiors.
Couple that with 20-something CEOs, who are often fearfully insecure, and you have a recipe for disaster.
I've been told by at least one manager that he disliked older devs because they are much more likely to push back against against poor management and refuse to put in overtime.
Perhaps, but I can say that I am over 40 and I can tell when the enthusiasm for my candidacy dies after they see my face that it's not due to anything but ageism.
and I'm in an underrepresented group, we all have the ability to conform our experiences to the reason that matches what other people say will limit our opportunities. It is equally important to weigh each experience against the similar experiences. I've seen plenty of linkedin posts and blogs about people bragging about their quests to get competing offers in tech, some interviewed at 60 companies and did 100 interviews, when my tolerance is 12 companies and maybe 15 interviews. Some did 700 hours of leetcode, where my tolerance is maybe 5 hours. The dataisbeautiful and some employment subreddits have flow charts that show similar quests to get an offer, visualizing how much rejection and time is used inefficiently.
Like I said, not to invalidate anything, these experiences are so common amongst the whole pool that it has to be weighed accordingly.
It wouldnt take me 700 hours to get familiar with all the abstract problems and concepts I’ll encounter, but it would take me a very long time to, and longer to synthesize solutions that are above average, and regurgitating that on the spot for an interview in a quicker time than other candidates.
It seems to me that ageism actually has some value.
People never got any smarter, but the nature and details of group activity have changed over time.
After a career of delivering products for boutique manufacturing companies, I'd say that my ability to pass a modern interview suite is essentially nil. My last gig for a company with modern practices taught me that it's no fun in any case as design devolves into manufacturing (perhaps for good reason).
Give me a young body, and I'd look into purposefully arcane careers with little remuneration. Blacksmithing perhaps.
But some are pulling strings like connections for them to get the job that they want. It is quite rampant, and it even gives the job to those who are not quite competent enough for that certain position.
These stories reinforce my decision to go into consulting so long ago. People hire me because they can't get stuff done, and they need it done now. We're not getting married, and I'll be gone as soon as the project/mission is accomplished. And, no BS coding tests.
Just do interviews with at least 5 companies at the same time. Pick the first which offers you the position, semi ghost others(keep them for backup), profit and no hurt feelings.
My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again.
I'm not claiming I'm Google caliber, whatever that means. Obviously I'm not because I don't have the patience for their interview questions.
To be clear, the entire question was: What's not in a Linux inode?
My answer was: Lots of things...dinosaurs, the moon...
The interviewer told me very matter of factly that it was in fact, the filename.
I honestly lost all respect for the process, sorry Googlers.