New Grad vs. Senior Dev • Hacker News Board

Re: New Grad vs. Senior Dev

#131

Post by DonHopkins » Sat, Mar 28, 2020, 6:09 PM UTC

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!

I like to ask interviewees to imitate the sound a computer would make over an AM radio while executing different algorithms.

Nested for loops go brrrrrrrrrrrr, munching squares go bweep bweep bwweeeep bwweeeep bwweeeep bwweeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bweep bweep bweep bweep...

https://www.youtube.com/watch?v=V4oRHv-Svwc

Life goes shlup shlup shlup shlup shlup...

https://www.youtube.com/watch?v=hB78NXH77s4

If they use any Don Martin sound effects, I hire them on the spot.

https://www.madcoversite.com/dmd-alphabetical.html

>CHK CHK CHA-GONK BRBBRBBRING! -- Man's Eyes Being Poked Like A Cash Registers' Keys And Jaw Popping Open Like A Till Drawer -- Mad #61, Mar 1961, Page 18 -- Kitzel's Department Store

Re: New Grad vs. Senior Dev

#132

Post by dasyatidprime » Sat, Mar 28, 2020, 6:11 PM UTC

leetrout wrote: post #82

alexis_fr wrote: post #63

Earlier quoted context omitted.

> if I see someone use a linked list Or a hashmap to prepare 3 variables to pass to Json serialization.

I think that hits the human factor of software development where it is easier to conceptualize your hashmap will become that JSON object. Curious - what would be your solution? Just creating the json directly as strings / bytes?

Unsorted-array-based maps are sometimes used in the Java world, and for two or three elements will have much less overhead than hash tables. For instance, fastutil has http://fastutil.di.unimi.it/docs/it/unimi/dsi/fastutil/objec.... The map interface and encapsulation into a single “object” is the same.

It occurs to me that I don't know whether any of the major dynamic language implementations with maps/dicts/hashes as a central data structure use a similar approach for very small ones… huh.

Re: New Grad vs. Senior Dev

#133

Post by Ididntdothis » Sat, Mar 28, 2020, 6:17 PM UTC

GordonS wrote: post #125

Ididntdothis wrote: post #23

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.

I got the chance at work recently to work solo on a small, greenfield project, where I was fully in control of all the pieces and the problem space was small. I could do it any which way I wanted. 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".…

For a while I worked in video decoding/encoding. That was true engineering. I loved reading up about cache and assembly and then applying this knowledge to our code. It was ok to work on one function for weeks just to get 20% speed up. Now I do enterprise and it’s just horrible. Between dealing with stakeholders and 3rd party systems that barely work there is no room for systematic engineering.

Re: New Grad vs. Senior Dev

#134

Post by est31 » Sat, Mar 28, 2020, 6:20 PM UTC

tspop wrote: post #46

TeMPOraL wrote: post #11

Oh god. That meme. I've seen it a day or two ago. Can't find the picture anywhere now (I've seen it in some group chat). Anyway, beyond the words quoted at the beginning of this article, the meme's "nested loops go brrr" had a picture of a triple-nested loop using Active Record to do some simple database operations. To which the correct response is: "it's a 'senior developer' in an industry where you get called a 'se…

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…

Wow it was based on a real world story. Makes the meme even better.

Re: New Grad vs. Senior Dev

#135

Post by onekorg » Sat, Mar 28, 2020, 6:25 PM UTC

corysama wrote: post #86

dilyevsky wrote: post #67

Earlier quoted context omitted.

Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too

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".

Re: New Grad vs. Senior Dev

#136

Post by maliker » Sat, Mar 28, 2020, 6:26 PM UTC

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 readability improvements (f-strings) in 3. I can get the test/refactor done in a month, and I think it's a net positive." They were right, and now we're on python3.

So, sometimes we all learn something.

Re: New Grad vs. Senior Dev

#137

Post by ericlippert » Sat, Mar 28, 2020, 6:29 PM UTC

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…

Well then, feel free to write your own blog post on a topic you enjoy more!

Re: New Grad vs. Senior Dev

#138

Post by jayd16 » Sat, Mar 28, 2020, 6:33 PM UTC

dmoy wrote: post #42

TeMPOraL wrote: post #35

Earlier quoted context omitted.

It's not even that. You could have a normal hash table with a decent hashing function, and you'll still get beaten by a flat array for small n (hundreds, low thousands), because the array is contiguous in memory - so operations like search or moving stuff around after addition make extremely good use of CPU's cache.

> the array is contiguous in memory - so operations like search or moving stuff around after addition make extremely good use of CPU's cache Also - if I see someone try to use a linked list for an enormous data structure again.... Wow it does not scale worth crap because it turns out that the hardware is actually important, and contiguous memory is amazing.

In this case complexity analysis would tell you that.

Re: New Grad vs. Senior Dev

#139

Post by Jasper_ » Sat, Mar 28, 2020, 6:34 PM UTC

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…

Models are easy when you turn every cow into a sphere. But physicists never believe their models respect the real world. Computer Science should be about the Science of Computers, not hypothetical models acting on hypothetical architectures.

Re: New Grad vs. Senior Dev

#140

Post by ericlippert » Sat, Mar 28, 2020, 6:35 PM UTC

cwzwarich wrote: post #93

ericlippert wrote: post #62

Earlier quoted context omitted.

One of the most important things you can do in perf analysis is to know when to stop looking for incremental improvement. If this subject in particular interests you, we did a lot of work in the C# lexer/parser so that once the file is lexed, it only re-lexes the tokens which changed on every edit. It also does fun stuff like the syntax colourizer only runs on code that's actually on the screen. Getting every operati…

Does the C# parser implement incremental parsing by just using a recursive descent parser with caching, or does it do parsing with nonterminals as lookahead?

It does a full lex and parse. Then if there is an edit, it determines based on the edit which tokens need to be re-lexed; maybe we went from "[10,20]" to "[10.20]" and so now the [ and ] tokens are fine but everything in the middle is changed.

So we go from a data structure representing "original text plus edit" to a data structure representing "original lex plus changes". Now we have the information we need to do the same to the parse tree, which has also been stored. Given the set of tokens in the program which changed, and knowledge of where the textual boundaries are of every parse node, we can restrict the re-parse to the affected syntax tree spine. In the example given, we know that we've still got, say, an array index list but the contents of the list need to be re-parsed, so we re-start the parser on the left bracket.

The algorithm that does this is called "the blender", and reading that code makes my brain feel like it is in a blender. The code was written by Neal Gafter and based on his PhD thesis in incremental parser theory.

The source code is available on github; do a search for "roslyn" and you'll find it.