|
Tezzeract posted:Were you talking about something like this: 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.
|
# ? May 23, 2021 21:52 |
|
|
# ? May 26, 2024 18:14 |
|
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.
|
# ? May 24, 2021 02:13 |
|
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.
|
# ? May 24, 2021 05:35 |
|
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?
|
# ? May 24, 2021 18:32 |
|
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.
|
# ? May 24, 2021 18:59 |
|
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 |
# ? May 24, 2021 19:55 |
|
kayakyakr posted:Sounds like you need to work on your pre-deploy quality control. See above
|
# ? May 24, 2021 20:01 |
|
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" 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.
|
# ? May 25, 2021 03:29 |
|
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.
|
# ? May 25, 2021 15:53 |
|
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.
|
# ? May 25, 2021 18:02 |
|
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.
|
# ? May 25, 2021 18:58 |
|
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. 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.
|
# ? May 25, 2021 19:27 |
|
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.
|
# ? May 25, 2021 19:30 |
|
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.
|
# ? May 25, 2021 20:20 |
|
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.
|
# ? May 26, 2021 02:04 |
|
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 |
# ? May 26, 2021 03:16 |
|
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" 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.
|
# ? May 26, 2021 03:44 |
|
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. 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.
|
# ? May 27, 2021 04:56 |
|
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.
|
# ? May 27, 2021 21:23 |
|
Frontenders who don't want to pull their test-writing weight because backenders "are better at it" are annoying, so stay full stack.
|
# ? May 27, 2021 21:40 |
|
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.
|
# ? May 27, 2021 22:16 |
|
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.
|
# ? May 27, 2021 23:08 |
|
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.
|
# ? May 28, 2021 00:03 |
|
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.
|
# ? May 28, 2021 00:04 |
|
drat why are you attacking me in particular
|
# ? May 28, 2021 00:34 |
|
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?
|
# ? May 28, 2021 01:08 |
|
Think about programming like jazz; it's all about the semicolons you don't type.
|
# ? May 28, 2021 01:11 |
|
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.
|
# ? May 28, 2021 01:15 |
|
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.
|
# ? May 28, 2021 01:18 |
|
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!
|
# ? May 28, 2021 02:00 |
|
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 |
# ? May 28, 2021 03:43 |
|
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.
|
# ? May 28, 2021 05:33 |
|
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.
|
# ? May 28, 2021 06:49 |
|
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)"
|
# ? May 28, 2021 13:42 |
|
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.
|
# ? May 28, 2021 15:38 |
|
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? 🔫
|
# ? May 28, 2021 16:18 |
|
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!
|
# ? May 28, 2021 16:28 |
|
marumaru posted:With Typescript, right? Right? 🔫 drat well better be. Comedy CoffeeScript option.
|
# ? May 28, 2021 17:23 |
|
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
|
# ? May 28, 2021 17:32 |
|
|
# ? May 26, 2024 18:14 |
|
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
|
# ? May 28, 2021 18:40 |