Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Grad vs. Senior Dev

ericlippert.com

Post reply on HN
Print view View original

151–160 of 392 posts

Re: New Grad vs. Senior Dev

#151

Post by est31 »

lonelappde wrote: post #88
tspop wrote: post #46

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!

Many people can write brute force implementations. But while the meme is funny and great, it only shows a part of reality: sometimes you do have to optimize things. Just don't do it too early and only if there is a clear use case that requires the speed. Then you should be able to write fast code, or at least know which library to use that has a good implementation of the algorithm you need.

Some companies like GAFAM probably put too large focus onto algorithmic questions, but they can afford to lose otherwise good engineers who are bad at algorithmic questions. They need something to filter the masses of applicants they receive.

Re: New Grad vs. Senior Dev

#152

Post by MaxBarraclough »

corysama wrote: post #65
dimtion wrote: post #7

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…

It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…

> briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again

A fine concrete example of this is the Coppersmith–Winograd algorithm (and its derivatives), a matrix multiplication algorithm with impressive complexity properties, but which in practice always loses to the Strassen algorithm, despite Strassen's inferior complexity. [0][1][2]

(Aside: the Strassen algorithm is pretty mind-bending, but also easily shown. If you've got 22 minutes spare, there's a good explanation of it on YouTube. Perhaps there's a more dense source elsewhere. [3])

> It’s not until they get lectures from greybeard software engineers that they learn about the reality algos and not just the idealized algos.

To mirror what some others are saying here, students should also be taught the realities of cache behaviour, SIMD-friendliness, branch prediction, multi-threaded programming, real-time constraints, hardware acceleration, etc.

[0] https://en.wikipedia.org/wiki/Coppersmith%E2%80%93Winograd_a...

[1] https://en.wikipedia.org/wiki/Strassen_algorithm

[2] https://en.wikipedia.org/wiki/Computational_complexity_of_ma...

[3] https://www.youtube.com/watch?v=ORrM-aSNZUs

Re: New Grad vs. Senior Dev

#153

Post by [deleted] »

onekorg wrote: post #135
corysama wrote: post #86

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.

The answer could be 2x. Let's say you're in a 64 bit platform. Your linked list nodes consist of a next pointer and a 64 bit integer. If your linked list nodes are all allocated sequentially in memory then it'd only be 2x as slow as an array of 64 bit integers. But maybe it's not fair to call sequentially allocated linked list a "trivial linked list".

[deleted]

Re: New Grad vs. Senior Dev

#155

Post by saagarjha »

lalaland1125 wrote: post #53
saagarjha wrote: post #33

By the way, here’s an anecdote for the flip side: at one of my internships I was working on a tool to process large log files, and by careful application of Aho-Corasick I was able to make it about 50 times faster on the dataset we were dealing with, which made using the tool change from “let’s go grab lunch while this finishes” to “let’s stream the logs through this live”. Sometimes you do know how to make things fa…

For interest's sake, did you try simply using a decent regex engine as an alternative? Any DFA regex engine implicitly implements Aho-Corasick for you.

I think the engineer before me put a bit of effort into this, but it didn’t work out all that well in this case. This isn’t surprising considering that the standard regex tool on the platform wasn’t known for being particularly performant.

Re: New Grad vs. Senior Dev

#156

Post by mister_hn »

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

Not everyone is accepting suggestions like you.

I am a senior dev and I always try to push new ideas to my team lead (senior dev and older than me), but all I get is blatant criticism because he says "I've tested it and didn't like it). A clear example: refusing to move to Spring Boot and still staying on the dead horse JavaEE, which got more complicated and fragmented than ever since Java 9

Re: New Grad vs. Senior Dev

#157

Post by xapata »

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

To be fair, it's easier to move to 3 now than X years ago. And there's more benefit.

Re: New Grad vs. Senior Dev

#158

Post by 04091948 »

Imagine that the intern didn't dare to ask such questions.

a - he could've gone out thinking that performance doesn't matter. but it certainly does in a piece of code being used daily by thousands of devs.

b - he could've thought that the simple implementation is faster but missed the fact that skip is implemented in assembly.

c - he could've realized both but missed the why.

and these failure scenarios are likely to happen because this is an intern we're speaking about.

One or two tricks up your sleeve do not matter but repeat this a 100 times which one do you think would be a better programmer?

I think the willingness to challenge authority figures and to be (often) proven wrong and to learn from it is an essential part of becoming better.

Maybe Tim was understanding because he himself challenged people older than him and in-process learned form them.

Advice like "don't reinvent the wheel", "avoid premature optimization", "write boring code" promote exploitation. which is the optimal strategy for older agents.

but for newer agents, a higher level of exploration is needed otherwise they would converge into a suboptimal strategy

Re: New Grad vs. Senior Dev

#159

Post by wwweston »

tyleo wrote: post #66

I see these senior vs non-senior engineer contrasts pop up a lot. I’m not a huge fan of them. It seems that there is a spectrum of skills an engineer could excel at: programming, infrastructure, managing, planning, etc. I’ve known senior engineers who only excel at a particular skill. I’ve also known senior engineers who are moderately good at many but not particularly good at one. In my experience the only differenc…

As a senior engineer who is proud of certain strengths and envious of different strengths I see in more often in others than myself, this seems pretty spot on to me.

Re: New Grad vs. Senior Dev

#160

Post by corysama »

joshlemer wrote: post #149
corysama wrote: post #86

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.

What would be the kind answer you're looking for?

The question had 2 goals:

1) Do you think about cache at all or is it just something you heard mentioned as important that one time?

2) It's a good lead-in to discussing the effects of cache in algorithms. How that conversation goes helps me to understand how that person thinks and discusses complex problems.

A good answer would be "I'm not sure, but probably way, way slower because linked list can point all over memory but arrays cache really well."

An excellent, A+ answer would be "In the best case it might not be too much slower if you have an intrusive linked list is arranged sequentially in memory like an array like onekorg explained. But, in practice most will be 20-200x slower because they are usually implemented as pointers to nodes containing pointers to data and each piece is allocated piecemeal in a already fragmented heap. Uncached memory reads can take 100+ cycles and summing an int is not enough work to hide that even if the CPU speculatively prefetches."

I mainly expect a surprised reaction that they could be so slow and looked forward to the follow-up discussion.

Post reply on HN