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

Just joined a new team as a senior dev last fall and went through this. I simply worked my ass off the first couple of months and asked a lot of questions and banged out some very high quality initial commits to make a strong first impression. Have a zen mind/open mind, things will be different and you may not care for some of the approaches taken. Play the long game and gradually make suggestions and changes as you get to know the landscape. My initial feedback from management was very positive, so this approach worked for me.


This was a wonderful book, it really helped lift the veil on how more complicated things were written in code for me. Also, I remember I was at the mall with my uncle and he offered to buy me a gift. I went straight to the bookstore and picked out this book. He was surprised that I picked out a book on programming, and rewarded me with some extra cash after purchasing the book.


Fingers crossed that you tackle a Quake Black Book at some point.


Back in ~2015 Philip Buuck did a video series called Handmade Quake where he analyzed every file while trying to rewrite Quake 1 from scratch. This of course generated buzz and soon enough he got hired by Epic, as a result everything got scrubbed and deleted, his videos, his blog, all of it gone.



This is an excellent book, and real breaks down the math into bite-sized chunks that can be easily consumed.


Folks might also enjoy the Nantucket PC game on steam: https://store.steampowered.com/app/621220/Nantucket/


he was too inept to start war


I can attest to many mortgage payments successfully made thanks to Java.


Can you imagine having to learn all this just to make a connection to a database, process some data, and then persist it somewhere?


The popular sentiment on computer science knowledge has done a complete 180 in the past several years.

Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize when an O(n^2) solution was going to work on their local n=10 test set but bring down the main website.

Now that knowledge of CS fundamentals has become valued in interviews, the pendulum has swung the opposite way. We have more free resources than ever before to practice and study CS fundamentals, algorithmic challenges, and even practice your interview skills. It's never been easier for a junior SWE to sit down, put in the effort, and work their way into a $200-300K job with sufficient dedication. Yet people never tire of complaining about Leetcode or having to understand CS fundamentals online.

Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.


> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.

Weird. Ability to leetcode doesn't mean you know what is happening in e.g. an RDBMS. We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website. Needless to say it didn't go over well. Ability to leetcode doesn't give you any knowledge that doing so might be a bad idea.


You can learn how to use some function to call into a database and study its behaviour, if you can grind leetcode and solve problems.

It's a good enough filter, the alternative is either way more costly or way worse(if you have seen "interviewing" which are just thinly veiled nepotism).


> We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website.

You didn't have anyone reviewing their code and mentoring them? No one reviewed their design before it went into production? If no, why not? If yes, why wasn't the problem caught then?


> We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website.

This says more about the ability of the other employees at the company than it does about the new junior employee.


Doesn't leetcode also have sql questions?


> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production.

It's all anecdotal evidence. I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account. Producing great production code is more about experience and knowledge of the domain than knowing how to bang out algorithms.


> I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account.

That's not the point, though. No one said that Leetcode is mandatory for being a good programmer.

The point is that Leetcode, however imperfect, is still a usable signal for programming ability.

Those excellent programmers you know would likely not have much difficulty with Leetcode style problems if they were to try them. That's the point.


> I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend

I don't see what makes you think a person who can ace Leetcode should be able to write an "efficient website backend". These are different sets of skills. You can ace Leetcode and not even know what a backend is.

> knowledge of CS fundamentals

Leetcode is not CS fundamentals. It's a small part of CS fundamentals. Besides, candidates aren't asked to show they know the CS fundamentals. They are asked to show that they spent more time practicing leetcode than the other guys.


> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production.

I competed with this guy in competitive programming competitions and while he was fantastic at it, he wrote the worst code I've ever seen.

I've also worked with many people who've never even heard of Leetcode or similar and they were fantastic developers.

In my opinion there's no correlation here and it's purely a distraction.


Leetcode is not a good indicator of quality code by any means. It's basically a filter. If one can't solve these programming questions, there is a higher chance that they are not good at programming compared to one who can.


But it might come handy when implementing - route optimization problems - Building database query optimization engine

You can argue that not everyone is implementing these from scratch every day. But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.


> But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.

Having the skills and ability to build these systems doesn't mean you can regurgitate all the algorithms required to build them on a whiteboard in 30-60 minutes. It means you have to ability to search for algorithms and apply them to your problem at hand over the course of several days, weeks, or even months.

Do you really think anyone building these systems spent only 60 minutes both deciding upon, and coding ANY of their algorithms and called it a day because they obviously chose the best one?


Isn't it what computer science is all about. You won't necessarily see the exact problem. But having the ability to reduce the problem at hand to an efficient algorithm that you might have "regurgitated".


Bullshit.

It has been my personal experience, and the experience of many people I’ve spoken with, that this kind of trivia is learned in order to get a job and then forgotten immediately afterwards because it’s useless.

Anecdotal example: a former colleague is an incredibly talented systems programmer and has had to study leetcode garbage for the last few months in order to feel qualified to interview for a position with a team that he had previously been on at an older employer.

As another commenter said elsewhere, these types of questions are used because they’re legal proxies for “IQ tests”, and because they filter for people who are willing to sacrifice much of their personal time for the sake of the company.


I don't think the knowledge is useless as much as it's properly abstracted away into core libraries for 99.999% of the real-world use-cases.

Maybe the questions started as "IQ tests" (or a proxy for "fresh out of a Stanford-like CS Program?") but my impression is that now it's a mild (or not) proxy for hazing.

"I suffered through this crap and by God you are going to suffer through it to, or you can't join my little club, and by the way I just make a hundred dollars telling you that."

Edit: clarity & speling


I think knowledge of the concepts is very useful, but precise recall of the algorithmic implementations is absolutely useless.

It’s very different for someone to have a solid grasp of, say, cache-aware programming techniques, algorithms and data structures that are necessary for low-latency architectural work, etc.

...but I’m aware of very few positions (if any???) that require the ability to arbitrarily synthesize that information on the spot.

EDIT: Originally meant to lead with the fact that I broadly agree with what you’re saying, I just wanted to clarify my original objection.


In this regard. I like the google approach for not asking questions that are publicly available on internet.

These are basic computer science fundamentals and critical thinking capabilities that essential for performing the job atleast for software development roles.


"Computer science is no more about computers than astronomy is about telescopes"

-Dijkstra


Economic hardship does not kill those under 35. You need to focus on the social good.


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: