Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.

Tezzeract posted:

Were you talking about something like this:

https://leetcode.com/problems/shortest-path-to-get-all-keys/

If it's more of a graph problem, you can memorize the graph traversal algos and the common book keeping parts like parent arrays/arrival times. And then the remaining problem is finding the set of neighbors in a 2d array.


Yeah that's a great one thanks. There really is a lot of "memorization" of the blueprint algos for solving these problems. I think that's why DP feels so difficult.. even problems that seem similar can present a very tough nuance or two in figuring out the recurrence. There are also the "one trick" problems that are frustrating because unlike the graph/tree traversal problems (and even some sliding window, two pointer array or string problems, etc) writing an algorithm without knowing that "one-trick" is basically going to gently caress you in in terms of time constraint.

Adbot
ADBOT LOVES YOU

Hughlander
May 11, 2005

Pollyanna posted:

Maybe we should be more worried about how we managed to dick up so spectacularly that we can’t roll back whatever change we deployed or scale up to handle whatever higher load we have.

The actual case that I was thinking of is that a 2nd party fostered a 3rd party library on us that bypassed our normal scale test harness and didn't scale. When challenged on it prior to shipping they hit us with, "Don't worry we tested it at scale"

Narrator: They didn't.

And culturally the database migration pattern was to roll forward only not back to avoid having every application developer need to consider the minute chance that every write might be rolled back.

apseudonym
Feb 25, 2011

Good Will Hrunting posted:

Yeah that's a great one thanks. There really is a lot of "memorization" of the blueprint algos for solving these problems. I think that's why DP feels so difficult.. even problems that seem similar can present a very tough nuance or two in figuring out the recurrence. There are also the "one trick" problems that are frustrating because unlike the graph/tree traversal problems (and even some sliding window, two pointer array or string problems, etc) writing an algorithm without knowing that "one-trick" is basically going to gently caress you in in terms of time constraint.

DP is all about identifying and removing duplicated computations. I find it pretty consistently the same if you sketch the naive algorithm, identify the waste, and reorder computation/memoize to avoid it.

For more mathy problems I'll start with the recurrence, but that tends to just get in the way if you have a bit more complicated conditions on dependent computation for me.

thotsky
Jun 7, 2005

hot to trot
I got an offer, it's below my current salary, I want to make a counter offer, but the offer came out of left field from HR, not the director/people I had been talking to. Who do I respond to?

Hughlander
May 11, 2005

thotsky posted:

I got an offer, it's below my current salary, I want to make a counter offer, but the offer came out of left field from HR, not the director/people I had been talking to. Who do I respond to?

HR/recruiting owns the negotiation. They’ll be in contact with the director for guidance but that’s where your negotiations are.

kayakyakr
Feb 16, 2004

Kayak is true
re: Interview coding questions - We talked about it as a team (as we had a bunch of folks just interview elsewhere and decide to stay), and decided that our preferred way of doing the code test portion was to have a project already established (so that development is a matter of cloning, launching, developing), and a list of features to pick up.

The project should be as close as possible to your normal tech stack so that it's very nearly matches up with the actual work the position would be doing. Spend no more than 4 hours on 1 or 2 features, then make a pull request that then gets reviewed in the process and minimize whiteboarding "in person".

Also let folks submit their own existing projects instead of working on our stuff.

Hughlander posted:

Production is making GBS threads itself and the outsourced qa leaves in 90 minutes if you don’t have code submitted in an hour the deploy isn’t going today and we’ll lose more than 2 hours revenue.

Sounds like you need to work on your pre-deploy quality control.

e: vvv ack. that's gross. that client can go eat dirt.

kayakyakr fucked around with this message at 20:20 on May 24, 2021

Hughlander
May 11, 2005

kayakyakr posted:

Sounds like you need to work on your pre-deploy quality control.

See above

Pollyanna
Mar 5, 2005

Milk's on them.


Hughlander posted:

The actual case that I was thinking of is that a 2nd party fostered a 3rd party library on us that bypassed our normal scale test harness and didn't scale. When challenged on it prior to shipping they hit us with, "Don't worry we tested it at scale"

Narrator: They didn't.

Ooooh, somebody’s getting in troubleeeee.

quote:

And culturally the database migration pattern was to roll forward only not back to avoid having every application developer need to consider the minute chance that every write might be rolled back.

So just write an unmigration.

Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.
Feel like I need some primer on how to decompose recursive problems that are more "difficult" than easy. Every other topic has been manageable to improve at pretty quickly with concentrated practice but I was trying Subset Sum with K Partitions yesterday and got absolutely nowhere. With problems like this I sometimes don't even know where to start.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Good Will Hrunting posted:

Feel like I need some primer on how to decompose recursive problems that are more "difficult" than easy. Every other topic has been manageable to improve at pretty quickly with concentrated practice but I was trying Subset Sum with K Partitions yesterday and got absolutely nowhere. With problems like this I sometimes don't even know where to start.

Is your problem breaking the problem down into a structure that's recurrent, or implementing the recurrent structure correctly without messing it up halfway through?

I usually just write out what data I have, what I'm trying to do with it, and why I would stop doing whatever I'm doing.

Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.
There are some problems I don't struggle with at all and figure out an algo quickly. Even something like minimum edits I've gotten comfortable with quickly figuring out the recurrence. Any variation of knapsack? I'm getting more than comfortable.

But for the one example I listed above I really just had no idea where to start to formulate a recursion tree.

Here's the problem btw: https://leetcode.com/problems/partition-to-k-equal-sum-subsets/description/

I obviously figured out how to calculate the way we needed to divide elements, but the recursive algo to place buckets and then backtrack.... didn't even come close.

I know a lot of people say that it just takes practice but I'm wondering whether there's a more efficient way to actually build my understanding. LeetCode explanations are generally trash.

kayakyakr
Feb 16, 2004

Kayak is true

Good Will Hrunting posted:

There are some problems I don't struggle with at all and figure out an algo quickly. Even something like minimum edits I've gotten comfortable with quickly figuring out the recurrence. Any variation of knapsack? I'm getting more than comfortable.

But for the one example I listed above I really just had no idea where to start to formulate a recursion tree.

Here's the problem btw: https://leetcode.com/problems/partition-to-k-equal-sum-subsets/description/

I obviously figured out how to calculate the way we needed to divide elements, but the recursive algo to place buckets and then backtrack.... didn't even come close.

I know a lot of people say that it just takes practice but I'm wondering whether there's a more efficient way to actually build my understanding. LeetCode explanations are generally trash.

I mean, that's a pretty hard one to pick out where the recursion would come from. The way I'd approach something that is asking me to build a recursive function is by looking at what we're looping over, because anything that you could recurse can also be built with nested loops.

In that one, we'd be looping over different ways to partition an array, as well as looping over the partitions to determine if each value equaled our expected outcome. The second, you could easily build a recursive function on, but it's not worth much as that's of something like O(log N) complexity. The first is where the $$ is.

But really, practice, giving in to your insanity, and more practice are still the prescription.

Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.
When we say "practice" do we mean "looking at the problem repeatedly until it clicks in your brain?" It's just been very hard for me to figure out the way to practice these specific types of problems where as like DFS/BFS, array sliding Windows, it's all very straightforward.

kayakyakr
Feb 16, 2004

Kayak is true

Good Will Hrunting posted:

When we say "practice" do we mean "looking at the problem repeatedly until it clicks in your brain?" It's just been very hard for me to figure out the way to practice these specific types of problems where as like DFS/BFS, array sliding Windows, it's all very straightforward.

Well, that's where giving in to your insanity comes in.

asur
Dec 28, 2012

Good Will Hrunting posted:

When we say "practice" do we mean "looking at the problem repeatedly until it clicks in your brain?" It's just been very hard for me to figure out the way to practice these specific types of problems where as like DFS/BFS, array sliding Windows, it's all very straightforward.

Find the answer or hints and then implement it yourself to understand it and move on. If it's not actually a one off then a similar problem will come up in the future and you can see if you come closer.

If you can solve moderate dynamic programming problems you're fine to interview which I assume is your goal. Occasionally you'll run into some rear end in a top hat with a completely unreasonable problem, commonly dp for some reason, and you should just chalk that one down as the bullshit it is and hope the hiring committee realizes that too.

Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.
What would we define as "Medium" for something like DP? I've worked through a few variations of Knapsack, then a couple of the String DP problems (edit distance, substring similarities etc) but not sure if those constitute "easy"

E: On the topic of the difficulty level wrt problem time I'm trying to compile a list of my final review push to start at FAANGs. I'll post it when I'm not high on painkillers from oral surgery and actually on my computer again

Good Will Hrunting fucked around with this message at 03:30 on May 26, 2021

asur
Dec 28, 2012

Good Will Hrunting posted:

What would we define as "Medium" for something like DP? I've worked through a few variations of Knapsack, then a couple of the String DP problems (edit distance, substring similarities etc) but not sure if those constitute "easy"

E: On the topic of the difficulty level wrt problem time I'm trying to compile a list of my final review push to start at FAANGs. I'll post it when I'm not high on painkillers from oral surgery and actually on my computer again

I would put almost any non-trivial dp problem in at least the moderate category. Leet code generally has a decent gauge if you can look at the difficulty on that.

FamDav
Mar 29, 2008

Good Will Hrunting posted:

There are some problems I don't struggle with at all and figure out an algo quickly. Even something like minimum edits I've gotten comfortable with quickly figuring out the recurrence. Any variation of knapsack? I'm getting more than comfortable.

But for the one example I listed above I really just had no idea where to start to formulate a recursion tree.

Here's the problem btw: https://leetcode.com/problems/partition-to-k-equal-sum-subsets/description/

I obviously figured out how to calculate the way we needed to divide elements, but the recursive algo to place buckets and then backtrack.... didn't even come close.

I know a lot of people say that it just takes practice but I'm wondering whether there's a more efficient way to actually build my understanding. LeetCode explanations are generally trash.

this one i would describe as a backtracking problem (you could memoize if you want?), and a heuristic you can use if its available is to notice that the array length is eerily low which implies exponential complexity. in some ways they're the most straightforward of these dumb interview problems because there is literally nothing better you can do, but that is also frustrating because if you didn't know that then you'd be inclined to try and optimize.

reversefungi
Nov 27, 2003

Master of the high hat!
For web end devs, does it make sense to stay full stack, or is it a good idea to eventually start to specialize in front end or back end? I'm pretty comfortable with both and I like both almost equally. Like, I slightly prefer back end (only because CSS is a real pain at times), but I have IMO pretty solid front-end chops. Sometimes I think I have rather weak UI/UX skills, but then I see some of the designs my coworkers come up with and I realize that I'm much more capable than I think.

I only have a little under 4 years experience so I'm still early on in my career, and I'm currently interviewing with a few places. Most of the opportunities are full stack, but there's one opportunity that's progressing that's mainly front-end. I'm a little unsure if I want to start pigeonholing myself into front-end roles. Will I be hurting my career/shooting myself in the foot? Or will the fact that I have past experience make it simpler to go back to back-end if at some point that's my preference? Mostly concerned about my career more than anything else and what impact that will have. Otherwise I personally don't mind focusing in on one of the two for several years.

thotsky
Jun 7, 2005

hot to trot
Frontenders who don't want to pull their test-writing weight because backenders "are better at it" are annoying, so stay full stack.

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


A lot of hiring managers don't want to extend an offer to someone who hasn't been doing the job they're hiring for already. If you go front-end only, you may have some trouble going back to full stack. There are front-end jobs that will appreciate a full stack background, but you'll have to be prepared to explain why you switched.

Queen Victorian
Feb 21, 2018

Yeah probably stay full stack. Full stack and backend roles generally pay more on average than frontend roles anyway. I say this as a combination UI/UX designer/frontend developer from a non-programming design background.

