121–130 of 392 posts
Earlier quoted context omitted.
The New Grad had knowledge. The Senior Dev had Understanding. Understanding > Knowledge It's that simple.
More like, The New Grad has Ideals. The Senior Dev had Deadlines. Deadlines > Ideals.
Earlier quoted context omitted.
Hey, I made that meme. It was based on a similar story the one in OPs blogpost. At my first job I used to work with some really talented fresh grads that wanted to show off their algorithms skills and ended up over-engineering stuff. One of them implemented a trie and stored it in SQL lite to implement some string autocomplete where the number of strings was something like 100. The other implemented a 2D segment tree…
New hires showing up at work and doing the one thing they were tested on in the interview. How strange of them!
Can someone explain the bugs in the code samples? The author says they're there but I honestly can't find them.
Edit: As others have stated, the 'out of bounds' exception should be taken care of by the '\0' at the end of strings in C
I always envy people who work on this level instead of cobbling systems together that integrate several systems all with their own set of flaws and you can be happy if you can make them work together somehow. The algorithm stuff seems pretty simple in comparison. A very local problem that can be profiled well and you can understand most of the factors at play.
Gods, it was wonderful!
As I've moved up the ladder and worked on complex enterprise systems, with umpteen integrations, overly-strict SAST systems, enforced 90% test coverage and the like, I seldom feel the "joy of code". It was good to feel it again!
I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity. I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity! In a strict sense big…
I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity. I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity! In a strict sense big…
Earlier quoted context omitted.
Hey, I made that meme. It was based on a similar story the one in OPs blogpost. At my first job I used to work with some really talented fresh grads that wanted to show off their algorithms skills and ended up over-engineering stuff. One of them implemented a trie and stored it in SQL lite to implement some string autocomplete where the number of strings was something like 100. The other implemented a 2D segment tree…
Thanks for the context. The example you describe supports the meme better. Sorry for being harsh, I got triggered by that code inside the printer, because I've dealt with a lot of dumb "I don't know how SQL joins work, so I'll use my ORM to do it and filter the data in code" cases early in my career, and I have sort of an allergy to that now.
Earlier quoted context omitted.
It wasn’t taught to me. And, in my previous job I interviewed many dozen fresh grads. One of my questions was “How much slower is it to sum integers in a trivial linked list vs. a trivial array?” 90% answered “Umm... I don’t know. 2x?” When asked why, they all said “1 op to sum the int +1 op to traverse the pointer.” It was amazingly consistent.
O dear.... Am I happy that I never studied computer 'science'..... On the other hand, there must be smart computer science students and/or smart places of education where actual learning about processor caches and the like takes place.....
Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit. Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet. Days 2-30 [1]: ideate, develop,…