This was a good read. Many tech companies (and some non-tech companies) talk the talk about hiring from a diverse crowd, then interview them as if they're all CS bros (reverse a tree, "justify the text" bullshit leetcode nonsense, 8 hours of interviews), the exact kind of stuff that people from diverse and non-traditional backgrounds don't know and don't care about.
I agree, but I don't think this is a place where it is fair to expect developers to "vote with their feet" and not participate in these interviews. The companies who do data structures and algorithms interviews seem to pay the highest in the industry
You have to pay a lot (+ a lot of perks) to get folks to tolerate the amount of bullshit you put up with at a FAANG.
There is a world of other more enjoyable and educational opportunities out there they must compete with. And so the cash shovel must be pulled out.
People vote with their feet, and then a new generation of fresh grads are lured by the pay to fill their role. They’ll grow sick of it in a few years, rinse and repeat.
Social signaling is too important not to engage in "nonsense" on occasion. Geeks resist this, thinking that their special flavor of technical knowledge, which they alone possess, should transcend a million years of evolution that produced monkeysphere dynamics. The situation is laden with all manner of irony.
Agreed. I am quite ok with being a "fool", if it means working for a FAANG tier company and collecting FAANG tier compensation.
I am not going to disadvantage myself by refusing to participate in this on some questionable principle. While I agree that Leetcode-style interviews are not the overall best, I am yet to come up with an alternative that addresses all those issues without introducing massive new ones. So it is a compromise. And as long as this compromise stands, I am fully intending on getting the most out of it.
Exactly. Does anyone think that even "non-self-taught" programmers may remember off-hand "how to reverse a binary tree" ? Interviews require preparation. They may be terrible selecting interview questions, but neither that nor being "self-taught" are valid reasons to claim "you can avoid preparing this interview".
That's what I wondered about too.. OP knew about HN but hadn't picked up about how interviews apparently work at a lot of companies nowadays - the whole 'leetcode' stuff. Never had to deal with that, but heard plenty about it after just couple of weeks lurking on HN.
Ah well, probably goes to show that everybody picks different threads/posts to read
It also might show some professionalism and interest if the interviewee were to ask “what kind of interview can I expect such that I can best prepare?”
> not even preparing for them as they’re the predominant format, is just showing a lack of preparation.
Why would you spend six months preparing for them when you could build and launch an entirely new product in the same amount of time, which has a much higher expected value?
If you land the job, you have a guaranteed, pre-specified income. Probably a high one, depending on the company.
The massive risk of failure with launching a product should dramatically lower the expected value. Especially since most products, even if successful, won't pay as well as the corporate job.
You must be some incredible entrepreneur for that EV to be much higher. Strong leetcode skills print money with far less uncertainty than starting a company.
Not really, no. At least nowhere I’ve worked. Currently I work at a company that recently went public and operates near FAANG scale. There are some interesting technical debt issues to overcome and these are challenging. But they’re not arbitrary or capricious. Most importantly they’re not correlated at all with our interview questions, which are designed to select people with recent exposure to mid- and upper-level textbook CS problems. That is, they’re going to naturally select from privileged groups (generally white and wealthy Asians who have attended top-tier universities).
I dont agree many of the word problems on Leetcode i.e simple and medium dont even need you to read a datastructure or algorithms book, what is required is some good logic and basic knowledge of a language. Then its just the way you approach the problems so they are actually very good problems and will definitely make you think better, clever and maybe just maybe make you a better programmer. It is more like solving math puzzles in school, no one can deny the usefullness of those math puzzles in making you think hard.
I think that puts a negative tone on people with other degrees than CS, even if they have good software experience, or are older with life commitments. Jobs and interviews in past did not ask this stuff, yet it's now implicitly considered prep. It's biased towards new CS grads and young folks.
Many/most? companies needing devs do not use/need these CS "fundamentals", which do not automatically correspond with tech skills needed to do product development, at least in SaaS world.
Are they? I often read this on HN, but I'm starting to wonder if there's not a selection bias that's even bigger than I expected. Beyond the usual suspects, I've had more coding assignments for instance.
You do not need to be a CS bro to learn the basics of data structures & algorithms. If you're a self-proclaimed autodidact, couldn't you just learn it yourself?
Of course, hnewslets who get filtered by such interviews will come downvote in force.
The basics? Yes, certainly. The hyper-specific bits and pieces that show up over and over again in interviews? Not so much. Those are selected because they can fit into an interview time slot and be graded consistently despite widely varying skills among the interviewers. A lot of important and interesting algorithms are too complicated for that, but knowing them is no help in an interview. Mostly those interviews test for recent exposure (either from being a recent grad or from having the luxury of spare time) which is not strongly correlated with ability to perform the job itself and can even be considered discriminatory.
OTOH this is standard interview-curriculum stuff that people can prepare for, which is fair in its own way. Moving away from this can also put people at a disadvantage because it makes it harder to know how to prepare for interviews.
(I say this as someone with a weird background/employment history who'd be at a fair disadvantage in many respects if they had to get a normal job - but I know I can get a bit of normie cred by brushing up my algorithms at least...)
I would argue that “preparing for interview” is exactly what’s wrong. Nobody should be “preparing for interview”, especially the really hardcore technical kind of interview, unless the job itself really is about hardcore technical stuff. Most of the time the job isn’t hardcore technical stuff, and so the performance during interview has zero correlation with performance on the job.
To me the really bizarre thing is that I so rarely talk about things I have actually done in interviews. Even for system design ones, I am often repeating information out of a book that I read as that is the correct theoretical answer.
I suspect you could teach someone to pass a lot of tech interviews without them ever building a production system.
You can teach that. You can even pass most tech interviews without having ever touched version control or knowing how to use it. Maybe that's an easy thing for candidates to pick up once hired, but then so are algos you never need in day-to-day programming (like sorting), because you can simply look them up should you ever need to implement that.
It's all a bit broken. Best method I've seen so far is to sit down with candidates and pair on some code, and it's still got issues.
I have nearly 2 decades of experience and when I was asked to write a console log hello world app by a teenager and the CEO , who stared at me silently - well - I just couldnt bring myself to do it, fear of failure at such a simple task in such an OTT scenario mean I quit the interview on the spot as I did not want to know what the judgement could be.
Im not saying its right, just that it didnt come naturally to me to be in that situation.
You should not be taking an interview so seriously that you freeze under such a situation.
If you feel it's out of your control, it could've just been a bad day, but you may be suffering from something like generalized anxiety or a similar problem, you might want to look into that with a health professional.
It wasn't anxiety as much as knowing that if I faltered even a little that this particularly interviewer would say no. I had not written fizz buzz in a few years and decided that the fact I thought about it for a few seconds meant I had already thrown the interview away.
Im just saying its thanks to my instinct that I have been so successful in my life, and I have never lost anything by refusing fizz buzz, yet have attained good things.
Maybe its survivorship bias.
It goes against my rules to proceed in interviews I think don't lend themselves to the situation.
Talking about past projects selects for people who are comfortable talking at length in florid language about relatively little substance, and who are maybe comfortable exaggerating or stretching the truth.
The most substantial and complex projects I've worked on can end up sounding simple and boring when I describe them. It's not that I can't discuss the details, it's just that I'm not good at _selling_ them. I tend to stick to facts and give a simple overview of the project, and I'm never sure how to approach the gritty details. And honestly, the right choice at the time was likely "Pair a MySQL db with a cron job" or something, and that sounds really underwhelming in an interview.
On the other hand, I've heard people describe projects they worked on, and you'd have thought they were leading the charge on the reinvention of Internet. But when you do the math on their resume, they were two months out of university at the time.
Those types of interviews basically and inevitably end up being "tell me a good story". Non-fiction is preferred, but interesting fiction will win out over boring reality.
At my last interview (which happened less than a month ago), I said I used to do "stupid stuff with Raspberry Pis" (my exact words) and I got hired.
Maybe I was just lucky, but I think you don't have to be all "florid", just show enthusiasm when talking about what you did, and it doesn't have to come from the vocabulary; people can tell whether you're enthusiastic from your tone.
Focusing on the business need filled and results seems to be the best tactic here; we all hype ourselves, but if we were honest most of our work is boring "plumbing" to solve a business need. I mean, that's what we're hired to do, that's why we get paid; if we're not producing value for who we're working for, that relationship has broken down.
Most day-to-day "programming" can be broken down into that "Pair a datastore with a processor" idea, or "know enough about the problem to google/SO a fix or solution," so I don't think being honest about the mundane is a bad quality. Honestly, I think it's important enough, to make it at least a few of my questions on any formal interview, something akin to "what was a project that you thought would be simple but turned into something bigger, and how did you handle communication and management of it from that point forward?"
It really depends on the interviewer not wasting both our times and making it worth for everybody. I had candidates that weren't good sellers of their past experience, but I made sure to engage with them and they were in fact excellent professionals.
When interviewing you can ask the candidate for details on their MySQL + cron job and investigate how do they think, architect and build a solution and how much bullshit they're talking. Were you given a very detailed task to perform and you just did it? Or did you reach the conclusion that a MySQL DB plus a cron job would achieve the results? Why? What if the cron job failed? Draw a rough flowchart of your script, etc.
On the other hand, you can smell the bullshit of interesting fictions from a long distance when you ask those probing questions.
Now, an interview on basic CS algorithms? The only thing I would know is that you have a good memory and can recall the Cracking the Code Interview book.
The same thing actually applies to DS&A interviews: a person can memorize the solution to a given problem, but the interviewer can easily throw some curveballs that require deeper knowledge to handle.
It might come down to who is doing the interview: if you're a founder, or a team leader, and have done a lot of project management, you're likely to ask better questions about constraints, considerations, teamwork, etc, and get a better read on a candidate from questions about past experience. OTOH, a programmer giving an interview may not really care that much about those aspects or have a realistic idea of what a reasonable answer sounds like, and will thus tend to just jump through the interview hoops--and be more susceptible to, well, nonsense. On the other hand, they may actually be interested and invested in low-level technical questions.
I've had really good tech interviews that were challenging and even fun, and I don't think I could've faked my way through. I've never had a good experiential interview. But then, I've only ever interviewed for front-line programming jobs at large companies.
Exactly. And, just like unpaid internships, being able to invest a many hours every day into "preparing for an interview" is something that many people can't afford to do.
1. FizzBuzz, always, unironically; this easily weeds out 99% of the people who can’t program. I don’t even ask for an elegant solution, just a solution that works, in any language they choose.
2. Open question/toy problem that doesn’t involve hardcore technical knowledge, just common sense. The question is framed in a way that the candidate can grasp an actual use case - e.g. “How would you design a database for a public library?” I would explain concepts like PK and FK on the spot if needed. I even let them use the internet to look up whatever they need. The idea is not to see how much stuff they have memorized from leetcode, but to see their thinking process and whether they are resourceful and ask the right questions. Seriously, some people don’t even know what keywords, not even approximate ones, to use to Google stuff.
Resourcefulness and asking the right questions have much higher priorities on my list of things to look for in candidates.
Heh. I don't claim my method is perfect, but I believe it's reasonably better than hardcore leetcode stuff. FizzBuzz is the kind of problem that doesn't need any preparation to solve for any person who can program. In fact, if I sense that the candidate already knows FizzBuzz too well, I can skip right over it and head over to the open question/toy problem. The candidate could try to bluff me about FizzBuzz, but that's not going to help them at the open question/toy problem. :P
How else can I know that you know how to program though?
Fizz buzz is literally a couple IF statements and a loop.
As an interviewer, I need to know that you aren't just completely making everything up.
This is an actual problem. There are actually people who, for some reason or another, made up a bunch of stuff on their resume and literally do not know how to use a loop or IF statement, and there is no way to know this, unless you ask them to do it.
It is not an insult against you. It is just that an interviewer needs some small very easy check, just to make sure that you didn't completely make everything up.
> Why dont you test how I drink from a cup of water to ascertain that I am able to function as a normal human being?
> Where is the line drawn?
The line would be drawn at the place where like 20% of people who interview at places legitimately can't solve fizz buzz.
If I lived in a bizarro universe, where 20% of people that I talk too legitimately can't drink a glass of water, then I might have to test for that as well.
Fortunately, we aren't in that kind of situation yet.
> If there is 20 years of programming experience it could be perceived as an insult in my opinion.
Ok, and what about the people who put 20 years of programming experience on their resume and are just making everything up, and legitimately don't know even the basics of coding?
Thats the problem that exists in the world. That there are people who you have no way of knowing how to actually code at all, and exaggerated to an extreme degree on their resume.
How else would you suggest figuring out if the person that I am talking to basically just completely made everything up, or is instead just such a good talker that they can bluff their way into people thinking that they know what they are doing?
So what's the alternative? You can talk about work history but now you're locked out of the FAANG track if you don't start with an internship there because very few jobs are going to work at the same scale. Of course you could go learn about systems design at scale but now you're back to preparing for interviews.
You can just sit and chat like you're friends but that's going to bias the interview process to "people who I like" which is just "people who are like me".
I'm sure there are LeetCode questions that are more & less predictive of success but it does have the benefit of removing much of the bias in the hiring process, at the expense of requiring candidates to do some prep work. If you don't want to do the prep work then there are plenty of other places you can work.
I think one challenge in these conversations is that people talk about what the interview process should or shouldn't look like without talking about what the interview process is trying to optimize for. And each person is going to have different ideas of what they should be optimizing for in an interview so they'll have different interview solutions. Then you argue about the solutions but the reason you disagree is because you're starting with different goals.
being able to reason about expense & cost, being able to appreciate the path the computer has to take, has real value, even if it's not called upon day to day. it's just more pleasant working with people who bother to develop algorithmic insight.
Yes, but you don’t need to know how to “reverse a b-tree” for that. You just need to be aware of something called algorithmic complexity and big-O notation. You don’t even need to know how to determine the big-O for all the known algorithms and data structures: they can be readily looked up in reference books.
I agree that there's a lot of advanced data structures not worth memorizing and testing for rote knowledge is lame. and yet:
while there's a lot of other things I value in coworkers, and I want a diverse mix, I really trust a coworker much more who I know can reason through, can see how the code will execute, and understand what that implies, can find & state the significance.
there's a lot of here & now tests of ability in programming, to understand syntax, language, side effects, &c. but bring able to reason about runtimes, about this then that then that... it's the bigger picture. we have some pretty basic promise questions in our interviews, & it's so remarkable how many people get cut for now being able to understand sequencing, how a little async behavior trips so many up. not quite the classic algorithm test, but to me, they seem extremely similar in that they want the dev to be able to order & comprehend how things work.
I agree that a lot of pushback against algorithms is deserved. they are misused as a hiring bar frequently. but there is also things I value a lot, & they help elaborate whether a dev grasps coding situations or no.
Wouldn't that just be interviewing a candidate based on their capability to prepare for interviews and not actually interviewing for candidates who would be effective at their jobs once hired? Could this be a false assumption that these are correlated, or a decent indicator of one over the other?
As an honest question, why do you want to work for places who interview and hire so pedantically?
As a person with a diverse background and even more diverse interests, who likes to use jobs to learn things I don't know rather than simply apply things I do know, I use interviews as a natural filter. It can be rather unpleasant and frustrating at times, but in the end, it's better I don't work for some place that interviews like they got their process out of some Silicon Valley playbook.
Who said I did? I don't particularly; I'm self-employed and have been for a long time.
When I see people getting all het up over technical interviews on various moral grounds, one notes that they often forgo reflecting over the possibility that any replacements could be even more bullshit/arbitrary/exclusionary.
Yeah ok, makes sense. (Apologies for making you spell out the question again; I could've probably inferred what you meant and answered that in my earlier reply).
I have a history of self-employment and little formal education in programming per se. It might put potential employers at ease to be able to exhibit some conventional chops, and that kind of interview segment would give me an opportunity to. And algorithm-questions being more or less role-agnostic might mean less preparation rather than more for interviews when one is doing a bunch. OTOH if you want a particular role you should probably better brush up on what's needed for that role and show each application you make some individual love rather than hoping that you can carpet bomb tech company interviews in your city with algorithm-knowhow-powered interviews and get a job out of it.
Given how theoretical this discussion is for me, I feel like I'm slipping into being some kind of devil's advocate role now. I would like to apologise to anyone (basically everyone else here will have more experience with tech interviews than I have) who's reading this rolling their eyes.
No worries. I was basically just using your comment as a jumping point to say what I wanted to say anyway, as one does. Haha.
My experience has been rough and painful at times, because I tend to be very pragmatically and interest driven in terms of what I learn, outside of being pragmatic about what might be asked in interviews. I also do not have a computer science degree, as I studied mathematics, but I self-study on interests of mine and take interviews as they come. This has made interviews rough at moments, but it's worked out so far, because I would likely be very unhappy at a place that quizzes me on something I could learn over a weekend or two if needed and grades me solely on that. I had one particular interview that wasted an hour and a half on tree questions, then a few more hours on random discussion topics and behavioral questions, and they never once asked me about prior work or side projects. It was a complete waste of time and energy, for both of us, and I have held that interview experience as a prime example of what I have read about Silicon Valley and FAANG-style interviews.
> Moving away from this can also put people at a disadvantage because it makes it harder to know how to prepare for interviews.
This just proves that you can memorize a cheat sheet. What good is having interviews if they are so predictable that the applicant basically just repeats himself over and over again? That isn't an interview. That is gatekeeping. "Do you know the secret handshake?"
I don't know the entire multiplication table by heart, but I know how to multiply. But that's not what interviewers are testing for. They basically want to see you rattle off a chart from memory as though that's a non-arbitrary universal indicator of capability.
A skilled interviewer can take the classic CS interview questions and combine them or take them in unexpected directions. Memorizing the solutions won't help with that, and it'll quickly become clear if your understanding is shallow.
Of course, that doesn't really change the fact that the content of the questions has little to do with the work you'll end up doing. But I've done brainstorming with coworkers, and none of us had any ideas for interview approaches that would work better--except maybe those 2-day take-home projects that everybody hates. I think I remember a paper claiming that random acceptance would work about as well as the current interview process.
I have come to totally agree with this. The leetcode interview process actually disadvantages experienced professionals and advantages inexperienced upstarts with time to study.
Yeah, it probably is a good proxy for agism, given how well it correlates with university material that will very naturally rot from disuse (in most programming jobs).
I don't really get why "reversing a binary tree" seem to be used as an example of what's wrong with hiring. I will say, though, that if someone said "how do you reverse a binary tree?" I would have asked the follow up question: "what do you mean by that?". If asking that would be used against me, sure, that's bad hiring.
But if the answer is: "swap all the left and right nodes in a binary tree", then... isn't that pretty basic programming?
It's funny, I've heard "reverse a binary tree" as the canonical coding interview algorithm question for over a decade and I've never stopped to think about what it actually involves. But I just Googled it and it seems like you're right...and yeah I feel like if you know how recursion works and you know what a decision tree is, it seems like a pretty trivial question.
It's a common joke interview question. I don't think anyone has acutally asked it?
I find high end jobs tend to ask some form of problem that can be tackled using dynamic programming techniques. Maybe couple of easier ones in the first interview.
I agree with most people. I never use these skills in the job. I think they're a intelligence test in disguise.
Oh, if it's just a joke that went over my head then that totally makes sense! Though in fairness there are apparently-serious interview questions that are even easier (e.g. FizzBuzz, though I don't think anyone asks that anymore either) and I've been asked interview questions that aren't much harder.
I mostly agree with your impression, though even after adjusting for intelligence I bet there's a positive correlation between knowing how B-trees work and, say, having a good intuition for how to index a database.
Maybe you’re passing it to some other function that doesn’t do that, or you don’t want to add some ordering flag to the datatype because that complicates things.
But the purpose of the question of course is to be an easy question showing basic competency in recursion and pointer usage.
Sure maybe at banks or companies where IT isn't a core focus but most tech startups and medium sized companies have taken the Leetcode cargo culting to heart
I've always wondered if these companies have data to support their hiring routine or if it's just a filter to convert an overwhelming number of applicants into a pool that's manageable?
On the other hand, reversing a tree and problems like fizz buzz are pretty low bars...
To piggyback on this solid comment, a lot of times it’s us engineers who can fix this. I sat on L5 hiring committee at Google for a while and I really believe what diverse-background candidates need is more support at HC. I could sell these candidates to the committee often, with minimal effort all they needed was a champion at committee. That can be you, dear reader, at many of the big tech companies.
Mostly HC is a ton of work (eg read 8 full interview packets a week) so if you express an interest and are a decent interviewer you’re likely to get shot at it and you can make a real difference.
Leetcode interviews are exactly how I, as someone from a non-traditional background, got a job at a tech company.
I didn’t need to know 4+ years of CS curriculum, which I never would have learned on my own. I just needed to spend some time learning algorithms and data structures, and practice using free resources on the Internet.
A pretty good deal for non-people who didn’t study CS in college.
In fact, someone who studied CS in college might be slightly miffed that they offered a job to an outsider like me just because I practiced data structures problems in my free time.
I honestly didn’t really think it was all that interesting a read. Author burned out developing new products after an angel round “ruined” their company. Author wouldn't work at FAANG for “idealogical” reasons. Author doesn't know basic data structures and algorithms and applied to companies that index on that type of skillset. Author’s tool belt is Windows and they’re looking to join macOS shops.
It’s a string of poor decisions/planning followed by an unproductive rant. I don’t particularly like leet code style interview questions either, Author could take a few months and brush up if they’re a proficient engineer or if they’re really opposed then pre-filter companies based on their interview style. Author could find a corporation outside of FAANG that isn't idealogically abhorrent. Author could look for windows shops. Author could consult (sounds like they’ve been successful with this approach).
I suspect the author just isn’t that great of an entrepreneur and tried to pivot into a high paying engineering role they just aren't really qualified for either.
I agree about the SF observation at the end. If SF culture isn't working for you then explore elsewhere. I wish more people realized this before assuming they need to be in the bay area to be successful. It’s a pretty limiting and potentially damaging assumption and I’ve seen people get super distraught about the idea of being anywhere else because they drank all the VC urban tech hub cool-aid and are just starting to come down.
I couldn't help being struck by "I needed to take a break and get over my burnout." Must be nice... I've been continuously employed since 1992 because I've had no choice but to be continuously employed since 1992. Burned out or not, the bills don't stop coming: if you're in a position to "take some time and focus on yourself" in between jobs, you're in a very fortunate place.
I learned CS fundamentals after graduating with a non-CS degree. It was hard, but I enrolled in a few classes through Harvard Extension School which provides access to Harvard classes to anyone and self-study.
CS fundamentals have a big impact on the kinds of programs that individuals can write. Asking questions to show that a candidate can write a DFS, leverage multiple data-structures, or do X helps ensure that the individual is capable in this regard. Even for experienced candidates with lengthy portfolios you may find that someone drifted into an operational, management, or product role and has forgotten how to effectively program.
However, the format of the whiteboard interview is awful and if one doesn't practice for it it won't turn out well. I'd love for there to be an alternative, but the other options all have their own cons.
1. Take home tests/projects
- Requires the candidate to invest time which they may not have.
- At scale this process is easily gamed.
2. Github projects/portfolio review
- Many candidates don't have time to work on open source
- The median github project has a low code standard, and is usually made for the purpose of learning something new.
3. Pair coding
- Many candidates hate pair coding, personally if a company mentions that they do this in day to day work I will not work for them.
- Difficult to calibrate.
The only alternative I've seen is a "functional interview". Where the candidate is given sample code reviews for standard applications or a broken program to debug.
> CS fundamentals have a big impact on the kinds of programs that individuals can write
Sadly, there seems to be very little correlation though. I've known programmers who graduated from a top CS school with extremely strong CS knowledge, who still write barely comprehensible code. And vice versa, people who have never been taught big-O, but who write the most maintainable, well-reasoned code I've seen. Most programmers aren't building e.g. databases, but writing software that provides business value.
Take home tests can be ok, as long as they are limited in time (<2h). I was adverse to pair coding, but found it to be not as bad as I thought, unless it's 100% pairing all the time. Well, whatever the solution, I think anything that's closer to what day-to-day work at a company looks like is going to give richer feedback/signals than whiteboarding.
Fresh graduates from university are a poor sample of top CS skills as they often lack practical knowledge of software engineering required to be productive. However this doesn't show that an individual with a strong knowledge of software engineering but mixed CS would be highly productive.
Also for #2 currently the company I work for is 'everything you write is ours'. Now in practice they do not really care but I really do not want to go through the months of BS paperwork (and yes it is that bad) just so I can put some project I have on github. So at this moment my github is mostly just 'git' fiddling things. Where I use it to fiddle with remote git, or some weird thing I got git into and how to fix it. No real code there at all. So everything I have is private.
I'm not necessarily agreeing with FAANG hiring practices here, but your comment is a classic example of the "racism of low expectations". Arguing that candidates who are "diverse" can't pass the same tests as a "CS bro" is no different from arguing that voter registration laws are racist because black people can't afford the internet, phones or cars to get registered. You're revealing quite a lot about what you think about "diverse" people without intending to.
I disagree completely. As someone from a non-traditional background, I think CS interviews dramatically increases the opportunities for me. I can’t change my background, but I can prepare for coding interviews.
I can’t help but feel that people who think otherwise have never worked in literally any other field for any amount of time. Like it or not, you have to narrow down any candidate pool to like 1% of applicants before doing any sort of in person interviewing. Most places do this by only hiring people with degrees. If you’re talking about a job that’s going to pay as much as a software engineer, you can probably get away with only hiring people from elite universities, or who have connections within the company.
Frankly to me the author comes off as arrogant and entitled. He feels he shouldn’t have to prove his worth because... he ran a failed startup? Then when his friends give him a job, literally the definition of nepotism, that still isn’t good enough? What does OP want? A system where only the best jobs are gained by nepotism?
> the exact kind of stuff that people from diverse and non-traditional backgrounds don't know and don't care about
This attitude is condescending towards those that come from diverse and non-traditional backgrounds, most of whom are perfectly capable of learning and developing an active interest in these subjects.
I read the blog, and see it as a failure to prepare on the author’s part. I HATE the software engineering interview process, but like any good engineer I do some research and prepare. I have to re-learn the graph algo implementations every time I interview for a job that has that kind of process. The author seemingly did not study for something they could have been prepared for.
While the digital nomad lifestyle is attractive, I'm always bemused by people on HN who are concerned about burnout, but also don't even seem to consider the non-coastal US. It's a less drastic option than leaving the country entirely.
A lot of the annoyances with SF companies just go away (of course, there are new problems too). Nobody will ask you to implement a red-black tree from memory, you can consistently work under 40 hours a week, and interviews are more focused on behavioral questions and project experience. If you're ok with a salary in the low 6 figures, it's really not bad.
Just want to throw it out there. Sure, you have a sub-six-figure salary in different parts of the country, but your rent/mortgage for a similar sized home is a third. Compared to Cali, your taxes are less too in most states.
While your absolute salary is less, your purchasing power is far greater compared to SV, SF and LA. I know someone is going to pick some outliers like NYC, Seattle and so forth. There's still more places to live than that.
People have also gotten rich off the lottery. Doesn't mean that's something you should always bank on. People have different lifestyle desires with various degrees of risk tolerance. There are different locales that benefit to different lifestyles. Understanding that difference allows people to live happier lives. Everyone catering to one lifestyle because a handful of people like it is not exactly ideal for any society.
A lot of the jobs (barring remote) in non-coastal US are for non-tech companies. There's a definite cultural difference between a company whose product is software, and a company whose product is -something else-. The article's comment about tech being the new factory workers rings true, but more true for that latter case, where devs are a particular kind of cog (a notably expensive one to boot), rather than a valuable asset.
Though that's probably less of an issue if consulting.
Or less, but agreed -- the quality of life is so much higher. Can you imagine a world where you don't have to fight traffic or step around human feces or discarded needles that were helpfully provided by the city?
Sure, you might end up moving in a year or two when the job plays out, but you can just move to another non-coastal town. Be flexible and follow the jobs, and you'll see more disparate types of environments (and learn more about how different people think) than you ever could. You can learn pretty much everything there is to learn from a given team in less than six months, so looking at it as a consulting or training gig (even if it's a full-time job) can give you a much stronger resume. (Bonus, you learn people skills from dealing with people from many different regions and backgrounds.)
A guy with a proven track record of delivering on a deadline and he is getting passes. The thing that would make the most sense in this is they saw he would not be happy in the roles he was applying for.
This is what I would assume too. I remember sitting next to a manager's cubicle at GE and hearing him discuss candidates. He would say things like, "Wow, this guy applying for this entry position has a PhD, he definitely would get bored and leave quickly." These places just want to fill seats at max capacity and turn over just means more work.
Unfortunately this is the "dark side" of entrepreneurship, and people show be made more aware of it.
We all love to open HN and read the new PG essay and dream "I am the one", but the odds are not in our favor.
The extreme survivorship bias also doesn't help.
But honestly, I don't know what the ideal solution is.
Even though I read stories like these, hear all about how the odds are stacked against, how difficult and hard it can be, I keep wondering a simple "What if?".
I guess you could say that there can be a 100 reasons not to do something, and yet one good reason why is more than enough to offset the 100 bad ones.
I think one also has to be a little bit "crazy"/"idealistic" as a person to be a real entrepreneur. As a realist (coder) in a tiny startup I know I could never run it like my CEO. He may not be the smartest guy but man does he have belief in the idea. If I were in his shoes I would have given up 1 year ago and bankrupted, but he kept investing his own money and now he might actually get it sold for big cash.
I didn’t see anything saying that the author had a CS degree. I’ll be frank, we get a lot of applicants with no degree who claim to be “self-taught”. Because teaching yourself isn’t really accredited, self taught can mean anything from a genius level programmer who was too cool for school and cranks out amazing stuff, to some bootcamp grad who read some stuff once and went through some tutorials and thinks they’re now ready to start touching our web scale systems. It takes too much energy to sift through the bullshit and in the end the ROI isn’t even worth it because we don’t need a prodigy we just need someone who we can trust to do decent work.
A CS degree isn’t hard to get in the grand scheme of things, and not getting one is basically the equivalent of burning your boat and going all in to whatever alternative path you choose, because if you fail you’ll just end up unemployable later on.
Think about it. 20 years ago? They were hired in simpler times, when people weren't even sure if the internet was going to be a big thing yet and if anyone could even make money off of it.
That probably wouldn't fly as well today or going forward as the field matures. Get your CS degree.
Given that we can expect a rising degree of risk adversity and narrowmindedness as the tech industry ages into something resembling other major industries, it would probably be a good idea for the readers to take xwdv's advice even if they disagree with the ethos behind it.
If having an unrelated degree on the resume puts those people into the "consider" bucket automatically, that is also the wrong approach.
To be honest, I can see requiring a degree for certain positions. But given the work most software devs are doing, I'd be happy to consider 4 years work experience. The number of times I need someone to invert a binary tree so far is 0, but the number of times I've needed someone to build some basic CRUD functionality following a UX spec is too numerous to mention. I don't need my degree to do the latter; I don't need to hire a degreed person to do it either. And even things that a degree might help with (recognizing an O(n^2) implementation when an O(n) is available) are lessons you can learn pragmatically by doing (i.e., having senior engineers point out issues in code review).
I'm sorry for all the people who downvoted you, but this is just a practical fact. You may think the CS degree is utterly useless, that they teach you extremely outdated stuff that you will never use in practice, that it's just elitism in all but name, a way to filter people with economic resources, etc. etc.
And I agree with almost every opinion you may have on this; but the thing is, it is just harder to come by a decent opportunity without it. Nice that you try to set your foot in the door here politically, but the cost for that is being on a crappier job.
No, not really. There are plenty of people who did not get a CS degree, for a variety of reasons, who can still be competent and help your company.
If someone has a legit work history in our industry, but no CS degree, and their resume otherwise makes them look like a good fit, you should interview them. At worst they are terrible and you waste a few hours of your time.
At the very least if you don't have a CS degree, you should be able to demonstrate CS-knowledge by prepping for basic whiteboard interviews.
Imagine what this guy looks like from the hiring managers side. Would you take the risk of hiring him for a software engineering position? Do you have any confirmation whatsoever that he can even write a single line of code? Yeah sure, he founded a startup, but you literally have no idea who wrote the actual code there or even if anything functional was even produced. Maybe the reason the startup failed is because the software was incompetent.
I get it. We all hate reversing a binary tree, and most likely we'll never have to do it in day to day work. But here's the thing, almost anyone who can reverse a binary tree on a whiteboard has basic competence at writing code. The reverse isn't necessarily true. There are lots of great coders who aren't good at whiteboard interviews. But hiring managers don't care about false negatives. Bad hires cost a truly staggering amount of money, overlooked candidates cost virtually nothing.
When I hear or read about people who are failing to get SWE jobs, it's usually because they do not have any demonstrable credibility of basic competence at writing code. To get a seat at the table you must bring at least one of the following: a pedigree, a network of credible people who can vouch for you, your name publicly attached to a successful project or the ability to crush whiteboard interviews. A manager that hires somebody who meets none of those criteria is taking an enormous risk.
> A CS degree isn’t hard to get in the grand scheme of things, and not getting one is basically the equivalent of burning your boat and going all in to whatever alternative path you choose, because if you fail you’ll just end up unemployable later on.
I wouldn't go that far. While the work involved may not be that hard, a CS degree may be inaccessible or a poor fit for many people.
That said, I agree with the premise that it is hard to evaluate self-taught individuals. It is far too easy to have gaps in knowledge if one doesn't approach their studies systematically, it is difficult for the learner to assess their own learning without a realistic baseline to compare against, and too many businesses oversell the quality of their programs (e.g. bootcamps).
> A CS degree isn’t hard to get in the grand scheme of things
I’m not going to call it hard quote yet, but I’ve been a bit shocked at just how much the university process is designed specifically for 17/18 years olds prepped and groomed the past few years for it. There seems to be little at all in the way go good education options for working adults and what little is directly targeted at that demographic, even from otherwise legitimate schools, feels extremely (I’d be happy to expand in this but I want to keep this comment short-ish)
What about other degrees? physics or math come to mind, they're probably self-taught at software engineering but they may have a problem solving and abstraction oriented mindset that far surpasses any ability to solve leetcode problems. They still shouldn't pass your initial screening?
Gets into tech interview, asked a question he doesn't know the answer to and DOES NOT RESEARCH THE ANSWER FOR THE NEXT INTERVIEW?
Now I'm starting to understand why the startup and game failed. Sure, reversing a tree is arbitrary. However, when there's a 6 figure job on the other side of that arbitrary line... it's probably worth learning.
I felt the same for a long time till i started solving leetcode problems, what he really needs is to solve a lot of problems on leetcode instead of writing this blog.
Change the strategy. These days, HR people are hunting for deveopers of any kind. Make yourself a nice LinkedIn profile, put all the correct words there, DO NOT emphasise that you are currently unemployed...
... and when the inquiries will inevitably come, just politely reject doing interviews with code questions, etc., and turn on the offence! Ask them yourself about the task and if it might interest you enough, so you will be motivated to work on it. Your ideal interview should be more about THEM, not about YOU. It might take a while to master this skill, but used right you can totally dominate the interview process and hire yourself into almost any company which is desperate for developers.
No, they are not. The whole reason there is a perception of a lack of developers is the screwy criteria and process applied to applicants.
I'm a developer with more than 30 years experience including some well known products from big companies. The same is true of my circle of friends but only two still have traditional tech jobs. The rest have gone independent out of necessity.
The biggest mistake people make when I give a coding question is not asking for help, even though I always tell them to treat the question as collaborative and use me as a resource. While I’ve been on interviews where the company expected me to code with no help, usually the culture at those places wasn’t a good fit anyway.
All that to say I’d suggest candidates be more willing to ask for help. Interviewers are people too and if you can code a solution easily after getting unblocked they might forget you ever asked for help, or respect you more for it.
I sympathize quite a bit as a fellow engineer from a non-trad background -- I solved this problem for myself by just biting the bullet and obsessing over getting good at the rote questions we're forced to answer. A nice side effect is that it has made me a better software engineer in some ways. I'm still working on it however, can't seem to shake the intra-interview jitters. I'd be interested in reading more about your swap to digital nomadism.
> Or certain questions about complicated SQL queries (I use an ORM, rarely do I need to write a query by hand).
This doesn't really seem unfair as ORMs stop working at a certain level. He seemed to have been targeting companies doing more complex things than he was previously doing.
That's really part of the problem of doing a bootstrapped or early angel type startup, and I definitely feel this guys pain. You spend years doing very shallow work because you simply do not have the time or money to dig deep into any given issue until it actually crops up, at which point you do the bare minimum to fix it and move on. Repeat this process until you fail to find a viable business model, or find a viable business model at which point if you're really lucky you can start slowly rewriting your app piece by piece, but more realistically you just accept that it was good enough and keep doing more new things.
This skillset just isn't that useful to a large software shop.
I started software development in startups/innovation teams and this is the reason I am telling younger friends who have yet to graduate to go for the big companies.
Startups are fun. I work at one now. 3/4 software engineering roles I have had have been startups. But all the work I am doing is also very shallow because everything is a fail fast timeboxed sort of thing where you work across a large spectrum of stuff and I will eventually need to change that.
One of the non-obvious challenges with doing a startup is that the majority of your work is spent slogging through boring, non-complicated tasks.
You’re simultaneously doing some of the hardest work of your life but also watching some of your skills atrophy simply because you’re spread so thing across so many different problems.
Startup founders tend to make good product managers or cross-discipline engineering managers for this reason, but it can take some time to slide back into the groove of deep technical work in specific domains.
That struck me as a red flag too, I wonder if he's really getting passed because his experience is all on stuff thats too small scale. Regardless, it doesn't sound like he actually did any interview prep, so it's not surprising he's getting negative responses. Even people who love this stuff have to brush up on the areas they don't frequently use (for work or fun).
A failed self funded video game project is a microcosm of the pain felt by bootstrapped founders that don't make it against their competition (VC funded or otherwise).
Just putting it out there. Windows is a bad dev environment. Learning basic sql and basic coding tests is sort of expected. Honestly I'm not sure if it was the interviewers that were being narcissistic given the broad brush strokes you paint with. What do you think they're perspective actually was?
And that's exactly why your experience was the way it was. HN is a self-selected crowd with a very specific mentality. Unsolicited advice: try a traditional job search website and look for companies outside of California and NYC. Your experience will be drastically different. I'm not saying it will be awesome every single time, but there will be more diversity in approaches to interviewing and in personalities.
Yeah I agree. You'll have better luck if you just go to indeed and apply for something that interests you. My most awful interview experiences have been from the jobs I've applied to on HN Who's Hiring or Stack Overflow's jobs board. It's clear the kind of people they're looking for are the hardcore CS types and not the casual (but highly experienced) business application developers.
Also - sometimes you just need to get your foot in the door somewhere that's not too picky and caters to what you're looking for but pays slightly lower than what you want. Then prove that you're actually as good as you say, so you can ask for a raise. I did exactly that with my current employer. After 4 months of being there and proving myself, I asked for a 35K pay raise (about 27%!) and got it almost instantaneously.
Honestly I've had such good luck with indeed that I haven't bothered to look elsewhere. I think there are some competitors like Monster and Glassdoor. I've heard good things about LinkedIn, but I find their platform to be extremely intrusive so I personally avoid LinkedIn altogether.
Hmmmm. The article drips with anger and cynicism, and hints at a few bitter opinions like "...companies I had ideological issues around..." It's hard to judge someone from an article, but if 5% of this sentiment bled through in an interview, I'd take a hard pass too. I just don't want to work with difficult, unhappy people.
It's a strange tone to take? The buried lede is: "[I] travel around and work as a digital nomad. I've been doing that for a couple of years now and I work an average of 2.5 days per week on machine learning or web projects and have rebuilt my savings and my whole life."
That sounds incredible! Like, the article should be titled "I'm winning at life".
yeah it's much much less about being an entrepreneur and much much more about not having professional software engineering experience / work etiquette.
Most scale up / startups would love ex founders to help them.
>Hmmmm. The article drips with anger and cynicism, and hints at a few bitter opinions like "...companies I had ideological issues around..." It's hard to judge someone from an article, but if 5% of this sentiment bled through in an interview, I'd take a hard pass too. I just don't want to work with difficult, unhappy people.
I find a sentiment like this pretty scary. Being competent at a job is not relevant, but just whether or not the interviewer subjectively likes you.
I don't disagree, but have you never worked with a person whose personality was a clash? It's a nightmare. I've quit jobs just to get away from people before.
One of my top criteria for accepting a job is whether I like the interviewers.
I'm not hardcore in the "asshole geniuses should die" crowd, but if you are a miserable person to be around, go find a job where you work solo. Don't drag your whole team down.
This topic has come up a few times on hn, and I always find myself in the minority. At my previous job, I never considered likability, and ALWAYS considered what contributions someone had to offer. Whenever I bring that frame of mind here, I always get a lot of push back. "People just want to work with people they like." It's clear I'm the outlier in this opinion, but if you're just working with people you like, you're not really a business, at least not fully. You're at a social club, too.
I get what you're saying, but you spend 40+ hours a week with the people you work with, so the social stuff matters. If someone is really good at their job but a complete asshole to their coworkers, nobody is going to want to work with them, which will likely end up being a net negative for the company's productivity.
Likability doesn't have to mean they will be your best friend. It can just mean they aren't a colossal jerk. I would probably call anyone who is considerate & constructive "likeable".
Do you tend to have emotional responses to the behaviors of others, or do negative behaviors roll off your back (like so much water off a duck's feathers)?
Most people feel bad when people act like assholes. Feeling bad enough, frequently enough, is cause for changing jobs for most people.
I'm confused by "you're not really a business". Are you the business owner at most of your jobs? Or do you tend to identify with the business you work for, sort of letting your ego merge with that of the organization during working hours?
I think saying "you're at a social club, too", is not a right way to frame it. A place of business is by definition a place where people are doing things together: business is social. Most people want to do social activities with people they can at least tolerate if not enjoy being around.
Now, if you are not of such a psychological make up that it really matters to you who you spend the majority of your waking time around, and you're able to compartmentalize strongly, then, it makes sense why you would be in the minority on this subject.
I think it could be important for you to realize that this is not really a matter of opinion in the sense of "a perspective on things that can be changed by experience or new information". This is really about folks' fundamental psychological make up.
>Do you tend to have emotional responses to the behaviors of others, or do negative behaviors roll off your back (like so much water off a duck's feathers)?
>Most people feel bad when people act like assholes. Feeling bad enough, frequently enough, is cause for changing jobs for most people.
So, I definitely get a bit ruffled when people are assholes, but I've also never found myself in a job where I can't at least push back on rude people and stake out some boundaries. In other words, I may not like interacting with some of the mean people, but I can find a way to work successfully with them, and ideally, even get past initial difficulties. When someone is dysfunctional enough, I frankly try to find ways to avoid that individual. Usually, if someone is that dysfunctional, everyone in the business knows it, and are trying to avoid them all the same.
A big fear I have is the distinction between a "truly dysfunctional person" and "someone who the interviewer didn't like during the interview." At least in my experience, first impressions aren't worth very much. And despite the fact that they aren't worth much, I've seen a number of people act as if their first impressions contain accurate and valuable information.
And, I suppose the point I'm trying to make is that I'm very afraid that someone will not like a good candidate during an interview, but would actually like them quite a bit once they actually got to work with them. I've actually just watched this scenario play out at my most recent job. Me and my team members interviewed a candidate who was very quiet and very shy. Those team members did not want to hire him because they were afraid he'd be a "poor fit." From talking to him, I felt that he seemed to be very intelligent, and so I vouched for him heavily. In hindsight, this has gone very well: he's one of the most productive members of the team, and is generally well liked. At worst, he hasn't had any conflicts with anyone. If I had not stepped it, it is unlikely he would have been hired, simply because people did not like his personality.
>I'm confused by "you're not really a business". Are you the business owner at most of your jobs? Or do you tend to identify with the business you work for, sort of letting your ego merge with that of the organization during working hours?
This is something I've struggled to articulate well, but I suppose I'm drawing a hard distinction between "accomplishing a specific work function," and "really liking a person I work with." Now, I'm not blind. I understand that there is some correlation here: a team of people who hate each other will generally be less effective than a team of people who all get along really well. I guess what I mean is that it feels to me that people are heavily prioritizing friends over function. Or, that people believe (incorrectly in my view) that if they find somebody disagreeable, it will be impossible to resolve differences and develop a good working relationship. In other words, the whole point of a business it to successfully complete some set of tasks. (build a thing, provide a service, etc.) I feel that if you too heavily prioritize working with people you like, eventually you're putting your social preferences ahead of actually running the business. In other words, we can all agree that all things being equal, a team of people that works well together will be more successful than one that does not. But what about a team of below average people who like each other a lot, vs. a team of brilliant geniuses who aren't much fun to be around? Clearly the choices between these two options will not always be that cut and dry. (and I've only provided a cut and dry example for the ease of explanation, not because I feel it is the most common scenario.) But, I feel that sociability is overemphasized because it preferred, not nec...
What if your colleagues are condescending, rude and actively trying to sabotage you?
Cooperative work needs some form of positive bond, trust and feeling of being part of a team that looks out for each other. It doesn't need to reach 'social club' levels.
Truth is, you either have a cooperative unit or have smaller cooperative factions within the team that are competing or adversarial.
You don't want the second type of nonsense at your workplace.
Maybe you've not seen it in practice and that's why it doesn't make sense to you.
I tend to fall closer to your view, but there is a difference between professional and asshole. I don't need to or even want to be best friends with my colleagues, but at this point in my life I also refuse to deal with assholes no matter how smart they (think) they are.
So when I say likability matters, what I'm saying is I need this person to be professional enough that we can work together day in and day out, and I don't want to routinely punch them in the face.
Definitely a defensible position, and one I agree with. This is not a rebuttal your point, but to the general conversation I would add: we should strive to be able to work well with people we dislike. (and where possible, strive to find ways to like those people too.)
Both are important. I don't want to be saddled with someone who's incompetent or someone who's an asshole. I spend more time with my colleagues than I do with my family, and I want to enjoy that time.
What, so we should all tolerate disagreeable people just because they can lay down a few lines of code?
It's not "whether the interviewer likes you", it's whether you can work with other people without taking an emotional toll on them. And it is as important, if not more so, than their ability to program. It's certainly a harder thing to teach.
(as for this specific quote, I think it's fine to have issues with what companies are working on... But the rest of the article really does just come off as bitter and angry, and for what?)
Are you suggesting a person’s attitude doesn’t matter at all for how they perform at work? Very few employees are hired and then don’t have to interact with anyone. If a person is a brilliant programmer, but pisses off everyone they work with and drives other employees to quit, they are going to be a net negative.
> whether or not the interviewer subjectively likes you
Yes, because we've been burned by this in the past: firing somebody who's impossible to work with is WAY more difficult than just not hiring them in the first place.
I don't place any judgement on the author at all. Programming since he was 12, started a company, self taught developer & data scientist. He's been extremely busy, is clearly motivated, and on paper should be extremely hireable. But he's getting dozens of rejections over whiteboard interviews, so he's probably wondering "am I actually just getting rejected for not having a CS degree", which is an extremely frustrating thought when you have the experiences he has.
The digital nomad life is probably somewhat relaxing, but he's clearly someone who values his accomplishments over his experiences, so I'm guessing that's why it wasn't the focus of this article.
> The digital nomad life is probably somewhat relaxing, but he's clearly someone who values his accomplishments over his experiences, so I'm guessing that's why it wasn't the focus of this article.
Ooh, that hits in a soft place for me.
Therein lies all of the angst, unsettledness, and general escapisms of this post, and more probably the world. I've seen the happiest people on earth do so very little compared to traditional 'success,' because they mastered what they 'valued' first... then pursued it relentlessly.
Here's piece from Hunter S. Thompson (don't know if you really want to emulate all of his teachings), that gets at the heart of this values orientation:
"The answer—and, in a sense, the tragedy of life—is that we seek to understand the goal and not the man. We set up a goal which demands of us certain things: and we do these things. We adjust to the demands of a concept which CANNOT be valid. When you were young, let us say that you wanted to be a fireman. I feel reasonably safe in saying that you no longer want to be a fireman. Why? Because your perspective has changed. It’s not the fireman who has changed, but you."
If a CS degree just let you invert a binary tree and do convoluted SQL queries, then arguably it is a quite poor CS degree. Maybe some interview questions/exercises are, as often, let's say not perfect. Or maybe they are good enough for most candidates but the people asking them are failing to see other competencies when somebody fails at boring / specialized tasks but could bring value in other ways.
Exposing yourself to what you consider your community of peers and being considered inferior is demoralizing. Even if he is winning, or you imply sarcasm, he felt minimized by a system that doesn't make sense to him (and many other software developers).
Yes. When I read 'I was unemployeable' I thought it meant: companies wont hire me. But actually it meant: I cannot stand working for companies (anymore?).
> The article drips with anger and cynicism, and hints at a few bitter opinions like "...companies I had ideological issues around..."
To be fair, I did literally have ideological issues with them -- such as the amount they track their users, their stance towards China, their use of patents, or just generally bad reputation in the industry -- there's a bunch of issues I feel strongly about and that prevents me from working with a lot of different companies. I guess that's a bit of a luxury, isn't it? But that's also my choice. I'm not exactly homeless these days, so I still manage to find great people to work with.
I am pretty cynical and stubborn... not sure about angry, as you say, "I'm winning at life".
> I just don't want to work with difficult, unhappy people.
Are you really unemployable if you aren't fitting in with companies with which you would be a bad fit? Sounds more like an issue with your application choices than your employability.
That invites even more inquiry. So the author waited for people to come to them, and when nothing worked out, declared themself "unemployable" (despite not proactively looking for work).
I get that people can hit hard places, and that the author was in such a place. But I don't think the perspective given is an objective one, especially considering the author has had time for hindsight to settle in.
According to the blog post, they didn't proactively apply at companies they were interested in. They didn't bother catching up on new technologies or other skills sought after in the current market, spending their time on building a computer game instead. Interviewers are being vilified for acting in their own best interests rather than the author's conveniences.
They then finish up by becoming a digital nomad working 20 hour weeks and building up their savings and loving life. Where are the details that went into making that lifestyle work? Was it not due to being employable?
It's hard to sympathize with the author when the narrative is essentially "I put very little effort into getting hired and so had to work a little harder to get a job".
> So the author waited for people to come to them, and when nothing worked out, declared themself "unemployable" (despite not proactively looking for work).
There are two sections. There is the part where people reached out to me. Then there is the part where I went out and interviewed more proactively. And there is a lot of stuff in between that doesn't really fit into this blog post. So consider my version a simpler, abbreviated version than real life.
> According to the blog post, they didn't proactively apply at companies they were interested in.
I did apply at companies I was interested in. Why wouldn't I?
> They didn't bother catching up on new technologies or other skills sought after in the current market, spending their time on building a computer game instead.
So, I had just come off 5 years deeply immersed in the bleeding edge of deep learning and the beginnings of the wider application of this technology at various companies. Excuse me for wanting to try something different. Have you ever made a game before? Do you have any idea how technically involved it is? How does this not count as catching up on new technologies or other skills? I should have studied leet code interviews instead? I think I'd rather enjoy life and pursue things I find interesting.
> Interviewers are being vilified for acting in their own best interests rather than the author's conveniences.
No, they are being vilified for focusing on arbitrary things rather than focusing on things that are important to the actual job.
> It's hard to sympathize with the author when the narrative is essentially "I put very little effort into getting hired and so had to work a little harder to get a job".
I'm not looking for your sympathy and I don't know what part of my life story seems low effort to you.
A friend of mine dropped out of college 1 semester short of a CS degree, wrote some iOS apps, sold them for a lot of money, started several software companies, wrote a book on how to do this, invested in several more startups and lost most of what he had made - and now runs a land clearing company and is having loads of fun and success doing it. Sometimes you don't realize what you really want to do until something bad happens.
He invested in startups that failed miserably. Land clearing is how you turn bare land/forest/swamp into something people can build on. i.e he and his employees drive big construction equipment. Actually a profitable business in the right area.
hints at a few bitter opinions like "...companies I had ideological issues around..."
Being opposed to working for companies that build business models around eroding privacy, delivering adverts faster, or even literally killing people in the case of weapons manufacturers isn't "bitter". Those are valid opinions. Not being willing to work for any company that will give you a paycheck without questioning the impact of what you're doing is a good thing.
> Being a self taught software developer who has been programming since I was 12, I had no idea how to reverse a binary tree.
It can be done. As a self-taught developer, and after years of startups and consulting, I got my first FAANG job at age 40. I hadn't done any real kind of interview in 15 years. I spent 90% of my time preparing for CS questions, and struggled at the first one, but ended up at FB, and Google a few years later.
My mindset wasn't that they really cared that I could do these obscure programming exercises that I hadn't used once in 20+ years of real-world programming, but rather that I could prove that I could learn and adapt.
The BST doesn't correlate to doing well at the job. Being willing to teach yourself the BST because you want the job does correlate to doing well at it.
If you can't handle the level of theater that is reviewing basic CS concepts that we all could afford to be more aware of even if we don't need to remember them day to day, you're really not going to survive the level of theater that dealing with a large organization requires.
Ironically, the old-school hackers who made the word "hacker" famous, like the ones who built the UNIX ecosystem before Linux was even a thing, knew their CS fundamentals like the back of their hand. They'd have zero trouble with the coding aspect of these interviews.
Very few people on HN are hackers.
> "If you look at Goldman Sachs or Microsoft, BOTH are investing heavily in tuning their recruitment process to identify and hire neuro-atypical people"
That's just a publicity stunt. I'd bet money that few of the neuro-atypical they hire last long in those places.
Honest to God, I think current interview practices suck and single out leetcode as particularly corrosive and demonstrating nothing about competence.
But I honestly can’t believe people are acting like reversing a binary tree is hard. This is like something you’d expect high school students with the most basic you data structures knowledge to be able to do.
I don't know that I'm terribly interested in gatekeeping who can call themselves a hacker.
Like I'll agree that there definition of hacker in 1983 https://en.m.wikipedia.org/wiki/WarGames is different from the one we generally buse today, but the world has changed a lot in that time.
Did white-hat exist in '83?
The definition of hacker has evolved from "one who uses computer tools to gain illicit access to protected computer systems" to "one who makes shit work and does cool stuff"
If you're going to imply that only the 1983 definition is the one anyone can use, I feel like you're going to be off on that island mostly alone.
Absolutely. There is so much pointless bureaucratic BS that has to be done and dealt with at large corps that studying CS concepts seems like a genuinely pleasant experience in comparison.
There should be a reason for it. I learn things because I need them for my job or I find them interesting, hopefully with some overlap. There's a lot of things to learn in life, and it's rather pointless to learn things for an interview process if it doesn't reflect upon the actual job requirements.
Also, it's not like people know nothing. A good interview process learns both what the candidate does and does not know, how what they know could be useful, and how capable the candidate is in filling a knowledge gap if there actually is one between what they know and what is actually needed for the job. That is of course in addition to learning whether they're nice to be around or not.
It's like learning a gate code; you don't need it once you're in the house, it's pointless to learn it, except that you have to in order to get through the gate.
It says that I spend my time learning things that are actually useful, rather than trivia.
The best screening I ever went through was for a job where I'd be working on a Spring Boot app with a React frontend. For that screening, I was asked to add a simple feature to an example app.
It was clearly toy code, so I knew they weren't trying to get free work out of me. It was also representative of the kinds of tasks I would be doing, which let me know that I would enjoy the job, and let them know I would be good at it. I was hired on the spot.
I've written algorithms to reverse b-trees, and I could figure it out again if I had to. But I don't have to, because the standard library is a thing, and that task tells a potential employer nothing about my skill set.
For what it's worth, I don't like the CS-y interview process, but I also struggle with that very technology specific process. I don't want a job that hired me just to be a Spring Boot + React monkey. I want a job that hired me because they think I'm smart and adaptable and can tackle any problem with any technology.
Here's the thing I think you're missing when it comes to the employer's POV during these types of interviews: they don't care so much about your skillset. At the point where you're doing an in-person interview and being asked these pointless puzzle questions, they are reasonably sure you have the required skillset to do the job.
What they're actually testing for during the in-person interview is your ability to be a good worker bee. They're filtering out people like you who would question the point of doing task X. They want people who will do task X without question. They don't want workers who will ask "Why are we doing task X? Shouldn't we do task Y instead?" For most positions at these large companies, the person who questions the efficacy of task X is a different role -- the role that is instructing you to do task X.
With these trivia questions, they are in fact telling you as a prospective employee the kinds of tasks you will be doing. They are letting you know that you will be doing a lot of pointless work, you won't have any say in the work you will be doing, the work you will be doing will seem trivial to you, and you have to be okay with that. If you're not okay with that, it's not the job for you.
This might be true at places that are hiring out of a boot camp or something, but as a hiring manager myself, I can say that this is 100% not true at any company I've worked for.
I don't mean to sound rude, but I feel like your response seriously lacks empathy.
I am a father to a 2 year old, I have a mortgage and an existing full time job.
The time investment required to go through a bunch of algorithms that are almost exclusively used in passing coding interviews does not offer the same ROI as, for example, streamlining a process that you are currently facing on a day to day basis.
On top of that, something that I've learned recently about myself is that I have a tremendous fear of failing coding interviews.
You see there is an emotional component to the effort you put in to doing one of those things. You go through the work to get accepted into the interview process then you find yourself face to face with "one shot" to impress.
Maybe they've even flown you out to their location so you can go through this whole experience on site. At that point the optimistic among us might start thinking about things like what our lives would look like if we worked at "technological mecca" doing really cool shit for silicon valley dollars.
So you start allowing yourself to think about watching the ocean on a sunny day eating avacado toast while you watch your now bleach blonde son playing in the surf. Your wife is happy too. You have this beautiful life that you're providing for those that you love.
(in your fantasies you don't worry about the cascadia fault-line, the dystopian nature of US healthcare, or the fact that california seems to catch fire for a month every year nowadays)
ANYWAYS, you go in, you give it your all. Maybe you think you nailed it, or maybe you can clearly come up with 20 better solutions in the 20 seconds after you leave. Maybe you studied 50 concepts intensely, but missed the one they picked to ask you about. You didn't get the questions in advance or anything.
It doesn't matter though, you missed a semicolon on the whiteboard and your code doesn't compile when they type it in.
You get a terse reply from your original recruiter "not a good fit at this time" ... there's no insight into what you did wrong or where you could get better. That opens the company up to legal liability. Anything more than "thanks" risks exposure.
So you're left with days and weeks of effort for nothing. On top of that you have a real long flight home where you get to grieve the loss of that beautiful life you imagined.
Do you work in a place where you can tell your colleagues at work that you were interviewing? If not, you can't even talk to the people in your life who are most likely to understand the pain you're going through.
For me the ROI was about 40 hours of studying for (estimating) about a million dollars delta over my next best job offer over the first five years. That week I spent studying is the most return I've ever achieved per hour. I don't love it and I deeply hated it at the time and still feel dirty to think about it, but from a financial ROI perspective it is unassailable. Honestly I think the opposite of your family-man argument is the case: I couldn't afford to allow my pride to keep me from doing that, for the sake of my family's finances. When I was young and unattached I could (and did) afford to be more idealistic about not doing that kind of gross thing, just for the financial reward.
I think you should acknowledge that some people fail despite studying about 40 hours, and failing an interview takes a significant emotional toll that needs to be dealt with.
Good point, it is definitely not risk-free ROI at all, and the emotional toll can have outsized impacts. But I still think people with the skill set to succeed at other companies can learn enough in a relatively small period of time (I said 100 hours in a different comment to make the numbers round, maybe even double that is worthwhile) for it to be a worthwhile risk. I mean, the exact calculation depends on a bunch of details, like what the best alternative is in comparison. But I think for lots of people, it is worth the risk.
One thing I'd say is that essentially none of the people I know in other fields have a similar opportunity for a relatively small amount of dedicated study to pay off so well.
You're just so right! I'm expecting to take on a roughly 14 week study course to fit the work required into the time I have after I've put my son to bed and around my day job. Oh yeah ... and that podcast I started about professional development in software engineering.
(...and, and, and...)
But you're SO right.
I expect that publicly committing to internet-strangers that I'm working on the course, producing materials for them &, having a scheduled weekly discussion around the topics will help with both learning the content AND keeping us all motivated.
Your initial comment was one of the things that helped me come to those conclusions, so genuinely thank you, kind internet stranger for sharing your wisdom.
So it took a few days for what you said to sink in. And there were a few other information sources that combined together to bring me to the conclusion that you're right.
I've actually started writing a self-study course on passing the FAANG, as a trained educator with a bachelor of Education and five years experience as a high school teacher, I think I can make a fair shake at designing a series of free learning materials on the subject.
I started inviting people along and have built up a list of about 20 people who've at least SAID they'll stop by to my live streams (once a week) to discuss the problems of the week.
I don't know that the switch would have flipped in my head about the ROI of the FAANG interview.
As I said, it took a couple days to actually sink it but you have completely changed my mind. I now completely agree with you that they are worth doing for a number of reasons, many of which aren't financial at all.
I see them as equivalent to the Bar exam for Lawyers now. Would you hire a lawyer who said "I don't believe in the bar?" (I think we've seen how that played out with the Kraken lawsuit!)
Would you go to a hospital that said "We don't believe that doctors need to have done the USMLE"?
In both cases hell no!
You're right. This is not arbitrary or cruel, it's just a professional qualification. Sure there's some luck involved, there's the chance of personality conflict. There's all sorts of potential downsides... but there's also the upside.
Being better at my craft overall is the ultimate reward. If I'm a better developer overall, the money will follow regardless of whether I get in to a FAANG
I think couple things about interviews I've come to realise is this.
1. DO NOT get emotionally involved or excited about an opportunity till the time you see an offer letter - those reeeallly sweet people that are so happy and courteous and smiley will switch in an instant, snap! throw you out faster than a used disposable cup and will not so much as give you the courtesy of a reply. They don't give flying f about you no matter how many hours they themselves invested in the process. See for them, this is paid work to talk to you, so they don't give a shit they do it for 10 hours and still drop you without even sending you an email. You are working for free during the interview process and have much more at stake in this process than the person you are talking to. You feel you're having a genuine human interaction with them? no.
You think it went well because objectively it went really well? Don't worry you'll get a 2 line generic rejection email.
2. DO NOT ever gauge your self worth as a developer to passing or failing an interview - you will destroy your own morale. Take hints and learn to be better, no doubt, but the decisions people make about you sometimes don't have anything to do with you specifically so don't take it to heart too much.
The problem is if you don't get emotionally involved you'll definitely lose at least some level of emotional boost & interest. That also could be noticed & mentioned in one of the reviews.
There is no ultimate solution, it always depends on specific person you're talking to
I have always felt the desire to work at FAANG was diametrically opposed to having a family life.
Its seems to be an extremely competitive, eat or die type lifestyle that would require many more hours than a normal job. In essence its its own marriage of sorts, or at least in competition for non-work relationships/marriages.
And there's nothing wrong with the people that choose to do that. But it seems obvious even in the success stories.
I'm extremely competitive, however I also value family over all else. I would much rather spends dinners with my kids, and weekends with my family enjoying the fruits of my labor over having a line on my resume. I know that if i ever went that route, it would absolutely come at a cost, most likely my marriage at least, and probably some level of relationship with my children. Its frankly not worth it for me.
Generally, amongst my peers over time I’ve found that to not be as true. Though of course it depends on a number of factors, including leadership and company culture.
I could easily take some time if needed. My senior admin is taking a month of paternity here in a few weeks, as he did with his first. I have a first line guy that has been in and out for months for various reasons. It is a strain on others in small places but like any place if you document and cross train a bit it’s not terrible.frankly it’s a stated goal for my teams and something I have implemented across several roles and sectors in my career (even if I didn’t get to reap the benefits)
Colleagues of mine that went FAANG stated similar. Amazon notoriously has an unlimited time off policy. That buddy hasn’t made the family vacation tradition since he started. The first year he tried it he basically worked in the condo.
So from what I’ve seen, at least with Amazon, it’s de facto cutthroat and not so much a benefit.
Though I understand I’m possibly attributing that same experience, which may even be localized to his team, to a much broader set, based on the similarities of their culture/workplace.
Many of these places have showers and lounges and free food etc. and frankly I don’t want to work at a place that there’s a culture that encourages eating and sleeping there. Again I prefer to do those things at home or break from work during breaks.
By the same token, I think your post lacks empathy for OP.
OP perhaps doesn't have the constraints you have.
As an aside--
Do you really expect A. someone who has never met you and who has B. written a comment online before you arrived to reply... to know your life conditions or to tailor it to every possible human life outcome?
That is, because you've had children, does every comment online now need to ensure its content is in alignment with your perspective? That sounds like a failure to empathize, on your part.
For example, if I write something... do I need to make sure it's prepared in a way that 100% of people can relate to it, throughout time & space? Such as fathers of children, amputees, astronauts, etc?
I don't know that you and I should get into a discussion here.
It sounds like we're so diametrically opposed that it could get pretty heated. At least from my end. You do have a right to your opinion, but I don't want to play in the space where I could get emotionally dysregulated by some dude on the internet.
I'd rather not bring a flame war to the HN community.
I'm also not entirely sure that your argument is in good faith and i'm really not in the sort of place where I want to tease out the things you say which are hyperbole versus the things you really believe.
Do you really think that I said all interviews should be tailored to all people throughout all time and space? I can't believe that you really think that, so you can't be arguing in good faith.
Are you really saying that you think it is unreasonable that we expect accommodations be made "for amputees"? Like their role or position in society is somehow a burden on you, or god forbid employers?
Honestly, maybe you do. Maybe you're super into eugenics. I don't want to find out really. It is best that we go our separate ways.
Ok, before you read this, I need you to sit down and take some deep breaths. If nothing else, just remember:
1. It's going to be okay.
2. One day, you will recover from this comment and move on
with your life. It will take time, but just take it day by day for now. Every day you're able to regulate your emotions after this comment is an achievement.
___________
Now for the comment:
0. Intro
Thanks amigo. I think you've taken it in the wrong direction, intentionally. (Given the current politics of hyperbolic outrage bait, I typically assume overly sensitive people prefer to [i.e. at least pretend to be] outraged over strawmen, because that's the current trend I see in western society.)
________________
1. The strawman
Your strawman implication: "You don't think accomodations should be made for amputees?!?!"
My actual quote: "For example, if I write something... do I need to make sure it's prepared for" ... <examples of various potential peoples' widely divergent qualities>
Good lord. Way to take things out of context, and then get outraged over your own strawman.
Look... I literally said "if I write something".
and you literally implied "you think it is unreasonable that we expect accommodations be made"
Where did I say anything about "accomodations"... my comment is essentially that you fail to see that no one can predict what stranger (and the qualities of their life) could possibly happen upon their comment.
Our interaction went something like this:
A. Random father arrives to see a comment wasn't tailored to his needs and claims the comment doesnt empathize with him
B. I tell the father that it is he who lacks empathy for expecting internet strangers who arrived in a discussion before he did, to somehow prospectively predict his life qualities/needs for empathy as a father, and tailor their comment specifically for him.
C. The father doesn't appreciate the exposure of his hypocrisy. Decides to paint a strawman involving employer accomodations for amputees, eugenics, and emotional dysregulation due to online commentary (while also assuming my gender, for bonus points of course)
________________
2. The strange & unrealistic
... Also, regarding: "the space where I could get emotionally dysregulated by some dude on the internet."
Uhh... yeah, First of all, you just assumed my gender... something tells me you're not very consistent in your political pretense.
That said-- welcome to Earth. It could get a little rough for ya... <sarcasm> Maybe you should avoid everything that could possible evoke stress, rather than adapting to inevitable stress</sarcasm>
___________________
3. Left field
Am I into eugenics? (Firstly... What part of left field did that come from?) We all are, whether we like it or not.
Are you attracted to attractive people? Guess what-- you're a eugenicist.
All organisms are designed by evolution to seek the best quality genetics for their offspring, so again, welcome to Earth.
"Just like adults, newborn babies prefer to look at an attractive face, according to new research carried out at the University of Exeter."
I have never prepped for an interview in my life. If they're asking me questions or to solve problems related to my field, I don't really need to study. If they ask me things that are irrelevant, then that's another thing entirely.
In short, I am a specialist, and am hired accordingly.
Same I was 32 self-taught with 14 years of experience. After a few failures at these types of interviews I just studied and spent some time learning how to solve the problems companies were asking. I did better and got offers at 2 of the FAANGs and I've been at one for almost 8 years. So it's possible to be a self taught or have spent your entire life at small companies before that but studying is required for the coding part. I think behavioral and architecture are easier for those that have built a lot of things before, but they won't make up for a couple bad coding interviews.
And how do you like FAANG? I'm in a similar situation, I'm 30, worked for different kinds of companies and now I'm thinking I'd like to try applying to FAANG companies (mainly because I hope it would be more interesting, challenging for at least a couple of years, and maybe even get to know some people that operate at a different level).
From my experience, lots of great things: stability, great compensation, a never ending supply of technical challenges, products to work on that huge numbers of people use ("oh you work on that? I use that every day!"), a well defined technical career progression path, plenty of personnel depth and financial cushion to do things slowly (so you aren't ever up all night live coding against prod to keep the systems up and the business from going under), a strong engineering culture with more focus on code quality / maintainability (related to the financial cushion and also the default assumption that code will live for a long time), easy to hire good engineers so you aren't constantly strapped for talent, ... probably some more things that I'm missing.
And lots of bad stuff: the communication burden of wrangling huge numbers of people, bad decisions by leadership that you're helpless to impact, just the general difficulty of having one's values align perfectly with those of a big shareholder controlled faceless blob, figuring out what to work on that will be both satisfying and aligned with the right peoples' goals (that is, fun coding projects are often not impactful while thankless slogs are, at least for more senior folks), etc.; essentially, the politics are harder to navigate and feel satisfied with.
To highlight my first two positive points: the stability and compensation has allowed me to pay down all our debt, buy a house (recently refinanced to a 15 year mortgage), save up a year of expenses, allow my wife to go back to school, and pay for a couple kids to be in a lovely daycare. Most of that would have been much more difficult in my previous life in the startup world.
I'm very happy I got the job (when I was about your age), but I also think often about leaving it.
Similar to sanderj reply. It's the longest I've been anywhere. I got to work on a team that traveled the world, got to work on features used by billions of people, work on advanced hardware products, on advanced software products that use ML for Speech and Natural Language. It's not possible to work on some of these problems at other companies. So you deal with the operational overhead, sometimes long hours, the uncomfortableness when a mistake from your company causes real harm, etc.
The compensation is also something that is not as clear to someone who had a career arc like me. I've always been able to make money to take care of myself and immediate family, but making consistent FAANG money changes the way you plan and help people. I've been able to help one family member go to school, another go to med school, multiple members to move closer, allowed my parents to retire early so they didn't have to work customer facing jobs during the pandemic, donated tens of thousands of dollars to local organizations, etc
If I was single I might've left and worked at startups or smaller companies, but I wouldn't now that I see how much impact I can have on those around me by just going to work and working hard.
Agreed. Employers usually want to understand your capacity to learn (as well as many other things). Going to university formally demonstrates this but obscure interview questions attempt to test for this too. You can learn them all, just try.
> I spent 90% of my time preparing for CS questions
As always, to me this sounds like a real waste of time. I'd rather be working on a real project (working for people who value work on real projects), not practicing for an interview.
I too, would like to be working on a real project. But most if not all companies that I'd be thrilled to work for are gatekeeped by these leetcode style interviews.
I don't like that that's how it is, but that's what the game is, and most people are in no position to change the rules of the game.
I also acknowledge that despite all its flaws, the SWE interview landscape is still better than say, that for lawyers, where if you didn't graduate from a top law school some doors are immediately and permanently shut for you.
You can still get into a top tech company without an outstanding pedigree. The closest analogue to the lawyer situation is that if you have a top tech company on your resume, I'd say many doors are opened (or opened much more easily) to you than someone without such name brand companies on their resume.
There's the key. Their marketing has convinced millions of current and future devs that they are the best places to work for; that they are worth doing silly things for just to work there.
The problem is that many of their "wins" are from decades ago (or more). Today, for Google at least, you can't even choose what you'll be working on. You'll be tossed wherever they think they need you. Even the best new hires won't make it to the largest salaries (dominated by veterans) and won't get to spend their 20% time (if they even get it) on the next gmail.
The best advice I can offer, about two decades into my career, is to stop chasing the shiny marketing material. They'll burn you out and replace you without blinking.
Almost every non-family owned business now hires developers (and data scientists), some for very good salaries in places where you're not paying thousands of dollars monthly to be someone's roommate.
I admit grass is greener on the other side. However every company (even Google) has it's downsides.
But it's all relative. At least from this side of the fence, I see FAANG (and other top tech companies) have less downsides and more upsides, relatively speaking, compared to your typical non-tech companies.
The point is emphasized by friends and ex-coworkers who've jumped ship to FAANG and other top tech companies after working at non-tech companies like where I am. All of them seem to love it.
> Today, for Google at least, you can't even choose what you'll be working on. You'll be tossed wherever they think they need you.
I am not sure what you mean by this, but at least a couple of years ago you did have the opportunity to talk to several different teams and decide which one you're joining before signing the offer. Is that not the case anymore?
>The best advice I can offer, about two decades into my career, is to stop chasing the shiny marketing material. They'll burn you out and replace you without blinking.
So needlessly passive aggressive. FAANG jobs, right or wrong, are super competitive and extremely well compensated at senior levels. You just won't make the same amount of money writing BI software or CRUD line-of-business apps for an insurance company, it's not possible. When you've got that many resumes to go through you need to add whatever filtering mechanisms you can. Nobody does any BST stuff at work. But it's a filter. Reasonable people can disagree about how effective of one but it's at least no worse than just arbitrarily throwing half the resumes out, because the people who know it have some CS background, or they want the job bad enough they were willing to spend a couple hours to learn it. It's not like it's a high bar to meet.
Every startup that raised money can choose from dozens of candidates. I'm not really buying the "Software developer shortage" theory. If there was a real shortage we all wouldn't be jumping hoops learning bachelor degree material or doing home assignments for some startup interview when we have 15 years experience. But this isn't what shortage looks like, to me this feels saturated.
Soft skills aren't a waste of time... and being good at interviews is a soft skill that lead to job offers - so far from useless if you can pull a six figure job.
This seems like a "why go to college" type of response where there is some truth to the fact that so much of college is a waste (I've never used statistics or economics in jobs)... yet it's more than just college or CS questions.
Spending time working on "how to reverse a binary tree" and "how to find the shortest path in a multi-dimensional array" are not soft skills. It's learning how to handle highly specific theoretical CS questions.
and those skills lead to job offers. As proven by the thousands of CS devs that "jump through the useless hoops" and end up with jobs.
I agree that a lot of story around interviewing is broken and that many of the questions don't relate to day to day jobs... like creating a binary tree or "how do you move a mountain" (IE: https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/03167784...) - but they do show that you know CS basics, know how to learn them or have basic problem solving skills.
As much as people bemoan CS interviews... currently? They are a necessary evil to certain segments of the job market. Can you get jobs without them? Sure... just like you can get jobs without degrees - but your resume will get round-filed for a large number of jobs without a degree and you'll not make it past initial filters without knowing "basic" CS trivia like binary trees.
Whether you're okay with a limited job pool or not is on you... I don't have a 4 year... but I have a 2 year with many years of experience and I'm okay with some of the limits until I eventually get a BA. I still make six figures and know I can find a new job if it comes to it - as I've done repeatedly with limits. I've never balanced a binary tree for a job interview but I have "failed" online tests because I wasn't "fast enough" on code tests. I'm still employable and successful.
Slight review shows I may be off on my terminology... Interviewing isn't a soft skill per-se but it is still an important one for those who wish to interview as it stands currently.
> Soft skills are the more intangible and non-technical abilities that are sought from candidates. For example:
* Communication
* Teamwork
* Problem-solving
* Leadership
* Responsibility
So "interviewing" isn't a soft skill as I've always though it to be but I didn't call CS basics a soft skill - I called interviewing one. I was thinking more "a skill not work related per-se" - ie interviewing - while the expected definition is more... personality and interpersonal skills.
I'd consider interviewing "personality and interpersonal" but I can adjust my terminology.
Interviewing is an important skill for most people and interviewing in the programming realm, unfortunately, relies on CS basics. Generally you don't get one without the other.
Unpopular opinion, but the skills learned in these exercises really can translate to improvements in real world projects. We can get very far with most modern programming projects through brute force alone or by using standard library containers and algorithms, but past a certain scale it really does pay off to have an intuitive understanding of how data structures and algorithms work from first-hand implementation experience.
Of course, if a company is just building the stereotypical basic CRUD app to serve a maximum of 10K users total and maybe 10 per minute at peak, this probably doesn’t matter much.
However, companies that pay top dollar expect candidates with top knowledge, and that’s fair IMO.
> pay top dollar expect candidates with top knowledge
Knowing how to solve the ten or twenty most common CS interview questions is not an indicator of possessing "top knowledge". It's an indicator that someone studied the cheat sheet to big tech interviews, and that's all.
Fortunately, FAANG interviews are more than just a couple of CS interview questions.
The coding problems are part of the interview, but they're not the entirety of the interview. You can't pass a FAANG interview by cramming CS questions, unless you're maybe applying for a new grad position where previous work experience isn't factored in very much.
I'll second this opinion. I drilled on Leetcode medium problems to address some deficiencies in a recent job search (whilst in my late 40s age-wise). It made a huge difference in the interview outcomes, and I've found that I'm actually using this stuff designing solutions in my new job.
Having a bunch of basic, generally useful algorithms in recent memory does save a lot of time on the "general solution" side when you're working in a new milieu. (That saved time then gets consumed trying to find, configure, and tune anything in an unfamiliar cloud environment, but that's another kettle of fish).
I have a dilemma related to this. I know what I like to work on (domain / industry, etc.). There are companies hiring for this sort of thing. I don’t have any professional experience there though. So do I spend my time working on cool projects to build up the necessary domain problems so I can even get my resume looked at or do I spend my time leetcoding so I can pass the interviews.
I can do both, perhaps even concurrently, but clocks are ticking and I’m worried I only have so many years before I’m pigeonholed where I am now.
So knowing a professionally comprehensive set of tricks and approaches for commonly used algorithms has just straight up made me a better coder.I know when its wise to wield bfs, dfs, sliding window, et al, and have the capability to knock out and efficient function, when needed. Its rare, but its helpful to master some of these tools. There is a certain power in being able to reason a correct algorithmic approach, modularize it in your head, and then use it to tackle a real life problem, without having to resort to hashing it out in an ide.
The hard part is distilling the most commonly used and most helpful of these tools. But after doing so, I can now approach side projects where I got stuck on not having an efficient way to store and access data.
Knowing the start and limits of those algorithms gives me that confidence that what I build is close to as efficient as possible, and allows me then focus on pulling those efficient modules together.
As a self taught dev, its given me confidence in my expertise, and that pays off in job opportunity, self respect, confidence to mentor others, and actually completing hard projects that I could not complete before.
If somebody told me to complete five pages of trivial arithmetic problems, I'd probably regard it as a waste of time. If they said I'd get a million dollars for doing it (and I believed them) then it would cease to be a waste of time and become, in fact, an extraordinarily efficient use of my time.
The FAANMG+ life probably isn't for everyone, but it has definite upsides, and I imagine that's why most people jump through the interview hoops. It's not because they generally value toy programs over real projects.
This is why software is terrible. Would you test Frank Gehry on the basics of architecture? Or have Frida Kahlo count her brushstrokes or plan her day hour by hour?
I test all developers by paying them to make the equivalent of a bird box. If it comes back relatively well designed, cool, I've got a developer. If they come back with three designs for different environments and species, I know I have an engineer.
As it stands, we have kids who have zero real world experience at the helm of corporations and the results are easy to see. They rarely produce anything of value for the general population. So rare we have to call them unicorns.
Yep. Software and products at these companies are often a horrific mess. Leaving one and taking a big pay cut just so I can go work with a small team of people who give a shit about software and products again.
Specifically, I wouldn't hire Frank Gehry because his buildings leak.
The subfield of software development where artistry outweighs cleverness and productivity is game design -- and not all game studios exist to do things that way, just particular boutiques centered around one storyteller's vision.
Okay, so... architects design the building. Engineers engineer it. Construction firms construct it. Why do you think Gehry was pouring concrete instead of designing his next award winning building?
> Would you test Frank Gehry on the basics of architecture? Or have Frida Kahlo count her brushstrokes or plan her day hour by hour?
Not sure if it's relevant? Google has hired Guido van Rossum and James Gosling. I'd imagine Google didn't ask them to "reverse a binary tree", whatever that means.
I.e., if you are Frank Gehry or Frida Kahlo, you don't need to go through hoops. (If you're reading this, you are probably not Frida Kahlo.)
"you are probably not Frida Kahlo" is not the same as "you will never be Frida Kahlo."
It's just a fact that most people are not one of the very best in their field: 50% of people can't be in the top 1%. That's not to say people shouldn't try - after all, many of the "very best" tried very hard to get where they are.
Why are you assuming that everyone has the same metric for being the "top"? There are millions of artists out there, creating from the world around them something unique to their time and place. Your base assumption appears to be that a bell curve can be applied to human creativity. Ask yourself who told you this and why.
Yeah it sucks to have to study stuff that's mostly irrelevant to your job in order to get that job - it truly does, I despise the system! - but it is worthwhile to shift your perspective to considering the ROI of doing that study. The dirty secret is that CS-y interview questions are easy compared to the job. It's just much much harder to debug some novel bug that crops up in the cracks between the myriad components that uniquely make up the system you work on, or to figure out what your users want and how to build that, or to respond to having the good problem of scaling more quickly than expected, or tons of other things successful professionals in the field regularly do as part of their day to day work. It's deeply lame that experience with these much more difficult things is not expressed through the typical CS-y interview process, but if you can do those things, you can definitely learn to do the CS-y stuff. Reversing a binary tree is easy; look it up. Yes, you have to learn how to traverse a tree, and no, that's not likely to be very useful knowledge in your work, but it's not very hard to learn. You can spend 100 hours studying and nail pretty much all the CS-y questions, and that could literally have a return of a million dollars over five years; I don't know of many opportunities that offer such a good possibility of returning 100k per hour. It sucks, I hated studying elementary stuff after I was already a successful professional, and I was a nervous wreck during the interviews, but it is very hard to argue with it from a purely ROI standpoint.
A lot of FAANG engineers seem to report that the interview was the hardest thing that they've done, harder than anything they do as part of their actual job.
It's probably not that the leetcode problems are ultra hard to solve (though they can be). It's also the combination of the artificial time constraint and the high pressure interview setting - which is a very different kind of pressure than you typically experience on the job.
FAANG has a system for firing people who can't cope with the complexity of the job. There is a huge survivors bios. To be a FAANG engineer you need to be able to pass the interview and have the skills (mostly people skills) to navigate a large system.
Surely companies account for this in their interview teams? Or are they just haplessly floating on the narrowly applied intelligence of their workers? (Or something else, not suggesting a divalency).
I don't know if it's true but during a video talk there was a story that a team of googlers were secretly given their own feedback ratings and they didn't hire themselves.
Amazon introduced the notion of a “bar raiser” who expects a candidate to be stronger than 50% of the staff. It’s sort of appealing, but if your attrition is unbiased (you lose equal numbers of strong and weak staff) the right edge of the bell curve seems too small to keep up with it.
The core money-making algorithms don't take many human bodies to develop. At Google, 500-600 researchers and core algo developers likely do most of the heavy lifting.
Otherwise, 90%+ of their developers are likely solving routine problems.
Although, most of them likely convince themselves that only the "chosen ones" among mankind can do what they do.
The reality is that most of software, even at the FAANGs, does not require the type of interview questions these teams enjoy asking.
FWIW, I don't think most people at big companies are at all convinced that they are the "chosen ones". I think they are glad to have good jobs that have a higher than average potential to contribute to projects that are useful to people.
Oh I agree, but yes, I think it's the giant amount of pressure and negligible room for error that makes it so hard, rather than the difficulty of the material.
FAANG guy here, interviews are hard in that they have absolutely nothing to do with your day-to-day job. If I were to go through the interviews again right now I'd make a massive fool of myself. I'd say it's basically common knowledge that prior to making any hops, you've got to take at least a month or two to grind leetcode problems so that you're back in that head space where you can solve pointless problems with high efficiency.
Interviews are also hard (as I frequently comment around here) because, once you've seen how the sausage gets made, you realize it's basically still a crap shoot which comes down to the loop you get. If you get an unlucky roll and end up with the personality type which views interviews as a chance to show how much more clever they are than everyone, then you've already failed. Their ego is tied to their "high bar" and impossible question set, and you're just fodder for them to show off that "high personal bar" during the de-brief.
Ha! My hobby is pharmacology and I’m always having to refresh myself on various steps of Krebs. We need a Ninja Nerd[0] for CS I guess, I’ve found it incredible.
Right, but you can't become a doctor without spending many thousands of hours and hundreds of thousands of dollars gaining credentials. But you can become a highly compensated software engineer by spending a miserable day answering pointless questions on a whiteboard. I would personally prefer the credentialing approach because at this point it would be easy for me to get the credentials. But the low barrier to entry also has advantages.
For that matter, I'm not sure that the way medical education is done is something to aspire to. Years and years of exhausting sleepless tedious grind, at the expense of any instruction on deductive thinking or bedside manner; if at the end of it all they can't even draw the Krebs cycle from memory, then what the hell is the point?
My beef with the leetcode interviews is that, IMO, they're in no way reflective of what you're actually going to do, and yet the interviewer often acts like it's a perfect barometer. One misstep or quibble and you're out.
I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.
I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.
Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?
or trying to glean proprietary information out of others?
> Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?
It's a struggle between fitting the interview to real-world situations vs making it seem like the candidate is doing work for the company.
I feel like a good situation might be actual problems previously encountered with the technology being assessed during the interview that would've required you to have collaborated with someone who is also experienced in that technology to help you solve them.
Maybe the best way to do this is when the situation is proposed to the candidate, make it clear that the answer is already known and put it in an envelope (physical or digital), which will be referred to when it's solved or the candidate hits a dead-end.
Leetcode interviews don't test if you're a good software developer, they test whether you're capable of becoming a good developer. The skills required to succeed at leetcode basically come down to 1. willing to spend 100 hours studying/practicing 2. Baseline critical thinking skills. Throw in some behavioral to make sure they can communicate and those are basically the skills needed to become a decent developer.
I don't think anyone cares if you can actually solve the problem. They are looking to see how you perform under pressure (not because the job is necessarily stressful, but because we can learn a lot about a person's true personality when they are under pressure), how good you are at problem solving, whether you actually know anything about coding or are just BSing, etc.
This is the ideal, and the original point of such questions (I was at a FAANG and interviewing candidates when they started becoming popular), but the inevitable result is that the test becomes interpreted more literally as it becomes more common.
"but because we can learn a lot about a person's true personality when they are under pressure"
Do you have a source for this? I can't help but think about the person in this clip: https://www.youtube.com/watch?v=LlCEmPF4-V0. You think you can learn much about her from that interaction?
While what you say is the ideal situation, I think being able to get the optimal solution and giving at least a halfway decent explanation about why it works is the #1 most important thing (along with just plain old not being a jerk).
I acknowledge there are some situations where you might pass the interview even without arriving at the optimal solution, but those are probably the exceptions.
Just being IN the interview to begin with is likely to be higher pressure than any sane or sustainable working environment would be.
I've interviewed people who didn't know the answer to some of these tech questions, and honestly, I was more impressed by them calming saying "I'm not sure on this one, I would probably need to go look it up".
I used to be quite stressed-out by job interviews, until I realised a small crucial thing... If you're interviewing while employed (which, to be fair, is not a luxury everyone has), the absolute WORST outcome of that interview is "I am given an offer".
Why worst? If you're not given an offer, nothing changes. You've spent somewhere between 45 minutes and a day, got some interview practice and all is basically status quo. But, if you're given an offer, you are now faced with having to weigh the pros and cons of accepting it.
I've consulted with quite a few companies on their interview process. Almost all of them had adopted Leetcode style interviews. My first question to the team always is: what exactly are you evaluating when you interview someone?
And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).
The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?
Getting really specific about what exactly being "excellent" means to a team is really critical.
Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).
It’s hard to admit that they don’t actually know how to evaluate people well and instead implement an absurd level of inefficient gatekeeping. The same reason some jobs only hire people with degrees even if it’s not necessary or the degree is irrelevant.
When I'll be preparing for the next interview rounds in my career, I'll make note of some problems that are both short/easy to explain, and have really interesting optimisations that are almost impossible to come up with on the spot (unless you've done a lot of similar stuff or that exact problem before). Then, when the interview is (nearly) over and it's my time to ask the interviewers something, I'll drop one of those in their lap to see how they react, and if they can come up with something that's not laughably stupid/inefficient. My point being that, if they're not capable of solving problems like that under intense time pressure, they're not up to the task of interviewing someone else on them. If they do give a good response, kudos to them, I'll be impressed.
Though I think my expectation is that they'll get annoyed and stop the "interview".
If you did this to me during an interview, I would try as best as I could to give you an answer in the 5 or so minutes left of the interview. Then, in my feedback, I would strongly recommend not hiring you as a bad personality fit.
I also don't really ask "trick" questions (I try to select questions based on what the CV indicates would be a strong area for the specific candidate), the closest I get to that is probably when it comes to service monitoring (where the exact final answer is less interesting than the process of getting there).
My reply was only intended for "trick" questions that have absolutely no relevance for the day to day job of 99% of Software Engineers. And that's exactly because those trick questions tend to be more about the "exact final answer" than about the process, so my point was about figuring out if the interviewer actually has a grasp of those sort of problems in general or if they memorised a good solution and are milking that for all it's worth.
And I do know that almost any interviewer would reject me based on that, but I think it's worth letting them feel the burn they try to inflict themselves.
As a younger developer I was part of a 3 person team that was interviewing people at a telecom. I mostly kept quiet and observed since it was the first time I'd done this but we had one member of the team who was bent on trying to show how smart he was.
My absolute favorite interview of the group, a guy who ended up getting hired elsewhere, was the most calm and professional developer I'd ever been around. Sitting in the room, I felt like he was interviewing us rather than the other way around. It was just in the way that he carried himself, answered questions.
And then the guy on our team started asking questions. The gentleman we were interviewing, rather than answer, kept calmly asking more questions of him instead.
- Can you describe the situation where this would be used?
No
- Have you ever run into an issue like this before that could be an example?
No
- How do I know that by solving this problem we would be addressing the business or customer problem?
We don't
- Then shouldn't I be solving questions related to the work?
...
I loved that guy. Wish we could have hired him because I really wanted to work with him.
> I stopped an interview once. I told the guy I didn't think I'd be a good fit for the organization, and maybe we should save ourselves some time.
I've done this a few times, each time from a startup that reached out to me asking me if I'd come in to talk to them, and then would throw me into their coding challenges immediately. Like whoa hold on there, I don't even know what you do, why are you asking me to do a coding challenge before we've even figured out if there is a fit for me technically and I figure out what it is you're trying to solve.
I once passed some take-home test from a small startup. They then requested a further take-home which a) would be monitored (it was a remote position) and b) would require some six to eight hours and c) would have to be done over the weekend. There had been no contact with anyone at that point other than passing the initial test, and no discussion of salary, benefits, etc.
I've rarely used unprofessional language in job application emails, but on that occasion I pretty much told them to take their no-name little company and shove it.
This seems to be another example of the trend to AI based hiring, where the candidate interacts with zero humans until they have invested a huge amount of time and energy[0]. Good on you for telling them off.
I try to use problems that I encountered and solved during my daily work in my interviews, and generally the experience is better for both me and the candidate when the problem is more relevant.
Many interviewers don't do this because it's often difficult to distill the most interesting problems down to something that would fit within the time allotted for the interview, and also there are candidates who prefer abstract textbook-style problems.
Amazon calls that the STAR method, Situation, Task, Action, Result. Combined with real world experience / examples can be powerful during interviews. Especially during interviews with people not knowing this method.
Yeah all my most interesting problems are solved by carefully reading logs and the code that wrote them, stepping through code in a debugger, working on small repros, and eventually hitting some eureka, often after a couple days of dedicated effort. This would be a poor interview technique, though it would have great signal.
A web startup I joined years ago hired this way. The "main" technical interview was pairing with one of the devs to fix a toy broken service. In my case, this went fullstack from client bugs to backend bugs to sql/orm bugs as well as "make a page to show a list of things". They weren't so formal as to have a coded up modular interview system or anything, but I always enjoyed that one the most because it was closest to the job.
I asked some of my interviewers, who had been around their companies for a while, if the interviews were as tough when they got hired, I think a few said said no it was easier, and iirc one said when they got hired they just shot the shit for a while and got hired right away, but he joined before the company was acquired by a FANG.
> interviews are hard in that they have absolutely nothing to do with your day-to-day job
I often wonder why this is legal, especially given the legal concept of disparate impact. It's basically just a disguised test of some combo of IQ + free time + willingness to grind dubiously useful information
I think it's only a matter of time until the extreme disparity between the candidates that pass this filter (mostly white and asian men below age 35) vs the applicant pool is used in a legal challenge about whether these tests are really looking for bona fide occupational requirements.
Because any software person will tell you these tests are extremely detached from the requirements of the job.
It seems like it would be an open and shut case if not for the army of lawyers employed by the likes of Google.
I find this interesting, because I feel every time I visit a Silicon Valley tech company’s office, I’m surprised by how diverse the employees working there are. Yes I know certain groups are still more represented than others.
But it’s still more diverse in contrast to the companies I’ve worked at (non-tech old school companies in finance, etc), where the tech employees tend to fall into a much narrower stereotype.
I think such a challenge would fail in any reasonable legal system. HN seems to be talking itself into a belief that these interviews have no relationship to actual programming work, but that's not the case and plenty of experienced engineers would step up to defend algorithmic questions if it ever moved beyond bellyaching in blog posts.
Of course the USA is ever more extreme and crazy when it comes to identity politics, so ago knows if the justice system is still reasonable in this regard. But I'd really enjoy watching people argue in front of a judge that working with tree structures is extremely irrelevant to programming.
There's some truth to this, but it's also true that when someone with many years of experience and a long history of top performance ratings and promotions has to take a week or two off to study in order to do the test, that it indicates the test is not well targeted to the job.
> I often wonder why this is legal, especially given the legal concept of disparate impact
“Not yet challenged” and “legal” aren’t exactly the same thing. Straight up IQ tests are probably more defensoble than leetcode for lots of positions for which leetcode interviews are used. But people have heard the popular misrepresentation of Duke Energy (“it’s illegal to use IQ tests”) more than they’ve heard the actual disparate impact rule, and that seems to be true on both sides of thr interview table.
Good call on the dice roll. Spent months prepping for the FB interview and got an engineer who seemed to be having a bad day or was just bored. I knew both problems but they derailed me on whether you can uniquely identify objects in JS with no additional id assigned. I told them you can’t as there’s no pointers or memory addresses in JS. They didn’t believe me and literally spent multiple minutes googling things to prove me wrong. And then rejected me after I still finished the second problem in the 7 minutes remaining. Nevermind they were looking at their phone multiple times during the interview lol
Demoralizing as all hell. Thankfully I had multiple mocks with FB engineers who told me I did great so I know it really was just bad luck that the real phone screen was a dud.
Sometimes interviews are just part of “following the process” when someone who knows someone is going to get the job anyway, but still they have to follow the process so everything looks normal. These things are not so cut and dry and objective as you would like to believe. I wouldn’t sweat it.
It amazes me more people don't see this. Virgin in the UK looked into the data and found a bad candidate experience was significantly impacting their bottom line, just in actual candidates cancelling their service within 30 days of a bad candidate experience.
They didn't even need to look at word of mouth impact to see a material hit on their customer retention, in a sector where churn is costly. They went on a crusade to improve, and now find candidates for jobs are net promoters, and their customer acquisition cost via candidates is lower than normal advertising(!)
I think some of the big tech companies simply don't care about their reputation at either micro or macro level, and nobody wants to call out that kind of toxic behaviour as they're all "part of the club".
This is actually a big thing we invest in at my current company: candidate experience and consequently a high Glassdoor rating. After focusing on it for years the company has one of the top ratings on Glassdoor (top 100 or 200 I forget). It’s a big differentiator when you’re not a big company and not a recognized brand. I think for FAANG companies they can get away with it because despite a poor experience, the actual job and pay/perks they offer are extremely desirable. Sad because, like you say, it’s not hard to see and make an impact on improving.
In my experience Glassdoor doesn’t mean shit. The single most dysfunctional, toxic work environment I’ve ever been in had - and still has - a high (>4) rating on Glassdoor. I won’t get into details but I was miserable and left after two months. They said all the right things during the interview but the reality was vastly different. The non-disparagement clause I had to sign on my way out was the icing on the cake. No wonder they have such a high rating if you’re not allowed to be honest about your experience.
At an employer prior to that, I saw first hand how companies were able to get negative but true reviews taken down almost as soon as they were posted. There was high turnover at that place and a lot of people were truthful in their reviews of the company. The Glassdoor rating was far higher than they deserved until they went under.
Im short, I’m sure you think you’ve got a great work environment, but I’ve been burned by bullshit Glassdoor reviews and I doubt I’m the only one.
That’s fair. It’s a metric so it doesn’t surprise me that it’s game-able like others. I guess as a candidate you have to use it as one data point. It’s tough because even interviewing as a candidate and asking lots of culture questions you only get, what, like 20 mns of questions answered? Before you commit to 40 hours a week? Sorry to hear you got burned. Toxic work environments are such a drain on life.
Well on the opposite side of the table are the people who start arguing with me during the interview (and twice even after the interview).
I generally try to help everyone as much as I can during interviews, because honestly this is taking time away from my other work and I'd nothing better than to hire you, but sometimes it's just to much.
Ugh, that's terrible. I had a similar situation when I started interviewing after my startup failed. It was with a major energy company for an Angular developer role. The interviews were going really well until the final interview when they asked me to do some live coding. This led to a 15 minute discussion about 5 minutes into the session about whether JS had while loops. The developer testing me was absolutely convinced that JS had no while or do/while loops and refused to move on from that point. Their loss.
That's a bugger :/ Regarding uniquely identifying objects, if we can compare objects by reference, doesn't it count as unique identifying? E.g. let a = { }; let a2 = a; let b = { }; a === a2, but b !== a2 .
In this case it was a problem about creating a deep copy of nodes in a graph. My “easy” approach involved using a map with the key being a reference to the original A and the value being the copy A* OR adding matching ids to A and A* and use a map to go from A to A*. They said no mutations to the original objects (ids are out the window) and then that led to the quibbling over addresses because you can’t use an object reference as a key in a map in JS (it’ll just stringify it in the map).
(I’m half hoping that after typing this out someone will reply with some data structure I’m unaware of that would allow you to uniquely map the reference of an object to an arbitrary value.)
Regarding getting a "bad" interviewer - what makes this worse is you're rolling the dice multiple times.
I've had several interviews where everything seemed to go well, but one (out of say, 4/5) interviewer just seemed to be hostile from the moment they walk into the room.
Its also a different kind of problem. Its not really problem solving, though it masquerades as such. Its memorization. Plain and simple, you know the techniques or you don't. Studying at length for those kinds of problems is extremely unfulfilling, especially for curious minds who have long realized there are far more actually interesting and useful problems to solve out there than there is time left to live. And yet, here we all are jumping through hoops because nobody has figured out how to test for real job skills.
It isn't pure problem solving but it also isn't memorization "plain and simple". It's a mix. It's unlikely you'll see exactly the same question as one you studied. The problem solving portion is figuring out how to apply one of the techniques you've learned to a novel problem.
I think the argument is that recognizing the algorithm part through the (usually thin) facade is very easy, once you know the (common) DS&A questions well. I.e. there is a lot of challenge in learning the algorithms, and little to no challenge in recognizing it through the problem. Examples where a person knows the underlying DS&A very well but is unable to recognize the nature of the problem would be a great counter argument.
I say "plain and simple" because IME people tend to overestimate the novelty of problems and underestimate the impact of "memorized" problems for solving new ones. 3 months of studying for an interview, while extremely annoying, is generally speaking a pretty small amount of time needed to cover a field as vast and complex as DS&A. And yet it is more than sufficient for most because there's extremely little novelty in the problems being asked. They want you to solve classic algorithms, but either dont' want to tell you so or (more commonly, IME) don't realize they are asking classic algorithm problems and only think they are asking some novel problem. Even "simple" techniques will be impossible for a person to solve in an interview setting, and yet if they've seen it before the interviewer will think they are a brilliant programmer. Its a memorization game even though it doesn't directly look like one. IMHO.
Anecdotal counterpoint: Passing FAANG-style technical interviews are the easiest thing I've done.
Learning new frameworks and coding standards, surviving code review, dealing with difficult team members, dealing with ever-moving business goals, and just about every other aspect of work, including the coding, has been harder.
I admit that I have never had to invert a link list as part of my work (Graph traversals I definitely had to do, actually). But I have had to submit to arbitrary technical demands and to learn and use technical materials I did not enjoy or agree with architecturally in order to successfully complete projects. So in that, studying and practicing to pass the technical screen is similar to the job. Employers want someone who is able to (sometimes!) bite their tongue and just do the work assigned.
I think the rationale at the scale of this point in FAANG is to hire as many people as possible and see who can't hack it (pun intended). In the early days, they had to be more choosy about narrowing the talent pipeline with harder interviews.
Actually, I remember one IT-style interview 12-ish years ago with a certain FAANG that shall go nameless that had this sorta narcissistic/sorta dumb hiring manager, whose profile picture was a shirtless muscles pool pose, believed that a technology I inherited and was forced to use was an interview deal-breaker. And, at the time, I was at an IT department at Big Name university down the street where there were much more complicated and interesting things going on, like remotely uninfecting and patching worm-laden systems and putting together a fully-redundant/HA VMware cluster that had an FC SAN and blade servers (the thing back then).
Not just FAANG jobs. In almost every job I've ever had, the interview was by far the hardest part. There's such an enormous stream of candidates, and no baseline "bar exam" to qualify people, so companies have to make the interview bar extremely high in order to be able to manage the candidate flow and sufficiently minimize false positives.
I'd guess 99% of engineers never have to do CS trivia as part of their day-to-day job.
I've been on interviews at some companies that have no brand name recognition/prestige, and probably do not have legions of candidates trying to get in. But they've thrown me harder leetcode questions than FAANG.
It's a bit perverse but the problem is that hiring people who can't do the job well is much worse for a company like that than it is for a big company with lots of slack in the system. Not only do they have to pay a person that isn't contributing enough, but the more senior folks on the team have to spend more time mentoring, so it's a double drain. This drives the process toward a higher bar after getting burned a few times.
I like to ask simple questions, and then dig further into once they answered it correctly. You would be surprised how many ex-employees from FAANG like companies fail it.
Simple questions, as in simple leetcode questions?
FWIW, most FAANG employees seem to admit that if they had to redo their interview, odds are they're more likely to fail than pass. Goes to show how much luck is involved in the process.
I think it's gotten harder too. Maybe in the past it really was about trying to see how the candidate thinks and solve problems. But now it seems like all all of that is secondary to getting the optimal solution. Two of my friends in Google who got in ~10 years ago say that it's definitely gotten harder from what they see.
> There's such an enormous stream of candidates, and no baseline "bar exam" to qualify people
That could be trivially fixed tomorrow, either by universities or (better) by an accredited certification body.
I mean, I'm sure there weren't bar exams for lawyers and professionals either, at some point in history. What prevents us from creating one for sw developers? As long as it didn't require additional attainments just to sit for it (i.e. you should not need a university degree), it would make the whole process more efficient for literally thousands of companies.
There's a significant number of employed, productive engineers that are apprehensive about passing such a test. They will fight tooth-and-nail to prevent any gatekeeping to the field. Personally, I would be happy to have my salary double overnight.
What do you think a cs degree is? We don't use them as automatic proof of competence because lots of people get good degrees but cannot program, or enter the field in other ways but can.
As you state yourself, cs degrees fail at being proof of competence. They are too long, expensive, and unfocused. Hence why we really could use something else, simpler and more accessible.
Yeah, but which institutions would design such exams? CS degrees aren't ideal but at least they're designed by people who have CS training and are programmers. If a government decided to set such an exam it'd probably end up requiring some sort of certification in enterprise .NET development.
Maybe. I agree that's a strong argument, but I think for both accountancy and law the standards are in both cases defined by governments, as the professions are largely about ensuring compliance with what governments require. The professional certifications can thus be just checking your knowledge of what the rules say, without getting into the question of whether the rules are correct.
In software it's not like that. There are very few laws on the book about how to write software, so there's no single authority that defines the right answer or the scope of reasonable questions. It's far more open. Even just picking a set of programming concepts would immediately cause controversy. Like, should monads and type-classes be a part of the professional qualifications? Most programmer would say no, because Haskell isn't widely used in industry. But CS degrees do sometimes test people on that sort of thing!
This seems like a decent point for accounting but not really for law. Certifying a lawyer is not just about a finite set of things they have to know, it's about fundamentals and the ability to ingest facts and form an argument. Similar to your Haskell point, there are parts of the law that not all lawyers need to know, but are expected to be able to figure out as needed and the certification aims to check for that ability.
(Also, in both cases, the government hires members of the profession to define the standards.)
I'm convinced we could have a bar exam for software engineering, but I'm not at all convinced that we should. It would make my life easier personally, but it would keep a bunch of people who followed less traditional paths out of the industry and I think that would be bad.
Google projects on Github are a good reflection of it. The code quality of these projects sometimes. You wouldn't be able to get away with that in smaller companies.
They're pretty flexible about the trial project, which is contract pay, including choosing an open source project. Though I think you definitely need to want to work at Automattic to go through the hiring steps though, including onboarding as customer service. Note I don't work at Automattic, I know someone who went through their hiring process but declined due to salary.
Is that an equal burden for every candidate, in every life circumstance? Or does it privilege certain groups over others? The ROI isn't the point. Requiring preparation unrelated to the job is highly suspect, regardless of the return.
It privileges younger less attached people with more free time over more experienced people who are more likely to have families. Note that I was the latter kind of person when I did this, and trust me, a credentialing solution like the one in essentially every other professional field would have been way better for me, but there are also advantages to having a lower barrier to entry than those fields.
Honestly I'm okay with a super-tough theoretical interview when a very high and very comfortable compensation and benefits package is at stake. Every other job I can think of that pays nearly as much as tech requires years of education/apprenticeship, brutal exams, and less flexibility around things like location, work/life balance, and dress code.
Right. I despise the interview process we've landed on in the industry, but have slowly and painfully come to terms with it as a decent bad way of doing it to balance between having some competency bar and the usual heavy gatekeeping solution.
>You can spend 100 hours studying and nail pretty much all the CS-y questions, and that could literally have a return of a million dollars over five years; I don't know of many opportunities that offer such a good possibility of returning 100k per hour.
It's even worse asking candidates propabilities, linear algebra and presenting them with real problems (NOT cs) and ask for applied algorithms, most failing miserably and then seeing on glassdoor that they found the interview easy non technical but got no offer. Most even miss that the discussion was about algorithms (I am not telling them explicitly).
My girlfriend knows multiple SWEs at Google who recommended reading the Algorithm Design Manual as a top tier study guide for Google's interview questions, to add another point of anecdata.
Yep. Again, this advice can be overwhelming: it's not the entire book that is the most useful part, it's the refresher material at the beginning that does a great job of covering the kind of stuff that shows up constantly in interview questions.
Definitely. I’ll add that it doesn’t take as much time and effort as commonly portrayed online, especially if you have many years of development experience already.
Keep in mind that many of the online FAANG cram-style study guides and anecdotes about grinding LeetCode are largely targeted at college grads who don’t have many years of experience, and who also likely have a surplus of free time.
For developers with years of actual programming experience, it’s not as difficult to study interview problems as it sounds. Even more so if you spread your practice over a long period of time. Doing one problem per weekday over the course of a year will get you quite far in LeetCode without much time investment.
I grab a random LeetCode problem on my lunch break if I’m eating alone (aka every day during COVID). I pick a different language that I’m familiar with to rotate my skills. I’m not even interviewing, but it’s actually kind of fun to do the harder problems and play with all of the little optimizations. And I get to keep my skills fresh in programming languages I’m not currently using in any projects.
> Doing one problem per weekday over the course of a year will get you quite far in LeetCode without much time investment.
The problem with this approach is that you won't be able to remember the details of problems older than X months ago, at least not to the level that will reliably help when in a stressful whiteboarding interview.
There might be entertainment/knowledge benefits, but it doesn't replace cramming for a known upcoming interview-event.
Having done it myself, I don't find that I lose the knowledge or experience as you described.
I approach it more as learning different techniques to solve different problems, rather than learning how to identify the trick and recall the solution to specific cues.
Trying to memorize solutions isn't really effective for interview problems, in my experience, unless you really can dedicate time to cramming as many solutions as possible right before an interview and hoping that they ask you one you've seen before.
You don't need to remember the details of a specific problem. Almost all the problems I've encountered interviewing for FAANGs were not found on such sites. You do need to remember classes of problems - graph traversal, tree traversal, dynamic programming, etc etc. But you should expect problems you've never seen before.
I think you are thinking about this the wrong way around. You don't need to "cram" for something if you understand it well. It's a matter of techniques, not answers.
I did one of these interviews on short enough notice no review was possible. The process was a little jarring but on these type questions I could just talk through the problem space and come up with something reasonable and explain it; although I doubt I answered anything precisely as expected in the half dozen interviews I had. Apparently it went well.
To be fair, I wasn't a fresh college grad, and I had been recently working as a full time researcher. But they sent me through the SE interview process and none of the specific questions were close to anything I had thought about in years.
>>You don't need to "cram" for something if you understand it well. It's a matter of techniques, not answers.
No, you absolutely do need to cram to get through the interviews. In fact the questions on leetcode are designed for this very purpose. Every question has one common theme. And one 'catch' that you absolutely need to know to solve them.
If you haven't looked at a question in X months chances are you will struggle to solve it quickly even if you have solved it before.
If you are out of a job, just buy leetcode premium. Keep doing it for 15 hours a day. Then start applying for interviews.
Its the dumbest way to hire and get hired.
Not even least surprised people can't hire a person to get a darn thing done.
> No, you absolutely do need to cram to get through the interviews
I just described a situation where that was not true, so I don't really know what you are responding to. If you are generally on top of problem solving, you don't need to "cram".
This generalizes - "cramming" has origins for formal courses, as a technique to try and pass an exam when you haven't actually done the work and don't understand the subject. It's a last-minute approach; might get you a pass but is hardly ideal.
> You don't need to "cram" for something if you understand it well
I think most people cannot ever understand these topics well, and from their perspective, it'll always be about cramming. -- It doesn't fit in their world view that others can solve these problems by thinking, not cramming, when they cannot?
Whilst to you, it's more about thinking, coming up with new things, but trying to learn it all by heart would seem a bit weird? -- And then maybe in a sense you're talking past each other?
If you don't mind my asking, what was your study plan like? I'm self-taught and I'm in a similar position, I really need to study but I'm lacking an effective plan of attack.
I did the green book (McDowell) cover to cover, with a few dedicated hours of study each day, and random googling/tinkering where I wanted to explore more. I won't say it was the most fun I've ever had, or as self-motivating as a nice side project, but it was a good change of pace over gluing APIs together, so the novelty effect kept me going for a while. I probably put 150 hours of prep in over 6-8 weeks. The ROI on that time (relative to competing startup offers) was very far north of $1k/hour.
Never heard it called the green book, usually just called by the acronym CTCI (Cracking The Coding Interview). Just commenting in case anyone else was confused.
Congrats on getting a good payoff on your work, and thanks for sharing the info about your process.
Thanks a ton for sharing this! Super inspirational.
I'm a self-taught developer, 34. My first programming job was only at about age 30.
About 2 years later, I was consulting for Amazon, as a full stack engineer building a digital marketing project, which was pretty cool-- plus great for the resume.
After that, Amazon contacted me for an interview with them, which I failed (lack of data structures & algorithm knowledge/experience).
I still have the hopes of working directly for a FAANG company. So, just wanted to say thanks.
Currently I am unemployed, but I am about to start studying DS&A again & building some small projects. Fortunately, given the industry & skillset, I have recruiters contacting me frequently, which is a positive, uplifting signal.
> I spent 90% of my time preparing for CS questions,
For me this is the main problem with companies that hire like FANG do. It is fully expected you have to study. Like I have to study to basically do the job I am currently doing but at FANG? Then there are the fact so many people say the hardest thing about Google is the interview. And for me that is kinda pointless then, like if I've just done the most challenging thing, why would I want to hang around?
Yup, it's a sad truth (not limited to tech companies) that you've got to play the game. The blogger wasn't unemployable, just unwilling to do what was necessary for these particular companies (his prerogative; not judging in any way...).
>My mindset wasn't that they really cared that I could do these obscure programming exercises that I hadn't used once in 20+ years of real-world programming, but rather that I could prove that I could learn and adapt.
This is how bad interviewers always justify asking nonsensical questions.
It's like that old joke:
An interviewer picks up a stack of 50 resumes, takes a glance at them and drops the bottom half into a wastebasket. A coworker asks:
Yeah, I don't like the attitude of "I'm self taught so I don't know about data structures and algorithms". The first part of the sentence doesn't logically lead to the second. It's not even anything that advanced or difficult either. We're talking about easily and freely available information with plenty of ways to practice.
If you have a big knowledge gap in something that's
- easy
- freely available
- relevent to your job
then that's pretty much entirely your fault and it has nothing to do with your educational background.
I'm also self-taught. I couldn't reverse a binary tree in a tech interview (without looking up how to do it first) because it's never been relevant to my job. I could, however, stand up an API and deploy it to AWS in a similar period of time, because it is relevant to my job.
> If you have a big knowledge gap in something that's
> - easy
> - freely available
> - relevent to your job
> then that's pretty much entirely your fault and it has nothing to do with your educational background.
Sure. But reversing a binary tree isn't relevant to most modern software engineers. And when it does become relevant then, like you said, it's easy to learn (on the job).
> It's not even anything that advanced or difficult either.
No but it is something that gets "memorized" for a test (and therefore immediately forgotten afterward).
I don't fully get this argument. Trees are a very common thing to encounter in all sorts of programming and recursively walking them is also very common. I had to do it yesterday as part of writing some code to traverse a file system, nothing fancy.
Although I've never asked or been asked it in interview context, reversing a binary tree specifically is probably just checking you understand how to write recursive functions. Binary, because variable number of child nodes would make the code longer and more complex for no good reason. Reverse, because that's the simplest operation you can do at each node.
People in this thread are acting like tree processing is as exotic as theorem proving, and could never have anything imaginable to do with daily work, but every web page is literally a tree!
Time complexity often comes up in these problems too, so it's not enough to just know the requisite parts of the problem you need to have memorized specific approaches unless you plan on doing some theory crafting mid interview...
And it's not like you can't find out of the applicant knows recursion and what a tree is without bringing in memorization, there's just some weird obsession with a very specific type of problem which happens to often involve memorization
I don’t understand why reversing a binary tree has become a favorite punching bag of the popular ire against programming interviews. It is an instance of the question: do you understand recursion from a discrete math perspective?
I’ve never been asked this question, so I haven’t “memorized” it as you say, but if you want to flip the order of all the nodes in a binary tree, you’ll need to at least reverse the left and right subtrees at some point. The understanding recursion part is knowing that reversing the subtrees is the same operation as reversing the main tree. In that way, it’s similar to the recursive solution to the Tower of Hanoi.
"I went on HN Who's Hiring, looked for people hiring data scientists or python web developers (pretty much everyone) and sent out resumes. [...] I had no idea [...] whatever I was supposed to do with some of the probability related word problems I got."
What do data scientists do?
"...I use an ORM, rarely do I need to write a query by hand...."
"I had been working as a consultant and/or starting companies for almost 10 years and found the b2b sales process is literally nothing like the hiring process for SV companies. In one we talked about project goals and solutions, in the other we talked about hypothetical word problems that I have no doubt are popular in CS programs."
And yet, one of the two failed while the other has job openings.
The title is very broad and it could mean a bunch of different things at different companies. But it almost always involves a solid understanding of statistics, hence the probability questions in the interviews.
GP might have been asking a rhetorical question. A data scientist's job is literally figuring out what they are "supposed to do with [...] probability related word problems".
So from the article, it seemed that the interviews were quite relevant to the jobs advertised, and that the applicant truly was not a good fit for them.
> about 20 of these in-person interviews going poorly ... it seemed like everyone I interviewed with was a caricature of narcissism and delusions of grandeur.
instead of reflecting over if maybe maths is actually on topic for a data science job.
It's also odd, I think, that the companies didn't ask some probability questions in a phone screen, saving time for him and themselves.
Data scientists also do a lot of SQL queries. The point is that this guy appears to have explained why he's not getting offers in the blog post, possibly without realising it: maybe he doesn't have the skills he claims to have.
Your comment starts out making sense then starts to make some weird assumptions and makes the same mistake you're calling out in reverse...
Like "easy", who defines that? Is it easy because it just takes time? By that logic most things in tech are easy right?
In reality it's time spent on stuff often not relevant to a job at all, it's being used as an artificial filter.
Remember this isn't just about knowing, it's about being able to regurgitate it from memory on demand in a timed high pressure test
> has nothing to do with your educational background
Yes it does? People learn this stuff literally because of their educational background.
You can do some pretty amazing things in tech never memorizing half the things you'd need to for Leetcode.
--
I'm self-taught, and I know my data structures and algorithms, but I don't know algorithms and their nuances by heart so I don't Leetcode nearly as well as my YOE implies.
I see it as a two way street though, I don't want to work at a place that will turn someone down for not running a hamster wheel...
The venn diagram of "positions that need you to know this without any time to look them up" and "positions that ask you to know them without looking them up during the interview" is practically two circles touching.
I have no problem for jobs that actually need that mind you, but so many jobs couldn't tell you where the practical application of their Leetcode questions would ever come up on the job if their lives depended on it
It's never been a blocker for me, my TC is easily as high as what it'd be at Google or FB and I work on cool things.
Just because I learned this stuff 15 years ago doesn't mean I wouldn't need to relearn it exactly as I did back then.
Surprise, I never needed to manually balance a binary tree for work, and mostly people don't. So I don't see how "it's easy and free to (re)learn" says anything when hardly any software developer who didn't just graduate a year ago remembers this stuff by heart.
Also I'd like to think I know enough about most data structures to recognize where they make sense and to get into implementing using them quickly. But quickly doesn't mean "all of them" or "during the interview" or even "preparing everything in the utmost detail as they would ask without reference material". Teachers also don't explain complicated stuff without preparation, unless it's the material they do every year for many years.
The needless gatekeeping that is “create a linked list” or “reverse a binary tree” or my favorite: sort these arbitrary list of items are stupid. The thing is they’re used as a proxy for intelligence and I think they don’t work. Think of all the countless folks who cram for these interviews and then can’t actually write code in a real setting, use git, or manage expectations. This guy could do all of those things as shown by his successful consulting work.
I agree, the guy should of noticed a pattern after the first few, and being unemployed and thus didn't have a job taking up his time actually systematically go through cracking the coding interview or other similar resources full time for a few months. Then he'd be basically be set for life.
Yet, if you want to pass a technical interview, that's the game. If you would like to introspect, having a large number of passes before you changed course was unnecessary.
I also interviewed and received job offers after burning out at startups, i listened to the advice to spend 6 weeks on hacker rank and top coder. I passed all my technical interviews. I was also coding on two personal open source projects, but practical cussing and interview coding are 90 pct different as you say.
I don't know if i will succeed at having impact at a large company. Tell you in 6 months. But i am iterating fast and following advice of the people around me.
You didn't mention the effect of being unemployable because your standards are going up. This is an occupational hazard of having more experience. Sorry about that, there are things you can't unsee . It happens to everyone, and an underdiscussed reason there are more young coders. Good luck.
Once i was given what I call a "brogrammer" code test. I looked at it, said not interested in brogrammer env. Fast forward 4 years, person I knew became VP. He asked what I thought.
I laid it out to him, that brogrammers are collective tards that cant think on their own, BUT they are good at things like code interviews. I was hired as director. The 2 people who said no cause I said no to their brogramming crap. I personally let go in 4 weeks. 2 years later, things were fixed, I got a fat check, and moved on.
Lesson? Uncle Bob and his elk are creating problems that you can be paid to solve. However Uncle bob and crew are great at brainwashing.
For people stating the knowledge is useless, here is how it has been useful for me.
Graphs: HTML is a tree, it’s easier to think about performance. Also, I once made a simple DSL like HTML and had to implement quite a few graphs traversal algo’s.
Heap overflows: I did one on htb. Being able to algorithmically think about pointers being overwritten and memory layout feels a lot like interviewing.
Trading: one algo trader I made needed speed. I had to go much further than most things I see on Leetcode.
In general: algorithms is the ability to think step by step in your mind without a debugger. That skill is quite important when the going gets tough.
Note: I am not for this interview style. AllI am saying is, it is not without merit. Or would you rather do a 40h take home assignment? (Same thing, not without merit but 40h?)
Finally, thanks to your comment, I understand the whiteboard interview. I couldn't for the life of me understand how hiring for software engineers was conducted in such a ridiculous manner (i.e. not anything like the job you are going to do), but like someone else said on here, it's a dance that proves your proficiency to learn technical concepts.
I'm genuinely curious, what are you all guys doing? Why are you not using CS in your jobs?
I've never worked in a large company, never had a salary that is even close to US engineer level, and yet I regularly write code that traverses complex graph structures (often with recursive CTEs in SQL), just because that's how a lot of real-life data is structured. I spent this weekend debugging this traversal, in fact. And that's only the 'trees and graphs' example from the top of my head, as I've found myself constantly using all the different CS stuff throughout my career.
This is not an attempt to attack anyone or an attempt to appear superior. If anything, I'm constantly reminded by how stupid and uneducated I am when I'm reading HN comments. I'm just trying to understand: are you guys really spending your whole days changing button colours?
Writing applications (web apps, jobs, desktop apps, occasionally something worse) that basically act like a front end to a database. By that I don’t mean frontend as in the frontend web stack but the backend is mostly just a series of API endpoints or screens that call an associated database procedure. Often times there’s some light massaging or transforming of the data to be more presentable. Usually with mildly legacy technology (think older .NET, Java, jQuery. Shit I just got finished pumping out a greenfield Access project).
I’d like to do other things, but this is the only sort of thing I think I’ve ever gotten an interview for.
> I'm just trying to understand: are you guys really spending your whole days changing button colours?
Not quite like that, but it isn’t uncommon for me to spend time making minor changes because the business area helping with requirements can’t remember what they wanted one day to the next. I wouldn’t like if I said there are many days I spend mostly doing nothing, just waiting for some process or for someone’s calendar to free up before anything can continue. This has been common at all jobs I’ve had except one, where I was a contractor hired to do an extremely specific task for a very small company.
I’ve started working in other things in my (abundant) spare time, hoping they’ll help me get somewhere, but I’ll see.
Even if you are self-taught, you should know what is a binary tree and how idea of reversing it applies. From there you should be able to easily come up with a makeshift algorithm or ask if you can google a solution (as this is what you would be doing at the job anyway), find best answer and then apply it to the problem.
I think most important part in this job is being able to find a good solution quickly if you cannot code it straight from your head.
Being offended by any question and the attitude "I did X therefore I cannot Y" is what disqualifies you.
There is nothing worse than an employee who thinks they know everything or that they don't need to know something and feel too superior to ask how or to find an answer from someone else.
I would suggest at least trying a therapy to get to the bottom of why you behave in such a way. Sometimes a simple change in thinking can lead to a dramatic transformation.
Can't agree you more. I also viewed interviews as absurd process before, then I changed my mind. It is actually useful, it can tell that 1) you want the job, hence you make the effort of preparation; 2) you are able to learn.
I have some experience with this. My advice: pick the skill that you are absolutely strongest at from a specialist's viewpoint and interview for that role. Once you are in, you will find your generalist skills help you excel quickly. It is annoying that interviews can't capture broad skill sets, but it is also widely known. It means you have to prep! Dive deep and practice the well known interview questions for the specialty you pick.
I’m a reasonably successful entrepreneur, but I’ve been fired or quit every FT position I’ve had. FTE is just a total different experience from running a company and being good at one is different from being good at the other. The only middle ground I’ve found that has worked for me has been consulting where I’m still my own boss and can pick up small projects here and there.
Being an entrepreneur is a high risk / high reward venture though and we’re not entitled to an easy, well paid salary if we fail.
Great read though and glad the author found their groove eventually. A salaried position doesn’t have to be the default fall back.
How old are you and do you plan to have kids? If yes, when? I am always very curious about how indiehackers/digital nomads think about having a family (or not)
I have the reverse question: if you have bandwidth to be able to do 20 interviews and you already know they do ask these inane leetcode questions, why wasn’t it possible to sink a month into solving a few of those and then interviewing?
It is hard to take folks for their resume or at their word alone. The inane questions just provide a common framework for evaluation. It is definitely not indicative of actual work to be done. It is totally an indicator for someone willing to pick up a new skill and learn in a short window. We in fact get the other kind of candidates as well: who can solve these problems very well but can’t do good work. So the interviews at snap at least try to go for a combination of informational and design/technical questions.
Ignore the feedback - we are not really allowed to give exact feedback because of liability issues :/. So it is going to be some super high level things you can’t sue us for.
I agree - you really should sink time into preparing if you can. We prepare for all kinds of other things, but a surprising number of people won't prepare for interviews that are massively affecting the trajectory of their lives.
Leil Lowndes writes books on improving as a communicator, not about tech, but one of her pieces of advice for interviews is to interview at places you don't want to work first, and treat it as practice. In her case the recommendation is meant for people who struggle with being comfortable presenting themselves and talking, but it applies just as well in other contexts.
E.g. find some jobs you're clearly qualified for where you're likely to get an interview relatively easily. Drop your standards - your goal is not to get hired. See what questions you're asked. Use the experience to improve. Amp up the "difficulty" if you get offers.
See how the questions differ, and how the process differs if you try for more challenging positions.
Then go for the job you want.
Figuring out how to pass the interviews in "low risk" situations (because you don't really want the job) is both good practice, good calibration of expectations of what kind of job you can get, and a good way to relax more when you apply for the dream job.
Yeah I'm not surprised he's burned out after doing 20 interviews lol. You have to pace yourself. This guy sounds like the kind of person who bull rushes into things and burns himself out.
Skimming through the article, this seems to be an exaggeration. He may be unemployable at some companies; maybe even at most companies that advertise on HN; but I am sure there are companies that don't ask for inversions of binary trees, theory of probability, etc. during interviews. They may not pay as much as the ones that do; but surely he is far from unemployable.
>A job at a typical startup has no boundaries and feels like a cult.
At the same time , they'll often take a chance on someone who on paper isn't qualified. That's how I got into this industry.
Has anyone been able to hire a general businesses person to manage the day to day boring parts. I'd like to keep working full time while paying someone to run my startup
You could message me or put a contact on your profile! I'm an strategy and ops guy (consulting, now FAANG) interested in helping startups grow. Would be interesting to explore this problem further.
I honestly wouldn't have the money to pay someone at your level. At best I can pay a college kid $30 an hour to maybe work on the business 10 hours a week.
Which if you remember being in college, is a decent amount
A lot of students start internship where I work and quite often I am their mentor officially or not so. Recently their dean called me and offered to lecture at the university. I am an engineer with 20 years of experience, I can teach a lot of useful practical things, but when I looked into syllabus it was a list of mostly useless theoretical knowledge I am no expert in. Honestly, it was not a pleasant moment, I felt like a successful plumber.
C'est la vie. The disconnect between college and industry has always existed I think.
My guess is that what students really want is a lecture in how to get a job, not how to be useful in a job. OJT and fakeittillyoumakeit would then become the order of the day.
I wonder sometimes why I don't hear more about apprenticeships by the nation-state sized companies. Bring in likely 17 year olds and train them in whatever specialized way you like.
Perhaps some of all this interview nonsense could be avoided by commonly recognized software equivalents of a PE cert, but I suppose you'd simply slide into subtle quizzes about programming languages and the like.
It's hard for me to understand how someone that portrays themselves as intelligent, successful and on top of that mentions HN didn't understand how the tech recruitment works.
614 comments
[ 0.17 ms ] story [ 360 ms ] threadLife is too short to engage in nonsense unnecessarily.
There is a world of other more enjoyable and educational opportunities out there they must compete with. And so the cash shovel must be pulled out.
People vote with their feet, and then a new generation of fresh grads are lured by the pay to fill their role. They’ll grow sick of it in a few years, rinse and repeat.
I know it’s not a good advice in general, but regarding recruiting in particular, it’s a more realistic proposition.
If you know how to program, you have lots of options.
That depends entirely on how you choose to define "fools".
I am not going to disadvantage myself by refusing to participate in this on some questionable principle. While I agree that Leetcode-style interviews are not the overall best, I am yet to come up with an alternative that addresses all those issues without introducing massive new ones. So it is a compromise. And as long as this compromise stands, I am fully intending on getting the most out of it.
Personally I think 6 Leetcode interview loops is better than 6 take homes, but that’s just me.
Ah well, probably goes to show that everybody picks different threads/posts to read
Why would you spend six months preparing for them when you could build and launch an entirely new product in the same amount of time, which has a much higher expected value?
If you land the job, you have a guaranteed, pre-specified income. Probably a high one, depending on the company.
The massive risk of failure with launching a product should dramatically lower the expected value. Especially since most products, even if successful, won't pay as well as the corporate job.
I think that puts a negative tone on people with other degrees than CS, even if they have good software experience, or are older with life commitments. Jobs and interviews in past did not ask this stuff, yet it's now implicitly considered prep. It's biased towards new CS grads and young folks.
Many/most? companies needing devs do not use/need these CS "fundamentals", which do not automatically correspond with tech skills needed to do product development, at least in SaaS world.
Are they? I often read this on HN, but I'm starting to wonder if there's not a selection bias that's even bigger than I expected. Beyond the usual suspects, I've had more coding assignments for instance.
Of course, hnewslets who get filtered by such interviews will come downvote in force.
One would think the same topic showing up "over and over again" would make it easier to study for interviews
This really isn't a place for lazy, ad hominem attacks.
(I say this as someone with a weird background/employment history who'd be at a fair disadvantage in many respects if they had to get a normal job - but I know I can get a bit of normie cred by brushing up my algorithms at least...)
I suspect you could teach someone to pass a lot of tech interviews without them ever building a production system.
It's all a bit broken. Best method I've seen so far is to sit down with candidates and pair on some code, and it's still got issues.
Im not saying its right, just that it didnt come naturally to me to be in that situation.
If you feel it's out of your control, it could've just been a bad day, but you may be suffering from something like generalized anxiety or a similar problem, you might want to look into that with a health professional.
Im just saying its thanks to my instinct that I have been so successful in my life, and I have never lost anything by refusing fizz buzz, yet have attained good things.
Maybe its survivorship bias.
It goes against my rules to proceed in interviews I think don't lend themselves to the situation.
The most substantial and complex projects I've worked on can end up sounding simple and boring when I describe them. It's not that I can't discuss the details, it's just that I'm not good at _selling_ them. I tend to stick to facts and give a simple overview of the project, and I'm never sure how to approach the gritty details. And honestly, the right choice at the time was likely "Pair a MySQL db with a cron job" or something, and that sounds really underwhelming in an interview.
On the other hand, I've heard people describe projects they worked on, and you'd have thought they were leading the charge on the reinvention of Internet. But when you do the math on their resume, they were two months out of university at the time.
Those types of interviews basically and inevitably end up being "tell me a good story". Non-fiction is preferred, but interesting fiction will win out over boring reality.
Maybe I was just lucky, but I think you don't have to be all "florid", just show enthusiasm when talking about what you did, and it doesn't have to come from the vocabulary; people can tell whether you're enthusiastic from your tone.
Most day-to-day "programming" can be broken down into that "Pair a datastore with a processor" idea, or "know enough about the problem to google/SO a fix or solution," so I don't think being honest about the mundane is a bad quality. Honestly, I think it's important enough, to make it at least a few of my questions on any formal interview, something akin to "what was a project that you thought would be simple but turned into something bigger, and how did you handle communication and management of it from that point forward?"
When interviewing you can ask the candidate for details on their MySQL + cron job and investigate how do they think, architect and build a solution and how much bullshit they're talking. Were you given a very detailed task to perform and you just did it? Or did you reach the conclusion that a MySQL DB plus a cron job would achieve the results? Why? What if the cron job failed? Draw a rough flowchart of your script, etc.
On the other hand, you can smell the bullshit of interesting fictions from a long distance when you ask those probing questions.
Now, an interview on basic CS algorithms? The only thing I would know is that you have a good memory and can recall the Cracking the Code Interview book.
It might come down to who is doing the interview: if you're a founder, or a team leader, and have done a lot of project management, you're likely to ask better questions about constraints, considerations, teamwork, etc, and get a better read on a candidate from questions about past experience. OTOH, a programmer giving an interview may not really care that much about those aspects or have a realistic idea of what a reasonable answer sounds like, and will thus tend to just jump through the interview hoops--and be more susceptible to, well, nonsense. On the other hand, they may actually be interested and invested in low-level technical questions.
I've had really good tech interviews that were challenging and even fun, and I don't think I could've faked my way through. I've never had a good experiential interview. But then, I've only ever interviewed for front-line programming jobs at large companies.
1. FizzBuzz, always, unironically; this easily weeds out 99% of the people who can’t program. I don’t even ask for an elegant solution, just a solution that works, in any language they choose.
2. Open question/toy problem that doesn’t involve hardcore technical knowledge, just common sense. The question is framed in a way that the candidate can grasp an actual use case - e.g. “How would you design a database for a public library?” I would explain concepts like PK and FK on the spot if needed. I even let them use the internet to look up whatever they need. The idea is not to see how much stuff they have memorized from leetcode, but to see their thinking process and whether they are resourceful and ask the right questions. Seriously, some people don’t even know what keywords, not even approximate ones, to use to Google stuff.
Resourcefulness and asking the right questions have much higher priorities on my list of things to look for in candidates.
Then why ask it? This is the whole reason for my stance
Fizz buzz is literally a couple IF statements and a loop.
As an interviewer, I need to know that you aren't just completely making everything up.
This is an actual problem. There are actually people who, for some reason or another, made up a bunch of stuff on their resume and literally do not know how to use a loop or IF statement, and there is no way to know this, unless you ask them to do it.
It is not an insult against you. It is just that an interviewer needs some small very easy check, just to make sure that you didn't completely make everything up.
Where is the line drawn?
If there is 20 years of programming experience it could be perceived as an insult in my opinion.
> Where is the line drawn?
The line would be drawn at the place where like 20% of people who interview at places legitimately can't solve fizz buzz.
If I lived in a bizarro universe, where 20% of people that I talk too legitimately can't drink a glass of water, then I might have to test for that as well.
Fortunately, we aren't in that kind of situation yet.
> If there is 20 years of programming experience it could be perceived as an insult in my opinion.
Ok, and what about the people who put 20 years of programming experience on their resume and are just making everything up, and legitimately don't know even the basics of coding?
Thats the problem that exists in the world. That there are people who you have no way of knowing how to actually code at all, and exaggerated to an extreme degree on their resume.
How else would you suggest figuring out if the person that I am talking to basically just completely made everything up, or is instead just such a good talker that they can bluff their way into people thinking that they know what they are doing?
The whole point would be that someone who knows how to program at all, should pass.
Giving a complex problem would defeat the point.
You can just sit and chat like you're friends but that's going to bias the interview process to "people who I like" which is just "people who are like me".
I'm sure there are LeetCode questions that are more & less predictive of success but it does have the benefit of removing much of the bias in the hiring process, at the expense of requiring candidates to do some prep work. If you don't want to do the prep work then there are plenty of other places you can work.
I think one challenge in these conversations is that people talk about what the interview process should or shouldn't look like without talking about what the interview process is trying to optimize for. And each person is going to have different ideas of what they should be optimizing for in an interview so they'll have different interview solutions. Then you argue about the solutions but the reason you disagree is because you're starting with different goals.
while there's a lot of other things I value in coworkers, and I want a diverse mix, I really trust a coworker much more who I know can reason through, can see how the code will execute, and understand what that implies, can find & state the significance.
there's a lot of here & now tests of ability in programming, to understand syntax, language, side effects, &c. but bring able to reason about runtimes, about this then that then that... it's the bigger picture. we have some pretty basic promise questions in our interviews, & it's so remarkable how many people get cut for now being able to understand sequencing, how a little async behavior trips so many up. not quite the classic algorithm test, but to me, they seem extremely similar in that they want the dev to be able to order & comprehend how things work.
I agree that a lot of pushback against algorithms is deserved. they are misused as a hiring bar frequently. but there is also things I value a lot, & they help elaborate whether a dev grasps coding situations or no.
As a person with a diverse background and even more diverse interests, who likes to use jobs to learn things I don't know rather than simply apply things I do know, I use interviews as a natural filter. It can be rather unpleasant and frustrating at times, but in the end, it's better I don't work for some place that interviews like they got their process out of some Silicon Valley playbook.
This.
When I see people getting all het up over technical interviews on various moral grounds, one notes that they often forgo reflecting over the possibility that any replacements could be even more bullshit/arbitrary/exclusionary.
> but I know I can get a bit of normie cred by brushing up my algorithms at least...
So I guess the question would be “why do you want normie cred?”, and then the rest of my comment remains the same.
I have a history of self-employment and little formal education in programming per se. It might put potential employers at ease to be able to exhibit some conventional chops, and that kind of interview segment would give me an opportunity to. And algorithm-questions being more or less role-agnostic might mean less preparation rather than more for interviews when one is doing a bunch. OTOH if you want a particular role you should probably better brush up on what's needed for that role and show each application you make some individual love rather than hoping that you can carpet bomb tech company interviews in your city with algorithm-knowhow-powered interviews and get a job out of it.
Given how theoretical this discussion is for me, I feel like I'm slipping into being some kind of devil's advocate role now. I would like to apologise to anyone (basically everyone else here will have more experience with tech interviews than I have) who's reading this rolling their eyes.
My experience has been rough and painful at times, because I tend to be very pragmatically and interest driven in terms of what I learn, outside of being pragmatic about what might be asked in interviews. I also do not have a computer science degree, as I studied mathematics, but I self-study on interests of mine and take interviews as they come. This has made interviews rough at moments, but it's worked out so far, because I would likely be very unhappy at a place that quizzes me on something I could learn over a weekend or two if needed and grades me solely on that. I had one particular interview that wasted an hour and a half on tree questions, then a few more hours on random discussion topics and behavioral questions, and they never once asked me about prior work or side projects. It was a complete waste of time and energy, for both of us, and I have held that interview experience as a prime example of what I have read about Silicon Valley and FAANG-style interviews.
This just proves that you can memorize a cheat sheet. What good is having interviews if they are so predictable that the applicant basically just repeats himself over and over again? That isn't an interview. That is gatekeeping. "Do you know the secret handshake?"
I don't know the entire multiplication table by heart, but I know how to multiply. But that's not what interviewers are testing for. They basically want to see you rattle off a chart from memory as though that's a non-arbitrary universal indicator of capability.
Of course, that doesn't really change the fact that the content of the questions has little to do with the work you'll end up doing. But I've done brainstorming with coworkers, and none of us had any ideas for interview approaches that would work better--except maybe those 2-day take-home projects that everybody hates. I think I remember a paper claiming that random acceptance would work about as well as the current interview process.
Problem is, the percentage of skilled interviewers is likely not much higher than the percentage of skilled candidates.
I don't really get why "reversing a binary tree" seem to be used as an example of what's wrong with hiring. I will say, though, that if someone said "how do you reverse a binary tree?" I would have asked the follow up question: "what do you mean by that?". If asking that would be used against me, sure, that's bad hiring.
But if the answer is: "swap all the left and right nodes in a binary tree", then... isn't that pretty basic programming?
I find high end jobs tend to ask some form of problem that can be tackled using dynamic programming techniques. Maybe couple of easier ones in the first interview.
I agree with most people. I never use these skills in the job. I think they're a intelligence test in disguise.
I mostly agree with your impression, though even after adjusting for intelligence I bet there's a positive correlation between knowing how B-trees work and, say, having a good intuition for how to index a database.
But the purpose of the question of course is to be an easy question showing basic competency in recursion and pointer usage.
It’s not some arcade high art, it’s quite accessible with lots of great learning guides.
If you choose not to play the game, your pool of potential companies will be quite limited.
On the other hand, reversing a tree and problems like fizz buzz are pretty low bars...
Mostly HC is a ton of work (eg read 8 full interview packets a week) so if you express an interest and are a decent interviewer you’re likely to get shot at it and you can make a real difference.
I didn’t need to know 4+ years of CS curriculum, which I never would have learned on my own. I just needed to spend some time learning algorithms and data structures, and practice using free resources on the Internet.
A pretty good deal for non-people who didn’t study CS in college.
In fact, someone who studied CS in college might be slightly miffed that they offered a job to an outsider like me just because I practiced data structures problems in my free time.
It’s a string of poor decisions/planning followed by an unproductive rant. I don’t particularly like leet code style interview questions either, Author could take a few months and brush up if they’re a proficient engineer or if they’re really opposed then pre-filter companies based on their interview style. Author could find a corporation outside of FAANG that isn't idealogically abhorrent. Author could look for windows shops. Author could consult (sounds like they’ve been successful with this approach).
I suspect the author just isn’t that great of an entrepreneur and tried to pivot into a high paying engineering role they just aren't really qualified for either.
I agree about the SF observation at the end. If SF culture isn't working for you then explore elsewhere. I wish more people realized this before assuming they need to be in the bay area to be successful. It’s a pretty limiting and potentially damaging assumption and I’ve seen people get super distraught about the idea of being anywhere else because they drank all the VC urban tech hub cool-aid and are just starting to come down.
Feel free to ignore if the answer is no.
CS fundamentals have a big impact on the kinds of programs that individuals can write. Asking questions to show that a candidate can write a DFS, leverage multiple data-structures, or do X helps ensure that the individual is capable in this regard. Even for experienced candidates with lengthy portfolios you may find that someone drifted into an operational, management, or product role and has forgotten how to effectively program.
However, the format of the whiteboard interview is awful and if one doesn't practice for it it won't turn out well. I'd love for there to be an alternative, but the other options all have their own cons.
1. Take home tests/projects
2. Github projects/portfolio review 3. Pair coding The only alternative I've seen is a "functional interview". Where the candidate is given sample code reviews for standard applications or a broken program to debug.Sadly, there seems to be very little correlation though. I've known programmers who graduated from a top CS school with extremely strong CS knowledge, who still write barely comprehensible code. And vice versa, people who have never been taught big-O, but who write the most maintainable, well-reasoned code I've seen. Most programmers aren't building e.g. databases, but writing software that provides business value.
Take home tests can be ok, as long as they are limited in time (<2h). I was adverse to pair coding, but found it to be not as bad as I thought, unless it's 100% pairing all the time. Well, whatever the solution, I think anything that's closer to what day-to-day work at a company looks like is going to give richer feedback/signals than whiteboarding.
Ideally I'd want to interview for both skills.
I can’t help but feel that people who think otherwise have never worked in literally any other field for any amount of time. Like it or not, you have to narrow down any candidate pool to like 1% of applicants before doing any sort of in person interviewing. Most places do this by only hiring people with degrees. If you’re talking about a job that’s going to pay as much as a software engineer, you can probably get away with only hiring people from elite universities, or who have connections within the company.
Frankly to me the author comes off as arrogant and entitled. He feels he shouldn’t have to prove his worth because... he ran a failed startup? Then when his friends give him a job, literally the definition of nepotism, that still isn’t good enough? What does OP want? A system where only the best jobs are gained by nepotism?
This attitude is condescending towards those that come from diverse and non-traditional backgrounds, most of whom are perfectly capable of learning and developing an active interest in these subjects.
A lot of the annoyances with SF companies just go away (of course, there are new problems too). Nobody will ask you to implement a red-black tree from memory, you can consistently work under 40 hours a week, and interviews are more focused on behavioral questions and project experience. If you're ok with a salary in the low 6 figures, it's really not bad.
Leaving the country isn't "drastic": 96% of humans live outside of America.
Do 96% of English speakers live outside of America tho?
> we left there for a reason.
Yups. So did immigrants who came from outside the US now living in the big coastals.
While your absolute salary is less, your purchasing power is far greater compared to SV, SF and LA. I know someone is going to pick some outliers like NYC, Seattle and so forth. There's still more places to live than that.
Though that's probably less of an issue if consulting.
Sure, you might end up moving in a year or two when the job plays out, but you can just move to another non-coastal town. Be flexible and follow the jobs, and you'll see more disparate types of environments (and learn more about how different people think) than you ever could. You can learn pretty much everything there is to learn from a given team in less than six months, so looking at it as a consulting or training gig (even if it's a full-time job) can give you a much stronger resume. (Bonus, you learn people skills from dealing with people from many different regions and backgrounds.)
We all love to open HN and read the new PG essay and dream "I am the one", but the odds are not in our favor.
The extreme survivorship bias also doesn't help. But honestly, I don't know what the ideal solution is.
Even though I read stories like these, hear all about how the odds are stacked against, how difficult and hard it can be, I keep wondering a simple "What if?".
I guess you could say that there can be a 100 reasons not to do something, and yet one good reason why is more than enough to offset the 100 bad ones.
A CS degree isn’t hard to get in the grand scheme of things, and not getting one is basically the equivalent of burning your boat and going all in to whatever alternative path you choose, because if you fail you’ll just end up unemployable later on.
If the degree on the resume puts those people into the "pass" bucket automatically, that is the wrong approach.
That probably wouldn't fly as well today or going forward as the field matures. Get your CS degree.
To be honest, I can see requiring a degree for certain positions. But given the work most software devs are doing, I'd be happy to consider 4 years work experience. The number of times I need someone to invert a binary tree so far is 0, but the number of times I've needed someone to build some basic CRUD functionality following a UX spec is too numerous to mention. I don't need my degree to do the latter; I don't need to hire a degreed person to do it either. And even things that a degree might help with (recognizing an O(n^2) implementation when an O(n) is available) are lessons you can learn pragmatically by doing (i.e., having senior engineers point out issues in code review).
And I agree with almost every opinion you may have on this; but the thing is, it is just harder to come by a decent opportunity without it. Nice that you try to set your foot in the door here politically, but the cost for that is being on a crappier job.
I was an idealist too, 20 years ago...
Pro - You might get hired by xwdv.
Con - You might get hired by xwdv.
So far the cons seem to outweigh the pro's for me.
If someone has a legit work history in our industry, but no CS degree, and their resume otherwise makes them look like a good fit, you should interview them. At worst they are terrible and you waste a few hours of your time.
Imagine what this guy looks like from the hiring managers side. Would you take the risk of hiring him for a software engineering position? Do you have any confirmation whatsoever that he can even write a single line of code? Yeah sure, he founded a startup, but you literally have no idea who wrote the actual code there or even if anything functional was even produced. Maybe the reason the startup failed is because the software was incompetent.
I get it. We all hate reversing a binary tree, and most likely we'll never have to do it in day to day work. But here's the thing, almost anyone who can reverse a binary tree on a whiteboard has basic competence at writing code. The reverse isn't necessarily true. There are lots of great coders who aren't good at whiteboard interviews. But hiring managers don't care about false negatives. Bad hires cost a truly staggering amount of money, overlooked candidates cost virtually nothing.
When I hear or read about people who are failing to get SWE jobs, it's usually because they do not have any demonstrable credibility of basic competence at writing code. To get a seat at the table you must bring at least one of the following: a pedigree, a network of credible people who can vouch for you, your name publicly attached to a successful project or the ability to crush whiteboard interviews. A manager that hires somebody who meets none of those criteria is taking an enormous risk.
I wouldn't go that far. While the work involved may not be that hard, a CS degree may be inaccessible or a poor fit for many people.
That said, I agree with the premise that it is hard to evaluate self-taught individuals. It is far too easy to have gaps in knowledge if one doesn't approach their studies systematically, it is difficult for the learner to assess their own learning without a realistic baseline to compare against, and too many businesses oversell the quality of their programs (e.g. bootcamps).
I’m not going to call it hard quote yet, but I’ve been a bit shocked at just how much the university process is designed specifically for 17/18 years olds prepped and groomed the past few years for it. There seems to be little at all in the way go good education options for working adults and what little is directly targeted at that demographic, even from otherwise legitimate schools, feels extremely (I’d be happy to expand in this but I want to keep this comment short-ish)
Runs startup. It fails.
Makes a game. It fails.
Fair enough, those things are really hard to do.
Gets into tech interview, asked a question he doesn't know the answer to and DOES NOT RESEARCH THE ANSWER FOR THE NEXT INTERVIEW?
Now I'm starting to understand why the startup and game failed. Sure, reversing a tree is arbitrary. However, when there's a 6 figure job on the other side of that arbitrary line... it's probably worth learning.
... and when the inquiries will inevitably come, just politely reject doing interviews with code questions, etc., and turn on the offence! Ask them yourself about the task and if it might interest you enough, so you will be motivated to work on it. Your ideal interview should be more about THEM, not about YOU. It might take a while to master this skill, but used right you can totally dominate the interview process and hire yourself into almost any company which is desperate for developers.
I'm a developer with more than 30 years experience including some well known products from big companies. The same is true of my circle of friends but only two still have traditional tech jobs. The rest have gone independent out of necessity.
All that to say I’d suggest candidates be more willing to ask for help. Interviewers are people too and if you can code a solution easily after getting unblocked they might forget you ever asked for help, or respect you more for it.
This doesn't really seem unfair as ORMs stop working at a certain level. He seemed to have been targeting companies doing more complex things than he was previously doing.
This skillset just isn't that useful to a large software shop.
Startups are fun. I work at one now. 3/4 software engineering roles I have had have been startups. But all the work I am doing is also very shallow because everything is a fail fast timeboxed sort of thing where you work across a large spectrum of stuff and I will eventually need to change that.
You’re simultaneously doing some of the hardest work of your life but also watching some of your skills atrophy simply because you’re spread so thing across so many different problems.
Startup founders tend to make good product managers or cross-discipline engineering managers for this reason, but it can take some time to slide back into the groove of deep technical work in specific domains.
Basically this guy discovered he is not actually very deep but has not actually concluded that from the evidence before him.
Reminds me of this thread - https://twitter.com/awilkinson/status/1376985854229504007
I don't buy apple products anymore because of the walled garden bullshit that permeates apple's vision of the world.
Linux is a fine dev environment. That interviewer was an idiot.
And that's exactly why your experience was the way it was. HN is a self-selected crowd with a very specific mentality. Unsolicited advice: try a traditional job search website and look for companies outside of California and NYC. Your experience will be drastically different. I'm not saying it will be awesome every single time, but there will be more diversity in approaches to interviewing and in personalities.
Also - sometimes you just need to get your foot in the door somewhere that's not too picky and caters to what you're looking for but pays slightly lower than what you want. Then prove that you're actually as good as you say, so you can ask for a raise. I did exactly that with my current employer. After 4 months of being there and proving myself, I asked for a 35K pay raise (about 27%!) and got it almost instantaneously.
It's a strange tone to take? The buried lede is: "[I] travel around and work as a digital nomad. I've been doing that for a couple of years now and I work an average of 2.5 days per week on machine learning or web projects and have rebuilt my savings and my whole life."
That sounds incredible! Like, the article should be titled "I'm winning at life".
Most scale up / startups would love ex founders to help them.
I find a sentiment like this pretty scary. Being competent at a job is not relevant, but just whether or not the interviewer subjectively likes you.
One of my top criteria for accepting a job is whether I like the interviewers.
I'm not hardcore in the "asshole geniuses should die" crowd, but if you are a miserable person to be around, go find a job where you work solo. Don't drag your whole team down.
I get what you're saying, but you spend 40+ hours a week with the people you work with, so the social stuff matters. If someone is really good at their job but a complete asshole to their coworkers, nobody is going to want to work with them, which will likely end up being a net negative for the company's productivity.
Most people feel bad when people act like assholes. Feeling bad enough, frequently enough, is cause for changing jobs for most people.
I'm confused by "you're not really a business". Are you the business owner at most of your jobs? Or do you tend to identify with the business you work for, sort of letting your ego merge with that of the organization during working hours?
I think saying "you're at a social club, too", is not a right way to frame it. A place of business is by definition a place where people are doing things together: business is social. Most people want to do social activities with people they can at least tolerate if not enjoy being around.
Now, if you are not of such a psychological make up that it really matters to you who you spend the majority of your waking time around, and you're able to compartmentalize strongly, then, it makes sense why you would be in the minority on this subject.
I think it could be important for you to realize that this is not really a matter of opinion in the sense of "a perspective on things that can be changed by experience or new information". This is really about folks' fundamental psychological make up.
>Do you tend to have emotional responses to the behaviors of others, or do negative behaviors roll off your back (like so much water off a duck's feathers)?
>Most people feel bad when people act like assholes. Feeling bad enough, frequently enough, is cause for changing jobs for most people.
So, I definitely get a bit ruffled when people are assholes, but I've also never found myself in a job where I can't at least push back on rude people and stake out some boundaries. In other words, I may not like interacting with some of the mean people, but I can find a way to work successfully with them, and ideally, even get past initial difficulties. When someone is dysfunctional enough, I frankly try to find ways to avoid that individual. Usually, if someone is that dysfunctional, everyone in the business knows it, and are trying to avoid them all the same.
A big fear I have is the distinction between a "truly dysfunctional person" and "someone who the interviewer didn't like during the interview." At least in my experience, first impressions aren't worth very much. And despite the fact that they aren't worth much, I've seen a number of people act as if their first impressions contain accurate and valuable information.
And, I suppose the point I'm trying to make is that I'm very afraid that someone will not like a good candidate during an interview, but would actually like them quite a bit once they actually got to work with them. I've actually just watched this scenario play out at my most recent job. Me and my team members interviewed a candidate who was very quiet and very shy. Those team members did not want to hire him because they were afraid he'd be a "poor fit." From talking to him, I felt that he seemed to be very intelligent, and so I vouched for him heavily. In hindsight, this has gone very well: he's one of the most productive members of the team, and is generally well liked. At worst, he hasn't had any conflicts with anyone. If I had not stepped it, it is unlikely he would have been hired, simply because people did not like his personality.
>I'm confused by "you're not really a business". Are you the business owner at most of your jobs? Or do you tend to identify with the business you work for, sort of letting your ego merge with that of the organization during working hours?
This is something I've struggled to articulate well, but I suppose I'm drawing a hard distinction between "accomplishing a specific work function," and "really liking a person I work with." Now, I'm not blind. I understand that there is some correlation here: a team of people who hate each other will generally be less effective than a team of people who all get along really well. I guess what I mean is that it feels to me that people are heavily prioritizing friends over function. Or, that people believe (incorrectly in my view) that if they find somebody disagreeable, it will be impossible to resolve differences and develop a good working relationship. In other words, the whole point of a business it to successfully complete some set of tasks. (build a thing, provide a service, etc.) I feel that if you too heavily prioritize working with people you like, eventually you're putting your social preferences ahead of actually running the business. In other words, we can all agree that all things being equal, a team of people that works well together will be more successful than one that does not. But what about a team of below average people who like each other a lot, vs. a team of brilliant geniuses who aren't much fun to be around? Clearly the choices between these two options will not always be that cut and dry. (and I've only provided a cut and dry example for the ease of explanation, not because I feel it is the most common scenario.) But, I feel that sociability is overemphasized because it preferred, not nec...
Cooperative work needs some form of positive bond, trust and feeling of being part of a team that looks out for each other. It doesn't need to reach 'social club' levels.
Truth is, you either have a cooperative unit or have smaller cooperative factions within the team that are competing or adversarial.
You don't want the second type of nonsense at your workplace.
Maybe you've not seen it in practice and that's why it doesn't make sense to you.
So when I say likability matters, what I'm saying is I need this person to be professional enough that we can work together day in and day out, and I don't want to routinely punch them in the face.
It's not "whether the interviewer likes you", it's whether you can work with other people without taking an emotional toll on them. And it is as important, if not more so, than their ability to program. It's certainly a harder thing to teach.
(as for this specific quote, I think it's fine to have issues with what companies are working on... But the rest of the article really does just come off as bitter and angry, and for what?)
There are tens or hundreds of thousands of skilled developers in the world, there's no reason to work with bitter, angry people.
Yes, because we've been burned by this in the past: firing somebody who's impossible to work with is WAY more difficult than just not hiring them in the first place.
The digital nomad life is probably somewhat relaxing, but he's clearly someone who values his accomplishments over his experiences, so I'm guessing that's why it wasn't the focus of this article.
Ooh, that hits in a soft place for me.
Therein lies all of the angst, unsettledness, and general escapisms of this post, and more probably the world. I've seen the happiest people on earth do so very little compared to traditional 'success,' because they mastered what they 'valued' first... then pursued it relentlessly.
Here's piece from Hunter S. Thompson (don't know if you really want to emulate all of his teachings), that gets at the heart of this values orientation:
"The answer—and, in a sense, the tragedy of life—is that we seek to understand the goal and not the man. We set up a goal which demands of us certain things: and we do these things. We adjust to the demands of a concept which CANNOT be valid. When you were young, let us say that you wanted to be a fireman. I feel reasonably safe in saying that you no longer want to be a fireman. Why? Because your perspective has changed. It’s not the fireman who has changed, but you."
https://lettersofnote.com/2016/07/18/a-man-has-to-be-somethi...
Thank you for that.
To be fair, I did literally have ideological issues with them -- such as the amount they track their users, their stance towards China, their use of patents, or just generally bad reputation in the industry -- there's a bunch of issues I feel strongly about and that prevents me from working with a lot of different companies. I guess that's a bit of a luxury, isn't it? But that's also my choice. I'm not exactly homeless these days, so I still manage to find great people to work with.
I am pretty cynical and stubborn... not sure about angry, as you say, "I'm winning at life".
> I just don't want to work with difficult, unhappy people.
Me neither!
I get that people can hit hard places, and that the author was in such a place. But I don't think the perspective given is an objective one, especially considering the author has had time for hindsight to settle in.
According to the blog post, they didn't proactively apply at companies they were interested in. They didn't bother catching up on new technologies or other skills sought after in the current market, spending their time on building a computer game instead. Interviewers are being vilified for acting in their own best interests rather than the author's conveniences.
They then finish up by becoming a digital nomad working 20 hour weeks and building up their savings and loving life. Where are the details that went into making that lifestyle work? Was it not due to being employable?
It's hard to sympathize with the author when the narrative is essentially "I put very little effort into getting hired and so had to work a little harder to get a job".
> So the author waited for people to come to them, and when nothing worked out, declared themself "unemployable" (despite not proactively looking for work).
There are two sections. There is the part where people reached out to me. Then there is the part where I went out and interviewed more proactively. And there is a lot of stuff in between that doesn't really fit into this blog post. So consider my version a simpler, abbreviated version than real life.
> According to the blog post, they didn't proactively apply at companies they were interested in.
I did apply at companies I was interested in. Why wouldn't I?
> They didn't bother catching up on new technologies or other skills sought after in the current market, spending their time on building a computer game instead.
So, I had just come off 5 years deeply immersed in the bleeding edge of deep learning and the beginnings of the wider application of this technology at various companies. Excuse me for wanting to try something different. Have you ever made a game before? Do you have any idea how technically involved it is? How does this not count as catching up on new technologies or other skills? I should have studied leet code interviews instead? I think I'd rather enjoy life and pursue things I find interesting.
> Interviewers are being vilified for acting in their own best interests rather than the author's conveniences.
No, they are being vilified for focusing on arbitrary things rather than focusing on things that are important to the actual job.
> It's hard to sympathize with the author when the narrative is essentially "I put very little effort into getting hired and so had to work a little harder to get a job".
I'm not looking for your sympathy and I don't know what part of my life story seems low effort to you.
Being opposed to working for companies that build business models around eroding privacy, delivering adverts faster, or even literally killing people in the case of weapons manufacturers isn't "bitter". Those are valid opinions. Not being willing to work for any company that will give you a paycheck without questioning the impact of what you're doing is a good thing.
It can be done. As a self-taught developer, and after years of startups and consulting, I got my first FAANG job at age 40. I hadn't done any real kind of interview in 15 years. I spent 90% of my time preparing for CS questions, and struggled at the first one, but ended up at FB, and Google a few years later.
My mindset wasn't that they really cared that I could do these obscure programming exercises that I hadn't used once in 20+ years of real-world programming, but rather that I could prove that I could learn and adapt.
"Have they tried try to invert a binary tree and see if it solves the problem?"
The only reason we accept it as the status quo is that people accept it and say "this is the way it is"
If you look at Goldman Sachs or Microsoft, BOTH are investing heavily in tuning their recruitment process to identify and hire neuro-atypical people.
It is a business strategy that is paying off.
Who's to day the kinder & gentler process they design couldn't be just as easily be applied to hiring in neuro-typicals.
https://www.microsoft.com/en-us/diversity/inside-microsoft/c...
https://fortune.com/2019/12/07/autism-aspergers-adhd-dyslexi...
It doesn't change because it hasn't changed. Not because it can't.
Ironically, the old-school hackers who made the word "hacker" famous, like the ones who built the UNIX ecosystem before Linux was even a thing, knew their CS fundamentals like the back of their hand. They'd have zero trouble with the coding aspect of these interviews.
Very few people on HN are hackers.
> "If you look at Goldman Sachs or Microsoft, BOTH are investing heavily in tuning their recruitment process to identify and hire neuro-atypical people"
That's just a publicity stunt. I'd bet money that few of the neuro-atypical they hire last long in those places.
Even if they did, that doesn't necessarily mean they can shuffle an array or flip a BST under pressure on a whiteboard
But I honestly can’t believe people are acting like reversing a binary tree is hard. This is like something you’d expect high school students with the most basic you data structures knowledge to be able to do.
Like I'll agree that there definition of hacker in 1983 https://en.m.wikipedia.org/wiki/WarGames is different from the one we generally buse today, but the world has changed a lot in that time.
Did white-hat exist in '83?
The definition of hacker has evolved from "one who uses computer tools to gain illicit access to protected computer systems" to "one who makes shit work and does cool stuff"
If you're going to imply that only the 1983 definition is the one anyone can use, I feel like you're going to be off on that island mostly alone.
Also, it's not like people know nothing. A good interview process learns both what the candidate does and does not know, how what they know could be useful, and how capable the candidate is in filling a knowledge gap if there actually is one between what they know and what is actually needed for the job. That is of course in addition to learning whether they're nice to be around or not.
The best screening I ever went through was for a job where I'd be working on a Spring Boot app with a React frontend. For that screening, I was asked to add a simple feature to an example app.
It was clearly toy code, so I knew they weren't trying to get free work out of me. It was also representative of the kinds of tasks I would be doing, which let me know that I would enjoy the job, and let them know I would be good at it. I was hired on the spot.
I've written algorithms to reverse b-trees, and I could figure it out again if I had to. But I don't have to, because the standard library is a thing, and that task tells a potential employer nothing about my skill set.
What they're actually testing for during the in-person interview is your ability to be a good worker bee. They're filtering out people like you who would question the point of doing task X. They want people who will do task X without question. They don't want workers who will ask "Why are we doing task X? Shouldn't we do task Y instead?" For most positions at these large companies, the person who questions the efficacy of task X is a different role -- the role that is instructing you to do task X.
With these trivia questions, they are in fact telling you as a prospective employee the kinds of tasks you will be doing. They are letting you know that you will be doing a lot of pointless work, you won't have any say in the work you will be doing, the work you will be doing will seem trivial to you, and you have to be okay with that. If you're not okay with that, it's not the job for you.
I am a father to a 2 year old, I have a mortgage and an existing full time job.
The time investment required to go through a bunch of algorithms that are almost exclusively used in passing coding interviews does not offer the same ROI as, for example, streamlining a process that you are currently facing on a day to day basis.
On top of that, something that I've learned recently about myself is that I have a tremendous fear of failing coding interviews.
You see there is an emotional component to the effort you put in to doing one of those things. You go through the work to get accepted into the interview process then you find yourself face to face with "one shot" to impress.
Maybe they've even flown you out to their location so you can go through this whole experience on site. At that point the optimistic among us might start thinking about things like what our lives would look like if we worked at "technological mecca" doing really cool shit for silicon valley dollars.
So you start allowing yourself to think about watching the ocean on a sunny day eating avacado toast while you watch your now bleach blonde son playing in the surf. Your wife is happy too. You have this beautiful life that you're providing for those that you love.
(in your fantasies you don't worry about the cascadia fault-line, the dystopian nature of US healthcare, or the fact that california seems to catch fire for a month every year nowadays)
ANYWAYS, you go in, you give it your all. Maybe you think you nailed it, or maybe you can clearly come up with 20 better solutions in the 20 seconds after you leave. Maybe you studied 50 concepts intensely, but missed the one they picked to ask you about. You didn't get the questions in advance or anything.
It doesn't matter though, you missed a semicolon on the whiteboard and your code doesn't compile when they type it in.
You get a terse reply from your original recruiter "not a good fit at this time" ... there's no insight into what you did wrong or where you could get better. That opens the company up to legal liability. Anything more than "thanks" risks exposure.
So you're left with days and weeks of effort for nothing. On top of that you have a real long flight home where you get to grieve the loss of that beautiful life you imagined.
Do you work in a place where you can tell your colleagues at work that you were interviewing? If not, you can't even talk to the people in your life who are most likely to understand the pain you're going through.
So you get to suffer alone.
So. What does it say about someone?
Absolutely nothing.
One thing I'd say is that essentially none of the people I know in other fields have a similar opportunity for a relatively small amount of dedicated study to pay off so well.
(...and, and, and...)
But you're SO right.
I expect that publicly committing to internet-strangers that I'm working on the course, producing materials for them &, having a scheduled weekly discussion around the topics will help with both learning the content AND keeping us all motivated.
Your initial comment was one of the things that helped me come to those conclusions, so genuinely thank you, kind internet stranger for sharing your wisdom.
I've actually started writing a self-study course on passing the FAANG, as a trained educator with a bachelor of Education and five years experience as a high school teacher, I think I can make a fair shake at designing a series of free learning materials on the subject.
I started inviting people along and have built up a list of about 20 people who've at least SAID they'll stop by to my live streams (once a week) to discuss the problems of the week.
It's going to be a structured course https://github.com/AlexChesser/faangterview-preparation-cour... I'll be releasing under MIT.
I don't know that the switch would have flipped in my head about the ROI of the FAANG interview.
As I said, it took a couple days to actually sink it but you have completely changed my mind. I now completely agree with you that they are worth doing for a number of reasons, many of which aren't financial at all.
I see them as equivalent to the Bar exam for Lawyers now. Would you hire a lawyer who said "I don't believe in the bar?" (I think we've seen how that played out with the Kraken lawsuit!)
Would you go to a hospital that said "We don't believe that doctors need to have done the USMLE"?
In both cases hell no!
You're right. This is not arbitrary or cruel, it's just a professional qualification. Sure there's some luck involved, there's the chance of personality conflict. There's all sorts of potential downsides... but there's also the upside.
Being better at my craft overall is the ultimate reward. If I'm a better developer overall, the money will follow regardless of whether I get in to a FAANG
1. DO NOT get emotionally involved or excited about an opportunity till the time you see an offer letter - those reeeallly sweet people that are so happy and courteous and smiley will switch in an instant, snap! throw you out faster than a used disposable cup and will not so much as give you the courtesy of a reply. They don't give flying f about you no matter how many hours they themselves invested in the process. See for them, this is paid work to talk to you, so they don't give a shit they do it for 10 hours and still drop you without even sending you an email. You are working for free during the interview process and have much more at stake in this process than the person you are talking to. You feel you're having a genuine human interaction with them? no. You think it went well because objectively it went really well? Don't worry you'll get a 2 line generic rejection email.
2. DO NOT ever gauge your self worth as a developer to passing or failing an interview - you will destroy your own morale. Take hints and learn to be better, no doubt, but the decisions people make about you sometimes don't have anything to do with you specifically so don't take it to heart too much.
There is no ultimate solution, it always depends on specific person you're talking to
Its seems to be an extremely competitive, eat or die type lifestyle that would require many more hours than a normal job. In essence its its own marriage of sorts, or at least in competition for non-work relationships/marriages.
And there's nothing wrong with the people that choose to do that. But it seems obvious even in the success stories.
I'm extremely competitive, however I also value family over all else. I would much rather spends dinners with my kids, and weekends with my family enjoying the fruits of my labor over having a line on my resume. I know that if i ever went that route, it would absolutely come at a cost, most likely my marriage at least, and probably some level of relationship with my children. Its frankly not worth it for me.
They have maternity leave, and they have resources so you don't have to be on call constantly as it is with smaller companies.
I could easily take some time if needed. My senior admin is taking a month of paternity here in a few weeks, as he did with his first. I have a first line guy that has been in and out for months for various reasons. It is a strain on others in small places but like any place if you document and cross train a bit it’s not terrible.frankly it’s a stated goal for my teams and something I have implemented across several roles and sectors in my career (even if I didn’t get to reap the benefits)
Colleagues of mine that went FAANG stated similar. Amazon notoriously has an unlimited time off policy. That buddy hasn’t made the family vacation tradition since he started. The first year he tried it he basically worked in the condo.
So from what I’ve seen, at least with Amazon, it’s de facto cutthroat and not so much a benefit.
Though I understand I’m possibly attributing that same experience, which may even be localized to his team, to a much broader set, based on the similarities of their culture/workplace.
Many of these places have showers and lounges and free food etc. and frankly I don’t want to work at a place that there’s a culture that encourages eating and sleeping there. Again I prefer to do those things at home or break from work during breaks.
OP perhaps doesn't have the constraints you have.
As an aside--
Do you really expect A. someone who has never met you and who has B. written a comment online before you arrived to reply... to know your life conditions or to tailor it to every possible human life outcome?
That is, because you've had children, does every comment online now need to ensure its content is in alignment with your perspective? That sounds like a failure to empathize, on your part.
For example, if I write something... do I need to make sure it's prepared in a way that 100% of people can relate to it, throughout time & space? Such as fathers of children, amputees, astronauts, etc?
It sounds like we're so diametrically opposed that it could get pretty heated. At least from my end. You do have a right to your opinion, but I don't want to play in the space where I could get emotionally dysregulated by some dude on the internet.
I'd rather not bring a flame war to the HN community.
I'm also not entirely sure that your argument is in good faith and i'm really not in the sort of place where I want to tease out the things you say which are hyperbole versus the things you really believe.
Do you really think that I said all interviews should be tailored to all people throughout all time and space? I can't believe that you really think that, so you can't be arguing in good faith.
Are you really saying that you think it is unreasonable that we expect accommodations be made "for amputees"? Like their role or position in society is somehow a burden on you, or god forbid employers?
Honestly, maybe you do. Maybe you're super into eugenics. I don't want to find out really. It is best that we go our separate ways.
I hope you have a very peaceful day.
1. It's going to be okay.
2. One day, you will recover from this comment and move on with your life. It will take time, but just take it day by day for now. Every day you're able to regulate your emotions after this comment is an achievement.
___________ Now for the comment:
0. Intro
Thanks amigo. I think you've taken it in the wrong direction, intentionally. (Given the current politics of hyperbolic outrage bait, I typically assume overly sensitive people prefer to [i.e. at least pretend to be] outraged over strawmen, because that's the current trend I see in western society.)
________________
1. The strawman
Your strawman implication: "You don't think accomodations should be made for amputees?!?!"
My actual quote: "For example, if I write something... do I need to make sure it's prepared for" ... <examples of various potential peoples' widely divergent qualities>
Good lord. Way to take things out of context, and then get outraged over your own strawman.
Look... I literally said "if I write something".
and you literally implied "you think it is unreasonable that we expect accommodations be made"
Where did I say anything about "accomodations"... my comment is essentially that you fail to see that no one can predict what stranger (and the qualities of their life) could possibly happen upon their comment.
Our interaction went something like this:
A. Random father arrives to see a comment wasn't tailored to his needs and claims the comment doesnt empathize with him
B. I tell the father that it is he who lacks empathy for expecting internet strangers who arrived in a discussion before he did, to somehow prospectively predict his life qualities/needs for empathy as a father, and tailor their comment specifically for him.
C. The father doesn't appreciate the exposure of his hypocrisy. Decides to paint a strawman involving employer accomodations for amputees, eugenics, and emotional dysregulation due to online commentary (while also assuming my gender, for bonus points of course)
________________
2. The strange & unrealistic
... Also, regarding: "the space where I could get emotionally dysregulated by some dude on the internet."
Uhh... yeah, First of all, you just assumed my gender... something tells me you're not very consistent in your political pretense.
That said-- welcome to Earth. It could get a little rough for ya... <sarcasm> Maybe you should avoid everything that could possible evoke stress, rather than adapting to inevitable stress</sarcasm>
___________________
3. Left field
Am I into eugenics? (Firstly... What part of left field did that come from?) We all are, whether we like it or not. Are you attracted to attractive people? Guess what-- you're a eugenicist.
All organisms are designed by evolution to seek the best quality genetics for their offspring, so again, welcome to Earth.
"Just like adults, newborn babies prefer to look at an attractive face, according to new research carried out at the University of Exeter."
Source: http://www.bbc.co.uk/devon/news_features/2004/baby_faces.sht...
Babies are eugenicists! The horror!!
In short, I am a specialist, and am hired accordingly.
And lots of bad stuff: the communication burden of wrangling huge numbers of people, bad decisions by leadership that you're helpless to impact, just the general difficulty of having one's values align perfectly with those of a big shareholder controlled faceless blob, figuring out what to work on that will be both satisfying and aligned with the right peoples' goals (that is, fun coding projects are often not impactful while thankless slogs are, at least for more senior folks), etc.; essentially, the politics are harder to navigate and feel satisfied with.
To highlight my first two positive points: the stability and compensation has allowed me to pay down all our debt, buy a house (recently refinanced to a 15 year mortgage), save up a year of expenses, allow my wife to go back to school, and pay for a couple kids to be in a lovely daycare. Most of that would have been much more difficult in my previous life in the startup world.
I'm very happy I got the job (when I was about your age), but I also think often about leaving it.
Hope that helps!
The compensation is also something that is not as clear to someone who had a career arc like me. I've always been able to make money to take care of myself and immediate family, but making consistent FAANG money changes the way you plan and help people. I've been able to help one family member go to school, another go to med school, multiple members to move closer, allowed my parents to retire early so they didn't have to work customer facing jobs during the pandemic, donated tens of thousands of dollars to local organizations, etc
If I was single I might've left and worked at startups or smaller companies, but I wouldn't now that I see how much impact I can have on those around me by just going to work and working hard.
As always, to me this sounds like a real waste of time. I'd rather be working on a real project (working for people who value work on real projects), not practicing for an interview.
But that's me.
I don't like that that's how it is, but that's what the game is, and most people are in no position to change the rules of the game.
I also acknowledge that despite all its flaws, the SWE interview landscape is still better than say, that for lawyers, where if you didn't graduate from a top law school some doors are immediately and permanently shut for you.
You can still get into a top tech company without an outstanding pedigree. The closest analogue to the lawyer situation is that if you have a top tech company on your resume, I'd say many doors are opened (or opened much more easily) to you than someone without such name brand companies on their resume.
There's the key. Their marketing has convinced millions of current and future devs that they are the best places to work for; that they are worth doing silly things for just to work there.
The problem is that many of their "wins" are from decades ago (or more). Today, for Google at least, you can't even choose what you'll be working on. You'll be tossed wherever they think they need you. Even the best new hires won't make it to the largest salaries (dominated by veterans) and won't get to spend their 20% time (if they even get it) on the next gmail.
The best advice I can offer, about two decades into my career, is to stop chasing the shiny marketing material. They'll burn you out and replace you without blinking.
Almost every non-family owned business now hires developers (and data scientists), some for very good salaries in places where you're not paying thousands of dollars monthly to be someone's roommate.
But it's all relative. At least from this side of the fence, I see FAANG (and other top tech companies) have less downsides and more upsides, relatively speaking, compared to your typical non-tech companies.
The point is emphasized by friends and ex-coworkers who've jumped ship to FAANG and other top tech companies after working at non-tech companies like where I am. All of them seem to love it.
I am not sure what you mean by this, but at least a couple of years ago you did have the opportunity to talk to several different teams and decide which one you're joining before signing the offer. Is that not the case anymore?
That hit hard! Thanks for putting that in words!
If, and only if, you're hired. Putting all of that time into studying for the interview is no guarantee of being hired.
Small companies cargo-culting FAANG interview processes on the other hand...
how else to you filter out the unlucky candidates :)
This seems like a "why go to college" type of response where there is some truth to the fact that so much of college is a waste (I've never used statistics or economics in jobs)... yet it's more than just college or CS questions.
I agree that a lot of story around interviewing is broken and that many of the questions don't relate to day to day jobs... like creating a binary tree or "how do you move a mountain" (IE: https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/03167784...) - but they do show that you know CS basics, know how to learn them or have basic problem solving skills.
As much as people bemoan CS interviews... currently? They are a necessary evil to certain segments of the job market. Can you get jobs without them? Sure... just like you can get jobs without degrees - but your resume will get round-filed for a large number of jobs without a degree and you'll not make it past initial filters without knowing "basic" CS trivia like binary trees.
Whether you're okay with a limited job pool or not is on you... I don't have a 4 year... but I have a 2 year with many years of experience and I'm okay with some of the limits until I eventually get a BA. I still make six figures and know I can find a new job if it comes to it - as I've done repeatedly with limits. I've never balanced a binary tree for a job interview but I have "failed" online tests because I wasn't "fast enough" on code tests. I'm still employable and successful.
Ok. So not soft skills then.
Instead, it is very specific skills. It is not soft skills.
https://www.wikijob.co.uk/content/interview-advice/competenc...
> Soft skills are the more intangible and non-technical abilities that are sought from candidates. For example:
* Communication * Teamwork * Problem-solving * Leadership * Responsibility
So "interviewing" isn't a soft skill as I've always though it to be but I didn't call CS basics a soft skill - I called interviewing one. I was thinking more "a skill not work related per-se" - ie interviewing - while the expected definition is more... personality and interpersonal skills.
I'd consider interviewing "personality and interpersonal" but I can adjust my terminology.
Interviewing is an important skill for most people and interviewing in the programming realm, unfortunately, relies on CS basics. Generally you don't get one without the other.
https://en.m.wikipedia.org/wiki/Theoretical_computer_science
Of course, if a company is just building the stereotypical basic CRUD app to serve a maximum of 10K users total and maybe 10 per minute at peak, this probably doesn’t matter much.
However, companies that pay top dollar expect candidates with top knowledge, and that’s fair IMO.
Knowing how to solve the ten or twenty most common CS interview questions is not an indicator of possessing "top knowledge". It's an indicator that someone studied the cheat sheet to big tech interviews, and that's all.
The coding problems are part of the interview, but they're not the entirety of the interview. You can't pass a FAANG interview by cramming CS questions, unless you're maybe applying for a new grad position where previous work experience isn't factored in very much.
Having a bunch of basic, generally useful algorithms in recent memory does save a lot of time on the "general solution" side when you're working in a new milieu. (That saved time then gets consumed trying to find, configure, and tune anything in an unfamiliar cloud environment, but that's another kettle of fish).
I can do both, perhaps even concurrently, but clocks are ticking and I’m worried I only have so many years before I’m pigeonholed where I am now.
The hard part is distilling the most commonly used and most helpful of these tools. But after doing so, I can now approach side projects where I got stuck on not having an efficient way to store and access data.
Knowing the start and limits of those algorithms gives me that confidence that what I build is close to as efficient as possible, and allows me then focus on pulling those efficient modules together.
As a self taught dev, its given me confidence in my expertise, and that pays off in job opportunity, self respect, confidence to mentor others, and actually completing hard projects that I could not complete before.
The FAANMG+ life probably isn't for everyone, but it has definite upsides, and I imagine that's why most people jump through the interview hoops. It's not because they generally value toy programs over real projects.
I test all developers by paying them to make the equivalent of a bird box. If it comes back relatively well designed, cool, I've got a developer. If they come back with three designs for different environments and species, I know I have an engineer.
As it stands, we have kids who have zero real world experience at the helm of corporations and the results are easy to see. They rarely produce anything of value for the general population. So rare we have to call them unicorns.
The subfield of software development where artistry outweighs cleverness and productivity is game design -- and not all game studios exist to do things that way, just particular boutiques centered around one storyteller's vision.
https://en.wikipedia.org/wiki/Stata_Center
Not sure if it's relevant? Google has hired Guido van Rossum and James Gosling. I'd imagine Google didn't ask them to "reverse a binary tree", whatever that means.
I.e., if you are Frank Gehry or Frida Kahlo, you don't need to go through hoops. (If you're reading this, you are probably not Frida Kahlo.)
If someone is aspiring to be her, you just helped crush that dream a little bit more. And for what?
It's just a fact that most people are not one of the very best in their field: 50% of people can't be in the top 1%. That's not to say people shouldn't try - after all, many of the "very best" tried very hard to get where they are.
It's probably not that the leetcode problems are ultra hard to solve (though they can be). It's also the combination of the artificial time constraint and the high pressure interview setting - which is a very different kind of pressure than you typically experience on the job.
https://youtu.be/r8RxkpUvxK0?t=534
The core money-making algorithms don't take many human bodies to develop. At Google, 500-600 researchers and core algo developers likely do most of the heavy lifting.
Otherwise, 90%+ of their developers are likely solving routine problems.
Although, most of them likely convince themselves that only the "chosen ones" among mankind can do what they do.
The reality is that most of software, even at the FAANGs, does not require the type of interview questions these teams enjoy asking.
I just couldn’t pull it out of my butt in the 30 mins I had. Sux. I’ll get there one of these days.
I find it extremely annoying to come up something while someone watches me as if I'm an idiot.
Interviews are also hard (as I frequently comment around here) because, once you've seen how the sausage gets made, you realize it's basically still a crap shoot which comes down to the loop you get. If you get an unlucky roll and end up with the personality type which views interviews as a chance to show how much more clever they are than everyone, then you've already failed. Their ego is tied to their "high bar" and impossible question set, and you're just fodder for them to show off that "high personal bar" during the de-brief.
[0] https://youtu.be/rr7IRYLqleg
I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.
I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.
or trying to glean proprietary information out of others?
It's a struggle between fitting the interview to real-world situations vs making it seem like the candidate is doing work for the company.
I feel like a good situation might be actual problems previously encountered with the technology being assessed during the interview that would've required you to have collaborated with someone who is also experienced in that technology to help you solve them.
Maybe the best way to do this is when the situation is proposed to the candidate, make it clear that the answer is already known and put it in an envelope (physical or digital), which will be referred to when it's solved or the candidate hits a dead-end.
Do you have a source for this? I can't help but think about the person in this clip: https://www.youtube.com/watch?v=LlCEmPF4-V0. You think you can learn much about her from that interaction?
I acknowledge there are some situations where you might pass the interview even without arriving at the optimal solution, but those are probably the exceptions.
I've interviewed people who didn't know the answer to some of these tech questions, and honestly, I was more impressed by them calming saying "I'm not sure on this one, I would probably need to go look it up".
Why worst? If you're not given an offer, nothing changes. You've spent somewhere between 45 minutes and a day, got some interview practice and all is basically status quo. But, if you're given an offer, you are now faced with having to weigh the pros and cons of accepting it.
And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).
The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?
Getting really specific about what exactly being "excellent" means to a team is really critical.
Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).
Though I think my expectation is that they'll get annoyed and stop the "interview".
I also don't really ask "trick" questions (I try to select questions based on what the CV indicates would be a strong area for the specific candidate), the closest I get to that is probably when it comes to service monitoring (where the exact final answer is less interesting than the process of getting there).
My reply was only intended for "trick" questions that have absolutely no relevance for the day to day job of 99% of Software Engineers. And that's exactly because those trick questions tend to be more about the "exact final answer" than about the process, so my point was about figuring out if the interviewer actually has a grasp of those sort of problems in general or if they memorised a good solution and are milking that for all it's worth.
And I do know that almost any interviewer would reject me based on that, but I think it's worth letting them feel the burn they try to inflict themselves.
My absolute favorite interview of the group, a guy who ended up getting hired elsewhere, was the most calm and professional developer I'd ever been around. Sitting in the room, I felt like he was interviewing us rather than the other way around. It was just in the way that he carried himself, answered questions.
And then the guy on our team started asking questions. The gentleman we were interviewing, rather than answer, kept calmly asking more questions of him instead.
- Can you describe the situation where this would be used?
No
- Have you ever run into an issue like this before that could be an example?
No
- How do I know that by solving this problem we would be addressing the business or customer problem?
We don't
- Then shouldn't I be solving questions related to the work?
...
I loved that guy. Wish we could have hired him because I really wanted to work with him.
I stopped an interview once. I told the guy I didn't think I'd be a good fit for the organization, and maybe we should save ourselves some time.
I've done this a few times, each time from a startup that reached out to me asking me if I'd come in to talk to them, and then would throw me into their coding challenges immediately. Like whoa hold on there, I don't even know what you do, why are you asking me to do a coding challenge before we've even figured out if there is a fit for me technically and I figure out what it is you're trying to solve.
I've rarely used unprofessional language in job application emails, but on that occasion I pretty much told them to take their no-name little company and shove it.
[0] https://www.asktheheadhunter.com/15129/before-you-risk-your-...
Many interviewers don't do this because it's often difficult to distill the most interesting problems down to something that would fit within the time allotted for the interview, and also there are candidates who prefer abstract textbook-style problems.
I often wonder why this is legal, especially given the legal concept of disparate impact. It's basically just a disguised test of some combo of IQ + free time + willingness to grind dubiously useful information
Pretty much any white collar job interview is an intellectual joust at best, and a mild hazing ritual at worst.
We actually have it good: you at least know what the broad contours of what we'll be subjected to.
Because any software person will tell you these tests are extremely detached from the requirements of the job.
It seems like it would be an open and shut case if not for the army of lawyers employed by the likes of Google.
But it’s still more diverse in contrast to the companies I’ve worked at (non-tech old school companies in finance, etc), where the tech employees tend to fall into a much narrower stereotype.
Of course the USA is ever more extreme and crazy when it comes to identity politics, so ago knows if the justice system is still reasonable in this regard. But I'd really enjoy watching people argue in front of a judge that working with tree structures is extremely irrelevant to programming.
“Not yet challenged” and “legal” aren’t exactly the same thing. Straight up IQ tests are probably more defensoble than leetcode for lots of positions for which leetcode interviews are used. But people have heard the popular misrepresentation of Duke Energy (“it’s illegal to use IQ tests”) more than they’ve heard the actual disparate impact rule, and that seems to be true on both sides of thr interview table.
Demoralizing as all hell. Thankfully I had multiple mocks with FB engineers who told me I did great so I know it really was just bad luck that the real phone screen was a dud.
They didn't even need to look at word of mouth impact to see a material hit on their customer retention, in a sector where churn is costly. They went on a crusade to improve, and now find candidates for jobs are net promoters, and their customer acquisition cost via candidates is lower than normal advertising(!)
I think some of the big tech companies simply don't care about their reputation at either micro or macro level, and nobody wants to call out that kind of toxic behaviour as they're all "part of the club".
At an employer prior to that, I saw first hand how companies were able to get negative but true reviews taken down almost as soon as they were posted. There was high turnover at that place and a lot of people were truthful in their reviews of the company. The Glassdoor rating was far higher than they deserved until they went under.
Im short, I’m sure you think you’ve got a great work environment, but I’ve been burned by bullshit Glassdoor reviews and I doubt I’m the only one.
I generally try to help everyone as much as I can during interviews, because honestly this is taking time away from my other work and I'd nothing better than to hire you, but sometimes it's just to much.
(I’m half hoping that after typing this out someone will reply with some data structure I’m unaware of that would allow you to uniquely map the reference of an object to an arbitrary value.)
I've had several interviews where everything seemed to go well, but one (out of say, 4/5) interviewer just seemed to be hostile from the moment they walk into the room.
FB only asks leetcode questions tagged with 'Facebook'. 100%. I know ppl who memorized these questions and got in.
Learning new frameworks and coding standards, surviving code review, dealing with difficult team members, dealing with ever-moving business goals, and just about every other aspect of work, including the coding, has been harder.
I admit that I have never had to invert a link list as part of my work (Graph traversals I definitely had to do, actually). But I have had to submit to arbitrary technical demands and to learn and use technical materials I did not enjoy or agree with architecturally in order to successfully complete projects. So in that, studying and practicing to pass the technical screen is similar to the job. Employers want someone who is able to (sometimes!) bite their tongue and just do the work assigned.
Actually, I remember one IT-style interview 12-ish years ago with a certain FAANG that shall go nameless that had this sorta narcissistic/sorta dumb hiring manager, whose profile picture was a shirtless muscles pool pose, believed that a technology I inherited and was forced to use was an interview deal-breaker. And, at the time, I was at an IT department at Big Name university down the street where there were much more complicated and interesting things going on, like remotely uninfecting and patching worm-laden systems and putting together a fully-redundant/HA VMware cluster that had an FC SAN and blade servers (the thing back then).
I'd guess 99% of engineers never have to do CS trivia as part of their day-to-day job.
FWIW, most FAANG employees seem to admit that if they had to redo their interview, odds are they're more likely to fail than pass. Goes to show how much luck is involved in the process.
I think it's gotten harder too. Maybe in the past it really was about trying to see how the candidate thinks and solve problems. But now it seems like all all of that is secondary to getting the optimal solution. Two of my friends in Google who got in ~10 years ago say that it's definitely gotten harder from what they see.
I believe they mean e.g. "tell me what happens when you type https://example.com" in a browser.
You can go deep into tcp/ip, dns, how ssl encryption works, how urls on a server get mapped to specific ports, load balancing/round-robin etc.
That could be trivially fixed tomorrow, either by universities or (better) by an accredited certification body.
I mean, I'm sure there weren't bar exams for lawyers and professionals either, at some point in history. What prevents us from creating one for sw developers? As long as it didn't require additional attainments just to sit for it (i.e. you should not need a university degree), it would make the whole process more efficient for literally thousands of companies.
In software it's not like that. There are very few laws on the book about how to write software, so there's no single authority that defines the right answer or the scope of reasonable questions. It's far more open. Even just picking a set of programming concepts would immediately cause controversy. Like, should monads and type-classes be a part of the professional qualifications? Most programmer would say no, because Haskell isn't widely used in industry. But CS degrees do sometimes test people on that sort of thing!
(Also, in both cases, the government hires members of the profession to define the standards.)
I'm convinced we could have a bar exam for software engineering, but I'm not at all convinced that we should. It would make my life easier personally, but it would keep a bunch of people who followed less traditional paths out of the industry and I think that would be bad.
Is that an equal burden for every candidate, in every life circumstance? Or does it privilege certain groups over others? The ROI isn't the point. Requiring preparation unrelated to the job is highly suspect, regardless of the return.
...check yo math?
Definitely. I’ll add that it doesn’t take as much time and effort as commonly portrayed online, especially if you have many years of development experience already.
Keep in mind that many of the online FAANG cram-style study guides and anecdotes about grinding LeetCode are largely targeted at college grads who don’t have many years of experience, and who also likely have a surplus of free time.
For developers with years of actual programming experience, it’s not as difficult to study interview problems as it sounds. Even more so if you spread your practice over a long period of time. Doing one problem per weekday over the course of a year will get you quite far in LeetCode without much time investment.
I grab a random LeetCode problem on my lunch break if I’m eating alone (aka every day during COVID). I pick a different language that I’m familiar with to rotate my skills. I’m not even interviewing, but it’s actually kind of fun to do the harder problems and play with all of the little optimizations. And I get to keep my skills fresh in programming languages I’m not currently using in any projects.
The problem with this approach is that you won't be able to remember the details of problems older than X months ago, at least not to the level that will reliably help when in a stressful whiteboarding interview.
There might be entertainment/knowledge benefits, but it doesn't replace cramming for a known upcoming interview-event.
I approach it more as learning different techniques to solve different problems, rather than learning how to identify the trick and recall the solution to specific cues.
Trying to memorize solutions isn't really effective for interview problems, in my experience, unless you really can dedicate time to cramming as many solutions as possible right before an interview and hoping that they ask you one you've seen before.
I did one of these interviews on short enough notice no review was possible. The process was a little jarring but on these type questions I could just talk through the problem space and come up with something reasonable and explain it; although I doubt I answered anything precisely as expected in the half dozen interviews I had. Apparently it went well.
To be fair, I wasn't a fresh college grad, and I had been recently working as a full time researcher. But they sent me through the SE interview process and none of the specific questions were close to anything I had thought about in years.
No, you absolutely do need to cram to get through the interviews. In fact the questions on leetcode are designed for this very purpose. Every question has one common theme. And one 'catch' that you absolutely need to know to solve them.
If you haven't looked at a question in X months chances are you will struggle to solve it quickly even if you have solved it before.
If you are out of a job, just buy leetcode premium. Keep doing it for 15 hours a day. Then start applying for interviews.
Its the dumbest way to hire and get hired.
Not even least surprised people can't hire a person to get a darn thing done.
I just described a situation where that was not true, so I don't really know what you are responding to. If you are generally on top of problem solving, you don't need to "cram".
This generalizes - "cramming" has origins for formal courses, as a technique to try and pass an exam when you haven't actually done the work and don't understand the subject. It's a last-minute approach; might get you a pass but is hardly ideal.
I think most people cannot ever understand these topics well, and from their perspective, it'll always be about cramming. -- It doesn't fit in their world view that others can solve these problems by thinking, not cramming, when they cannot?
Whilst to you, it's more about thinking, coming up with new things, but trying to learn it all by heart would seem a bit weird? -- And then maybe in a sense you're talking past each other?
Congrats on getting a good payoff on your work, and thanks for sharing the info about your process.
I'm a self-taught developer, 34. My first programming job was only at about age 30.
About 2 years later, I was consulting for Amazon, as a full stack engineer building a digital marketing project, which was pretty cool-- plus great for the resume.
After that, Amazon contacted me for an interview with them, which I failed (lack of data structures & algorithm knowledge/experience).
I still have the hopes of working directly for a FAANG company. So, just wanted to say thanks.
Currently I am unemployed, but I am about to start studying DS&A again & building some small projects. Fortunately, given the industry & skillset, I have recruiters contacting me frequently, which is a positive, uplifting signal.
For me this is the main problem with companies that hire like FANG do. It is fully expected you have to study. Like I have to study to basically do the job I am currently doing but at FANG? Then there are the fact so many people say the hardest thing about Google is the interview. And for me that is kinda pointless then, like if I've just done the most challenging thing, why would I want to hang around?
This is how bad interviewers always justify asking nonsensical questions.
It's like that old joke:
An interviewer picks up a stack of 50 resumes, takes a glance at them and drops the bottom half into a wastebasket. A coworker asks:
'Why did you discard those candidates?'
The interviewer replies:
'Because I hate losers.'
If you have a big knowledge gap in something that's
- easy
- freely available
- relevent to your job
then that's pretty much entirely your fault and it has nothing to do with your educational background.
> - relevent to your job
isn't necessarily met here.
I'm also self-taught. I couldn't reverse a binary tree in a tech interview (without looking up how to do it first) because it's never been relevant to my job. I could, however, stand up an API and deploy it to AWS in a similar period of time, because it is relevant to my job.
> - easy
> - freely available
> - relevent to your job
> then that's pretty much entirely your fault and it has nothing to do with your educational background.
Sure. But reversing a binary tree isn't relevant to most modern software engineers. And when it does become relevant then, like you said, it's easy to learn (on the job).
> It's not even anything that advanced or difficult either.
No but it is something that gets "memorized" for a test (and therefore immediately forgotten afterward).
Although I've never asked or been asked it in interview context, reversing a binary tree specifically is probably just checking you understand how to write recursive functions. Binary, because variable number of child nodes would make the code longer and more complex for no good reason. Reverse, because that's the simplest operation you can do at each node.
People in this thread are acting like tree processing is as exotic as theorem proving, and could never have anything imaginable to do with daily work, but every web page is literally a tree!
And it's not like you can't find out of the applicant knows recursion and what a tree is without bringing in memorization, there's just some weird obsession with a very specific type of problem which happens to often involve memorization
I’ve never been asked this question, so I haven’t “memorized” it as you say, but if you want to flip the order of all the nodes in a binary tree, you’ll need to at least reverse the left and right subtrees at some point. The understanding recursion part is knowing that reversing the subtrees is the same operation as reversing the main tree. In that way, it’s similar to the recursive solution to the Tower of Hanoi.
What do data scientists do?
"...I use an ORM, rarely do I need to write a query by hand...."
"I had been working as a consultant and/or starting companies for almost 10 years and found the b2b sales process is literally nothing like the hiring process for SV companies. In one we talked about project goals and solutions, in the other we talked about hypothetical word problems that I have no doubt are popular in CS programs."
And yet, one of the two failed while the other has job openings.
The title is very broad and it could mean a bunch of different things at different companies. But it almost always involves a solid understanding of statistics, hence the probability questions in the interviews.
So from the article, it seemed that the interviews were quite relevant to the jobs advertised, and that the applicant truly was not a good fit for them.
> about 20 of these in-person interviews going poorly ... it seemed like everyone I interviewed with was a caricature of narcissism and delusions of grandeur.
instead of reflecting over if maybe maths is actually on topic for a data science job.
It's also odd, I think, that the companies didn't ask some probability questions in a phone screen, saving time for him and themselves.
Like "easy", who defines that? Is it easy because it just takes time? By that logic most things in tech are easy right?
In reality it's time spent on stuff often not relevant to a job at all, it's being used as an artificial filter.
Remember this isn't just about knowing, it's about being able to regurgitate it from memory on demand in a timed high pressure test
> has nothing to do with your educational background
Yes it does? People learn this stuff literally because of their educational background.
You can do some pretty amazing things in tech never memorizing half the things you'd need to for Leetcode.
--
I'm self-taught, and I know my data structures and algorithms, but I don't know algorithms and their nuances by heart so I don't Leetcode nearly as well as my YOE implies.
I see it as a two way street though, I don't want to work at a place that will turn someone down for not running a hamster wheel...
The venn diagram of "positions that need you to know this without any time to look them up" and "positions that ask you to know them without looking them up during the interview" is practically two circles touching.
I have no problem for jobs that actually need that mind you, but so many jobs couldn't tell you where the practical application of their Leetcode questions would ever come up on the job if their lives depended on it
It's never been a blocker for me, my TC is easily as high as what it'd be at Google or FB and I work on cool things.
Surprise, I never needed to manually balance a binary tree for work, and mostly people don't. So I don't see how "it's easy and free to (re)learn" says anything when hardly any software developer who didn't just graduate a year ago remembers this stuff by heart.
Also I'd like to think I know enough about most data structures to recognize where they make sense and to get into implementing using them quickly. But quickly doesn't mean "all of them" or "during the interview" or even "preparing everything in the utmost detail as they would ask without reference material". Teachers also don't explain complicated stuff without preparation, unless it's the material they do every year for many years.
Lots of missed income there.
I also interviewed and received job offers after burning out at startups, i listened to the advice to spend 6 weeks on hacker rank and top coder. I passed all my technical interviews. I was also coding on two personal open source projects, but practical cussing and interview coding are 90 pct different as you say.
I don't know if i will succeed at having impact at a large company. Tell you in 6 months. But i am iterating fast and following advice of the people around me.
You didn't mention the effect of being unemployable because your standards are going up. This is an occupational hazard of having more experience. Sorry about that, there are things you can't unsee . It happens to everyone, and an underdiscussed reason there are more young coders. Good luck.
Freudian slip?
I laid it out to him, that brogrammers are collective tards that cant think on their own, BUT they are good at things like code interviews. I was hired as director. The 2 people who said no cause I said no to their brogramming crap. I personally let go in 4 weeks. 2 years later, things were fixed, I got a fat check, and moved on.
Lesson? Uncle Bob and his elk are creating problems that you can be paid to solve. However Uncle bob and crew are great at brainwashing.
Graphs: HTML is a tree, it’s easier to think about performance. Also, I once made a simple DSL like HTML and had to implement quite a few graphs traversal algo’s.
Heap overflows: I did one on htb. Being able to algorithmically think about pointers being overwritten and memory layout feels a lot like interviewing.
Trading: one algo trader I made needed speed. I had to go much further than most things I see on Leetcode.
In general: algorithms is the ability to think step by step in your mind without a debugger. That skill is quite important when the going gets tough.
Note: I am not for this interview style. AllI am saying is, it is not without merit. Or would you rather do a 40h take home assignment? (Same thing, not without merit but 40h?)
- partial differential equations
- reverse a binary tree
- (sadly) made quite so many long-term friends
I've never worked in a large company, never had a salary that is even close to US engineer level, and yet I regularly write code that traverses complex graph structures (often with recursive CTEs in SQL), just because that's how a lot of real-life data is structured. I spent this weekend debugging this traversal, in fact. And that's only the 'trees and graphs' example from the top of my head, as I've found myself constantly using all the different CS stuff throughout my career.
This is not an attempt to attack anyone or an attempt to appear superior. If anything, I'm constantly reminded by how stupid and uneducated I am when I'm reading HN comments. I'm just trying to understand: are you guys really spending your whole days changing button colours?
I’d like to do other things, but this is the only sort of thing I think I’ve ever gotten an interview for.
> I'm just trying to understand: are you guys really spending your whole days changing button colours?
Not quite like that, but it isn’t uncommon for me to spend time making minor changes because the business area helping with requirements can’t remember what they wanted one day to the next. I wouldn’t like if I said there are many days I spend mostly doing nothing, just waiting for some process or for someone’s calendar to free up before anything can continue. This has been common at all jobs I’ve had except one, where I was a contractor hired to do an extremely specific task for a very small company.
I’ve started working in other things in my (abundant) spare time, hoping they’ll help me get somewhere, but I’ll see.
Being an entrepreneur is a high risk / high reward venture though and we’re not entitled to an easy, well paid salary if we fail.
Great read though and glad the author found their groove eventually. A salaried position doesn’t have to be the default fall back.
To be fair, practically all people in their 20's go through a pachinko machine of decisions leading God-knows-where.
It is hard to take folks for their resume or at their word alone. The inane questions just provide a common framework for evaluation. It is definitely not indicative of actual work to be done. It is totally an indicator for someone willing to pick up a new skill and learn in a short window. We in fact get the other kind of candidates as well: who can solve these problems very well but can’t do good work. So the interviews at snap at least try to go for a combination of informational and design/technical questions.
Ignore the feedback - we are not really allowed to give exact feedback because of liability issues :/. So it is going to be some super high level things you can’t sue us for.
Leil Lowndes writes books on improving as a communicator, not about tech, but one of her pieces of advice for interviews is to interview at places you don't want to work first, and treat it as practice. In her case the recommendation is meant for people who struggle with being comfortable presenting themselves and talking, but it applies just as well in other contexts.
E.g. find some jobs you're clearly qualified for where you're likely to get an interview relatively easily. Drop your standards - your goal is not to get hired. See what questions you're asked. Use the experience to improve. Amp up the "difficulty" if you get offers.
See how the questions differ, and how the process differs if you try for more challenging positions.
Then go for the job you want.
Figuring out how to pass the interviews in "low risk" situations (because you don't really want the job) is both good practice, good calibration of expectations of what kind of job you can get, and a good way to relax more when you apply for the dream job.
Skimming through the article, this seems to be an exaggeration. He may be unemployable at some companies; maybe even at most companies that advertise on HN; but I am sure there are companies that don't ask for inversions of binary trees, theory of probability, etc. during interviews. They may not pay as much as the ones that do; but surely he is far from unemployable.
At the same time , they'll often take a chance on someone who on paper isn't qualified. That's how I got into this industry.
Has anyone been able to hire a general businesses person to manage the day to day boring parts. I'd like to keep working full time while paying someone to run my startup
Which if you remember being in college, is a decent amount
A lot of students start internship where I work and quite often I am their mentor officially or not so. Recently their dean called me and offered to lecture at the university. I am an engineer with 20 years of experience, I can teach a lot of useful practical things, but when I looked into syllabus it was a list of mostly useless theoretical knowledge I am no expert in. Honestly, it was not a pleasant moment, I felt like a successful plumber.
My guess is that what students really want is a lecture in how to get a job, not how to be useful in a job. OJT and fakeittillyoumakeit would then become the order of the day.
I wonder sometimes why I don't hear more about apprenticeships by the nation-state sized companies. Bring in likely 17 year olds and train them in whatever specialized way you like.
Perhaps some of all this interview nonsense could be avoided by commonly recognized software equivalents of a PE cert, but I suppose you'd simply slide into subtle quizzes about programming languages and the like.