For me, the frontend devs who stand out from the pack are the ones with solid design skills and a good eye/intuition for it. I care more about that than top notch programming skills, being a mediocre self-taught programmer myself and having learned first hand that you don't need a CS degree or mastery over interview algorithms to pop out some React components or whatever.

I'd also be at least slightly leery of a full stack dev applying to frontend positions because full stack -> frontend feels like a step down. Then I'd wonder if it's because you couldn't hack it as a full stack dev or have crippling self esteem issues or something. I'd also be concerned you wouldn't have the design chops I'd want to see in a pure frontend role.

And another note: frontend roles that are not plugged into the UI/UX and design decision aspects run the risk of being soul-crushing codemonkey jobs where all you do is poo poo out components to specifications someone else made and you have no say in the big picture because gently caress you. My previous job degraded into this and it sucked a lot.

Tezzeract
Dec 25, 2007

Think I took a wrong turn...

Good Will Hrunting posted:

Feel like I need some primer on how to decompose recursive problems that are more "difficult" than easy. Every other topic has been manageable to improve at pretty quickly with concentrated practice but I was trying Subset Sum with K Partitions yesterday and got absolutely nowhere. With problems like this I sometimes don't even know where to start.

I tried to model the bottom up DP and completely bricked. I searched online and it is possible with bitmasks to represent the state?

It's a bit crazy how going from K = 2 to an arbitrary K changes the DP's structure.

gbut
Mar 28, 2008

😤I put the UN🇺🇳 in 🎊FUN🎉


I've been trying to carve myself out of "full-stack" for a decade now, as that's the first job I landed stateside. I love front end, I used to be a designer in a previous life, and everything just mentioned above is the main reason I've been taking it slow as it mirrors my experience. It's a shame how the first point if contact with your customers is not considered as valuable as a hacked together crud app for some reason.

marumaru
May 20, 2013




drat why are you attacking me in particular

reversefungi
Nov 27, 2003

Master of the high hat!
Thanks folks, those are all super helpful considerations. I think I sometimes suffer from imposter syndrome when it comes to back end work, as I don't have a CS degree (music degree), but maybe that's just something I need to get over. Is there any particular danger in staying as a full stack "generalist" instead of specializing in either over the long run?

CPColin
Sep 9, 2003

Big ol' smile.
Think about programming like jazz; it's all about the semicolons you don't type.

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


The Dark Wind posted:

Thanks folks, those are all super helpful considerations. I think I sometimes suffer from imposter syndrome when it comes to back end work, as I don't have a CS degree (music degree), but maybe that's just something I need to get over. Is there any particular danger in staying as a full stack "generalist" instead of specializing in either over the long run?

Predictions are hard, especially when you're talking about the future. But I think it's pretty unlikely you're going to see serious problems in the next three years.

pokeyman
Nov 26, 2006

That elephant ate my entire platoon.

CPColin posted:

Think about programming like jazz; it's all about the semicolons you don't type.

I always wondered why music majors love Go and JavaScript.

downout
Jul 6, 2009

I've found quite a few full stack job postings that clearly are targeting more front end focused experience. It's also a need I've seen regularly in teams I've been on (full stack but very FE qualified). I don't know about the pay, but I've seen them!

Roadie
Jun 30, 2013

downout posted:

I've found quite a few full stack job postings that clearly are targeting more front end focused experience. It's also a need I've seen regularly in teams I've been on (full stack but very FE qualified). I don't know about the pay, but I've seen them!

For a lot of basic CRUD-type stuff there are many, many more subtle pitfalls in the frontend work than in the backend, plus all the obvious management bikeshedding is going to be about the frontend workflows.

Roadie fucked around with this message at 04:09 on May 28, 2021

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Queen Victorian posted:

And another note: frontend roles that are not plugged into the UI/UX and design decision aspects run the risk of being soul-crushing codemonkey jobs where all you do is poo poo out components to specifications someone else made and you have no say in the big picture because gently caress you. My previous job degraded into this and it sucked a lot.

even if your front end development role is plugged into ui/ux, you'll still have to deal with endless bike-shedding because everyone has an opinion about ui. front end is a thankless role - it pays less and the coding is generally more ice-sculpture and less interesting than the back end stuff.

Queen Victorian
Feb 21, 2018

Bruegels Fuckbooks posted:

even if your front end development role is plugged into ui/ux, you'll still have to deal with endless bike-shedding because everyone has an opinion about ui. front end is a thankless role - it pays less and the coding is generally more ice-sculpture and less interesting than the back end stuff.

Oh yeah, for sure. The bike shedding sucks and it's relentless. Backend folks can much more easily fend it off by saying some smart-sounding jargon and maybe showing off some lines of code, but frontend is way more tangible and it's much easier for product to be like "what if you made this teal instead of blue" than question database schema implementation choices or something.

The more design power and sway the frontend developer has, the more easily they can push back on bullshit requests and do poo poo the right way and have backup from your team/other higher-ups. I definitely pull the "excuse me I'm a bona fide designer" card when I need to. If it's a larger team with more delineated roles, you want there to be a principle dev/team lead who can shield you from (micro)management meddling and go to bat for you and/or a dedicated UI/UX designer who does the workflows and specs and takes the brunt of the bike shedding. And you can always add a duck.

Still, the worst is when you're in the powerless codemonkey position with enough design knowhow and awareness to realize that what you're making is poo poo but you can't do anything other than follow the bad spec (ask me about
irregular timestamps on an ordinal scale), and then get to take responsibility for it when folks don't like it/start bikeshedding. It's worse still when you have to implement the horrible stupid bike shed ideas against your better judgement.

As for the code, a lot of it is indeed less interesting and not as challenging, but there are some cool areas. Programming data visualizations is typically my interesting/challenging code outlet, for instance.

marumaru
May 20, 2013



downout posted:

I've found quite a few full stack job postings that clearly are targeting more front end focused experience. It's also a need I've seen regularly in teams I've been on (full stack but very FE qualified). I don't know about the pay, but I've seen them!

As someone who isn't that big on back end stuff, I find it's the opposite. For me it's usually been "yeah we need a back end developer who knows how to make a terrible Bootstrap UI (it's really a form)"

Pollyanna
Mar 5, 2005

Milk's on them.


marumaru posted:

As someone who isn't that big on back end stuff, I find it's the opposite. For me it's usually been "yeah we need a back end developer who knows how to make a terrible Bootstrap UI (it's really a form)"

poo poo man, send that my way. I’ve become allergic to JavaScript after dealing with sloppily peppered jQuery everywhere. I can only eat high-quality organic free range React now.

marumaru
May 20, 2013



Pollyanna posted:

poo poo man, send that my way. I’ve become allergic to JavaScript after dealing with sloppily peppered jQuery everywhere. I can only eat high-quality organic free range React now.

With Typescript, right? Right? 🔫

downout
Jul 6, 2009

marumaru posted:

As someone who isn't that big on back end stuff, I find it's the opposite. For me it's usually been "yeah we need a back end developer who knows how to make a terrible Bootstrap UI (it's really a form)"

I see those too in personal experience. And uhhh those sound like the same teams giving the front end devs poo poo about UI choices. Often, conveniently coming from someone who doesn't know poo poo about UI/UX and has too much sway over engineering decisions!

Pollyanna
Mar 5, 2005

Milk's on them.


marumaru posted:

With Typescript, right? Right? 🔫

:ssh: drat well better be.

Comedy CoffeeScript option.

Achmed Jones
Oct 16, 2004



lol all the react work i did back in the day was in coffeescript or (occasionally) plain js. haven't done fullstack since like early 2016 though

do react people still do flux? we had our own home rolled stores and stuff bc there wasn't a turnkey solution and tbh it was great compared to any other frontend work

Adbot
ADBOT LOVES YOU

Flaming June
Oct 21, 2004

I have to help maintain a part of the platform in Coffeescript/Backbone and ugh. At least it isn't the main function of my job

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply