Hacker News new | past | comments | ask | show | jobs | submit | batshit_beaver's comments login

As someone currently in the process of trying to move from a cushy, interesting startup job to a soulless FAANG for that compensation multiple, the ONLY reason I'm doing it is because I have a young kid now. I wish there was another way, but it is genuinely impossible to provide a comfortable level of family life on a startup salary, unless your partner is also in tech and is ok with not being a stay at home parent.


> I wish there was another way, but it is genuinely impossible to provide a comfortable level of family life

It's all a matter of perspective, isn't it? It's basically the top 1% speaking. And you can't tell me that the other 99% have miserable lives.

> unless your partner is also in tech and is ok with not being a stay at home parent.

Stay at home parent is a choice, and a pretty expensive one. One does not have to choose that and can still live a comfortable life. Many women (and let's face it, we're unlikely discussing the man staying at home for the next 7-15 years, eh?) even prefer not to interrupt and/or basically end their careers because of parenthood.

Americans often look to Europe, claiming that these things are so much easier there, which might be true, but at least as much is it a matter of personal choice as well.


Can confirm that the 99% have very comfortable family lives, lower stress jobs, plenty family time... (based on having many lower income friends) Bottom n% is a different story, but a FANG salary is not a necessity unless your lifestyle choices and personal expectations make it so.


I'm guessing those lower income folks either don't live in HCOL locations or were fortunate enough to buy their homes before the pandemic. My family is all in HCOL, so with a young kid it's not really feasible to move away (or to go back in time and get a better deal on the house).

Yes, to some extent the asinine expenses of people like me are a result of various choices we made, but that's assuming those choices had any really realistic alternative at the time. And now I'm stuck.


I did the same for the same reason , but I moved from a soulless FAANG to a high frequency trading company. This is another integer multiple.

To my pleasant surprise, the HFT is more rewarding (not just in comp) than the FAANG was. At least for now, or that's what I keep telling myself.


There are other companies, too. I work at, statistically speaking, Your Phone Company, and they don't pay FAANG money but they certainly pay a lot better than I was doing at startups.

Caveat: I don't live in the Bay Area, though the Boston area isn't exactly cheap.


I hope it’s a great experience there, have friends in the risk/cyber areas and have heard nothing but good things.


Thanks! It's an interesting place, and I think the technical quality depends pretty heavily on what org you're in. But the quality-of-life is very high and I'm mostly enjoying myself.


In my experience it's virtually impossible to reach the same level of familiarity with a codebase as the people who originally wrote it. This is not only due to years of accumulated complexity and debt, but also the fact that code simply does not capture business intent completely, let alone correctly or with full context.

This is why projects tend to be put on maintenance mode or rewritten (piecemeal or from scratch) once their original owners are gone. This can be, but isn't always, expensive for the business' owners.


Surely it has positive consequences too?


Is it that they're bad, or is it that your tests stumble upon a small area in the huge realm of software engineering that those particular engineers struggled with on those particular days? Or, if you're asking these people the same group of questions and seeing a 90% failure rate, maybe your chosen questions have little overlap with common engineering tasks?

Why is it so hard to believe that even after 15 years of producing useful, quality software someone might still struggle with a random problem in an interview setting? What level of arrogance leads to this holier than thou thinking?


Citation needed.

We don't even know what defines a "good engineer" come yearly performance review time, but claiming that it's the knowledge of graphs and recursion seems rather suspect.

Inb4 "obviously there's so much more to being a great engineer," but then why are we not testing for that iceberg, instead just scratching the surface of "CS fundamentals?" And in fact, how many times does a great engineer need to prove that they understand fundamentals? Forcing engineers to go through that every time they want to switch jobs is inefficient and, frankly, disrespectful.


    > X and Y are fundamental CS concepts
In 2024, the list of X and Y are fucking HUGE. I would like to see OP sweat in an interview on some "fundamental CS concepts" they have not used in the last 5-10 years. The lack of humility in some of these comment is simply stunning.

I worked with a guy who was absolutely a first class engineer. Very well paid; I guess about 300K USD. He had almost no experience in C++ for more than 20 years (mostly Java and C# for last 10 years). During a discussion, I mentioned that the original C++ std::map used a red-black tree. He was well-surprised that lookup was not O(1); instead: O(log2(n)). (My point: He knows about red-black trees, but was surprised the original C++ foundation library did not include a hash map with O(1) lookup!) Really: He would have failed an interview from this person based upon "fundamental CS concepts". Any software engineer, no matter how smart or experienced, has some weak spots in their fundamentals.


This is a strawman. Implementation details of a specific language library are not "fundamental CS concepts", unlike the specific topics I was talking about.

If you're hiring a C++ expert, then yes, not knowing the difference between map and unordered_map would likely be a disqualifying condition. We are not talking about C++ expert interview though.


> why are we not testing for that iceberg, instead just scratching the surface

Typical interview loop includes more than 1 question.

> how many times does a great engineer need to prove that they understand fundamentals?

This is a logical fallacy. The interviewer doesn't know if the interviewee is a great engineer or not, that's the whole point of doing an interview in the first place.


    > Typical interview loop includes more than 1 question.
In my interview experiences, programming problems are "fail fast". If you fail one, you fail the whole interview. There is no "round 2".


I think the main issue is that people would much rather spend their free time learning or building something useful, rather than the "prep game." A more skilled, knowledgeable workforce would benefit the corporate overlords as well, but we can't have that due to the broken interview system.


You change job every few years, spend majority of walking hours in job and your financials directly depends on job. Why would you not spend time on prep.

I have no sympathy for people posting "jobless for months and reject coding test interview" in one sentence.


Working for them seems far less pleasant.


Google used to ask people to write code in a Google doc. No tools allowed.

Facebook to this day disables intellisense in their coderpad interviews.

It's fucked up.


It'd be like interviewing a chef and you give them twigs and a flint rock to roll their own stove.

I don't get what these tests are trying to show.

Breadth? Depth? There's other ways. Give some complicated code that touches a bunch of things and have them work with that.


From my interview at facebook some four years ago, I am inclined to believe they disable intelisense so the candidates do not get tangled up in the minutiae of language syntax, function arguments, etc. and instead focus on the algorithm they are trying to write.


Except you get dinged on your performance if your code doesn't run once the interviewer has a chance to test it after the interview. And getting dinged generally means rejection in today's economy.


I passed that round and I’m 100% sure the code I wrote was not runnable as it was written.


I actually got a google doc interview where they asked me to code up a hyperparamater optimizer from scratch. I couldn’t believe that they asked me to code in a google doc. I should have stopped the interview right there.


It's not "decent problem solving" that these folks demonstrate though, it's the ability to grasp and regurgitate common DSA patterns that show up in most leetcode style interviews. Does this ability make these people highly desirable hires? Should you hire such people over engineers with more real world knowledge, but who don't want to spend the time learning or practicing leetcode?


Congratulations, you've memorized leetcode patterns. Proves nothing beyond that (except that you've also had the time recently to practice leetcode).


I have never practiced leetcode puzzles or memorised solutions to them. I don't understand why you jumped to this conclusion.


Probably because you said you "can solve the majority of leetcode hard problems in under an hour". That could easily give the impression that you have practiced them. If you haven't practiced them, then how do you know you can solve them?


Sample of 5-6 I tried for fun. Along with a handful of similar puzzles from other places.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: