|
Pollyanna posted:How do you make sure you’re getting quality experience, anyway? I hear a lot about not doing the same thing over and over again etc., and there’s taking on projects and higher responsibilities, but “quality experience” is still a bit vague to me, and it’s not clear how to find, recognize, and pursue it. If I find myself able to complete features / tasks without so much as a glance at the documentation, or some kind of struggle, it's not teaching me anything and I'm better off letting someone more junior than me do those tasks. I try to identify the tasks that seem "scariest" (most unknowns) and take those for myself whenever possible. It's fine to be comfortable in a language or a framework, and to do things quickly and easily, but learning comes from new experiences. Even when I'm doing something I've done before, I'll try to improve on it in some way. If I'm truly repeating myself, perhaps it's a refactoring to extract a shared module. If not, I'll read through the documentation and see if there's a best practice or something I'm not aware of, and try to improve the code that way. There's a lot of angles you could focus on, whether it's performance, usability, or extensibility. I also try to spend a little time each day educating myself, whether it's trying a puzzle problem like Advent of Code or reading a technical manual. I actually try to do this first thing after I start in the morning so I'm fresh. 30 minutes a day adds up.
|
#
?
Dec 5, 2019 22:32
|
|
|
|
| # ? May 9, 2024 22:25 |
|
|
Pollyanna posted:How do you make sure you’re getting quality experience, anyway? I hear a lot about not doing the same thing over and over again etc., and there’s taking on projects and higher responsibilities, but “quality experience” is still a bit vague to me, and it’s not clear how to find, recognize, and pursue it. Spend two years in role and move up, move laterally, or move on. I read once that it takes two years to master the set of skills for a role, and after that you’re just performing. I don’t have a source for that, but it matches my experience.
|
|
#
?
Dec 5, 2019 23:47
|
|
|
I had an interview at a company I liked, and they actually extended me an offer, but it'd be a downgrade in seniority (who knows how they make these distinctions, but they thought I was mid-level on the cusp of being senior rather than being senior) and the pay is lower (the base only slightly but the target bonus substantially lower). Is it even worth trying to salvage an offer like this or should I just move on? I'm not exactly desperate to take a new job right away, and while I like the company I don't think I like it so much I want to take a substantial pay cut.
RICHUNCLEPENNYBAGS fucked around with this message at 02:39 on Dec 6, 2019 |
|
#
?
Dec 6, 2019 02:33
|
|
|
Tell them pretty much exactly that, and what you'd need for it to be worth while. Don't budge on it, and whatever happens it sounds like you'll be happy. No sense not at least giving them the opportunity.
|
|
#
?
Dec 6, 2019 02:40
|
|
|
If you’re not desperate don’t take a big pay cut IMO. It’d be one thing if their leveling was just different but pay met expectations. Something like that can happen especially going from a small to a large company. But a title reduction and a pay cut sounds like a downgrade, unless you really really want to work there for other reasons. Sounds like you’re willing to walk away. I’d probably tell them (nicely) that the offered position and opportunities at that level doesn’t meet your bar for moving. Maybe they’ll adjust, maybe they won’t. Either way worst case you keep your current job.
|
|
#
?
Dec 6, 2019 03:02
|
|
|
Thanks, those are both helpful perspectives. I guess I should have mentioned that I also learned after I kicked off this process that my current company determined after a salary review that I belong at the principal level based on my salary and their bands so I'm getting a promotion, at least on paper. I'm not sure how much that means in practice though. Does weigh on my mind that I could be going upwards at the current place or down at the new one and the sizes of the organizations are different but not like small-to-huge.
|
|
#
?
Dec 6, 2019 03:16
|
|
|
RICHUNCLEPENNYBAGS posted:Thanks, those are both helpful perspectives. I guess I should have mentioned that I also learned after I kicked off this process that my current company determined after a salary review that I belong at the principal level based on my salary and their bands so I'm getting a promotion, at least on paper. I'm not sure how much that means in practice though. Does weigh on my mind that I could be going upwards at the current place or down at the new one and the sizes of the organizations are different but not like small-to-huge. One or both of these companies has weird titling; in the generic Google-ish levels that many tech companies have, principal and mid-level are three to four levels apart.
|
|
#
?
Dec 6, 2019 14:33
|
|
|
Pollyanna posted:How do you make sure you’re getting quality experience, anyway? I hear a lot about not doing the same thing over and over again etc., and there’s taking on projects and higher responsibilities, but “quality experience” is still a bit vague to me, and it’s not clear how to find, recognize, and pursue it. Know your weaknesses and the gaps in your knowledge, and then work to fill them in. It doesn't have to be gigantic, it just has to be useful, for example: In interviewing earlier this year I realized that the cloud platforms are hot right now(every position asked about it, even those that didn't strictly use it) and I've not had a chance professionally to work with them - so I spent a week or two getting familiar with Azure concepts by tossing a repo up on Azure Devops, and signing up for an App Services subscription to toy around with Pipelines, and extend from there into Cosmos and Functions. Now, next time I get asked if I have any experience with Azure, I can talk about it because I've learned something about the bones of it, even if I haven't touched every single corner of its offerings. Learning how to make code run, and to make a bug go away are the equivalent of learning to walk. The industry is full of people whose resumes may as well say "I am proficient with foot-based autonomous pathfinding with over 10 years of experience." But they only ever use that skill to walk between the fridge and the sofa - never a library or a mountaintop.
|
|
#
?
Dec 6, 2019 15:01
|
|
|
prisoner of waffles posted:This smells funny to me. Usually a manager who hires is not given recruiter-ish incentives, right? It's attrition and hiring based. If I stay within 10% of my allocated headcount for the year it adds to my bonus. If I have a raft of attrition or don't fill my new heads I won't get paid for that. Given that I have a bunch of new heads and 0 attrition, the equation is dominated by filling those open slots. I also have delivery, quality, morale and compute costs related goals that factor into my bonus so I can't just hire a bunch of schlubs (or really now allow my managers to do that) because the rest of the goals would go to hell. wins32767 fucked around with this message at 19:43 on Dec 6, 2019 |
|
#
?
Dec 6, 2019 19:39
|
|
|
wins32767 posted:It's attrition and hiring based. If I stay within 10% of my allocated headcount for the year it adds to my bonus. If I have a raft of attrition or don't fill my new heads I won't get paid for that. Given that I have a bunch of new heads and 0 attrition, the equation is dominated by filling those open slots. Are these normal parameters for a manager’s bonus?
|
|
#
?
Dec 6, 2019 20:10
|
|
|
wins32767 posted:I also have delivery, quality, morale and compute costs related goals that factor into my bonus so I can't just hire a bunch of schlubs (or really now allow my managers to do that) because the rest of the goals would go to hell. Ahh, I misread what you meant when you said that your bonus was not related to what your team “makes” (as in their compensation).
|
|
#
?
Dec 6, 2019 20:28
|
|
|
lifg posted:Are these normal parameters for a manager’s bonus? At least in my experience there isn't really a standard. I've had bonuses based entirely on how the company is doing, bonuses where my boss got a pot of money and assigned my share of it based on his or her judgement, bonuses where the head of product and I got pot of money for our own bonuses and those of our teams and had to divvy them up (which is a story unto itself), and now this one.
|
|
#
?
Dec 6, 2019 23:38
|
|
|
raminasi posted:One or both of these companies has weird titling; in the generic Google-ish levels that many tech companies have, principal and mid-level are three to four levels apart. Well the current one is junior mid senior principal and then they have a bunch of loftier ones that theoretically someone could have
|
|
#
?
Dec 7, 2019 01:04
|
|
|
Current one is weird; it skips staff and senior staff
|
|
#
?
Dec 7, 2019 02:08
|
|
|
Junior/mid/senior are the only standardized levels. Everything above that is highly idiosyncratic.
|
|
#
?
Dec 7, 2019 02:10
|
|
|
ultrafilter posted:Junior/mid/senior are the only standardized levels. Everything above that is highly idiosyncratic. This is true. I've worked places where above senior was any mix of staff, advisory, principal, lead, fellow, and probably some others, and they tend to not necessarily translate to whatever ladder some other company uses. That said, typically principal is top of the IC ladder and has at least one level between senior and principal, often several. Title inflation is also rampant at smaller companies... because fancy titles are free.
|
|
#
?
Dec 7, 2019 02:52
|
|
|
So what I'm getting here is you guys don't think the seniority level in terms of title is very important.
|
|
#
?
Dec 7, 2019 04:02
|
|
|
It depends on the company. If you're at a small startup, people just assume that you're a beneficiary/victim of title inflation. If you're at a larger company and your resume indicates that you did something that involved leadership, then it matters. If you're a principal at a FAANG company, you might not even need a resume.
|
|
#
?
Dec 7, 2019 04:08
|
|
|
In an established company the seniority level of a position is very important, but the title is not a very useful way to compare positions between companies.
|
|
#
?
Dec 7, 2019 04:39
|
|
|
I forget who here posted this, but I loved it so much I kept it.quote:
|
|
#
?
Dec 7, 2019 07:10
|
|
|
Junior - Can (poorly) rewrite everything they see Regular - Can fix bugs or write features in a way that causes other problems because they can't make sense of this pile of poo poo who wrote this code they're terrible Senior - Can fix the bug or write the feature that happened to crawl up the product owner's rear end today, gently caress it they can keep jerking me around I'll just be conveniently unreachable when everything catches fire from lack of maintenance I don't care anymore Lead - Can get poo poo on by the product owner and fail to help code because they're out of practice Architect - Can balkanize the technology stack with toy projects in new languages they wanted to play with, that they then release to production without documentation and toss them to the regulars to own VP - Can deliver platitudes during good times and panicked anxiety during outages I'm not jaded no sir
|
|
#
?
Dec 7, 2019 08:07
|
|
|
a hot gujju bhabhi posted:I mean, I know it's all by the by, but who on earth thinks stools are "more office like"? Is this a US thing? Do Americans work on stools? I didn't realize you had asked about all this and I had left the thread alone. I'm not really sure myself, but I grew up with it particularly in college. My wife came from a family with a manufacturing business so I'm pretty sure they were using elevated desks too. At college, the computer engineering labs were using different elevations from a normal desk all the way to standing counter height, even though everybody was just coding away regardless of lab. I was never into the higher desks but figured I'd put up with it when my wife design the layout for the office in our new house. However, between this desk and this chair, I've exacerbated a spasm in my teres major/minor on my left side and my quadriceps get really right. Anyways, I have an electrical adjustable desk kit coming; there was a major Amazon coupon when I was looking at them so I went electric after all. I also got an Aeron from a Craigslist refurbisher. That chair doesn't go high enough to use right now so my cats currently use it for personal study.
|
|
#
?
Dec 8, 2019 19:22
|
|
|
So I had a BigN interview and I got the feedback that I did great on the coding portions but they weren't impressed with my answers to the system design portion, so they weren't going to move forward. I wonder if you guys would recommend any resources on how to approach those questions in the future. I kind of approached it as "let's start with the simplest thing that could possibly work and start to scale it up as they add requirements" (so basically I started with a plain old ASP.NET server with a SQL database) but my interviewer clearly didn't seem very impressed with this approach, and also I had the sense that I was not giving the expected level of detail.
RICHUNCLEPENNYBAGS fucked around with this message at 02:29 on Dec 10, 2019 |
|
#
?
Dec 10, 2019 02:27
|
|
|
You should establish scale and expectations at the start of the interview and it's probably the most important part of the interview. If you aren't on the same page as the interviewer then you're highly likely to fail as you'll run into something unsolvable with your architecture and won't have time to redo the entire design.
|
|
#
?
Dec 10, 2019 02:59
|
|
|
asur posted:You should establish scale and expectations at the start of the interview and it's probably the most important part of the interview. If you aren't on the same page as the interviewer then you're highly likely to fail as you'll run into something unsolvable with your architecture and won't have time to redo the entire design. You know, establishing the scale sounds like obvious advice now that you mention it.
|
|
#
?
Dec 10, 2019 03:06
|
|
|
You don't mention the problem, but I wouldn't generically use a RDBMS database. Most of the problems are performance centric and the expectation is to use a KV Store. At the very least be prepared to justify the type of database you choose and the advantages and disadvantages it provides.
|
|
#
?
Dec 10, 2019 03:21
|
|
|
yeah the whole "system design" part of the Google interview sucks, and you basically have to answer with exactly what they're looking for. Just look around at the various bits of things in terms of "Cracking the Google Interview" and you'll figure out what you need to say next time
|
|
#
?
Dec 10, 2019 03:27
|
|
|
The System Design question is what screwed me up at my Amazon interview. I was told to study Gang of Four object patterns, then they asked a system design question, and all I could do was flip through my mental Rolodex of wrong answers. “Abstract factory? Strategy? Singleton?”
|
|
#
?
Dec 10, 2019 03:35
|
|
|
I didn't make it either for mine but wasn't told specifically my system design stuff sucked. In one case, they were less interested in establishing scale than seeing software design. I was surprised. I got the impression they were more interested in API than what I got out of online courses. Something I think helped was studying beforehand which hipster database to use such that I can scale by throwing more machines at it. I don't do distributed stuff normally so I fixated on it. What little I knew was apparently enough...
|
|
#
?
Dec 10, 2019 04:06
|
|
|
I always recommend this book for the meat of the systems design interviews https://www.amazon.com/dp/1449373321/ I wish I had read it before my system design interviews. This site helped me with a general approach to a system design interview https://www.hiredintech.com/classrooms/system-design/lesson/55
|
|
#
?
Dec 10, 2019 04:16
|
|
|
Suspicious Dish posted:yeah the whole "system design" part of the Google interview sucks, and you basically have to answer with exactly what they're looking for. I don't give system design interviews but I don't think this is generally true. If it was true for you then you had a bad interviewer.
|
|
#
?
Dec 10, 2019 04:18
|
|
|
asur posted:You don't mention the problem, but I wouldn't generically use a RDBMS database. Most of the problems are performance centric and the expectation is to use a KV Store. At the very least be prepared to justify the type of database you choose and the advantages and disadvantages it provides. It was a variant on "design an online store" and my rationale was basically "unless you have some specific performance reason to want to do it it makes more sense to start with a relational database and start introducing KV stores, denormalization, and all the rest when you actually have a reason to" but since the interviewer kept asking I don't think that answer was the right one. It seems like a reasonable rationale IRL to me but maybe I'm just an idiot. RICHUNCLEPENNYBAGS fucked around with this message at 05:01 on Dec 10, 2019 |
|
#
?
Dec 10, 2019 04:56
|
|
|
Also, thanks for all your recommendations.
|
|
#
?
Dec 10, 2019 04:58
|
|
|
RICHUNCLEPENNYBAGS posted:It was a variant on "design an online store" and my rationale was basically "unless you have some specific performance reason to want to do it it makes more sense to start with a relational database and start introducing KV stores, denormalization, and all the rest when you actually have a reason to" but since the interviewer kept asking I don't think that answer was the right one. It seems like a reasonable rationale IRL to me but maybe I'm just an idiot. They probably wanted you to ask questions about what kind of load was expected and to address potential bottlenecks from there. They should have guided you in that direction though if it wasn't the way you naturally went.
|
|
#
?
Dec 10, 2019 05:05
|
|
|
Jose Valasquez posted:They probably wanted you to ask questions about what kind of load was expected and to address potential bottlenecks from there. They should have guided you in that direction though if it wasn't the way you naturally went. Oh, well, I suppose that makes a lot of sense.
|
|
#
?
Dec 10, 2019 05:16
|
|
|
I did some mock system design interviews with a friend who worked at a FAANG, and I asked about costs; like, how much do we have to spend, what infra do we already have that we can leverage, and my friend strongly discouraged me from pursuing that line of thought, even though it's a totally reasonable thing to ask in a real world scenario. They really just want you to hit the technical points of ~~scale~~: load balancing, high availability, resiliency, latency, etc.
|
|
#
?
Dec 10, 2019 05:55
|
|
|
RICHUNCLEPENNYBAGS posted:It was a variant on "design an online store" and my rationale was basically "unless you have some specific performance reason to want to do it it makes more sense to start with a relational database and start introducing KV stores, denormalization, and all the rest when you actually have a reason to" but since the interviewer kept asking I don't think that answer was the right one. It seems like a reasonable rationale IRL to me but maybe I'm just an idiot. I guarantee you that the interviewer is operating under the assumption that this is solving for the current Amazon scale. It's not bad idea to assume that it's the largest relavent company if the interviewer doesn't clarify the scale after you ask.
|
|
#
?
Dec 10, 2019 06:18
|
|
|
minato posted:I did some mock system design interviews with a friend who worked at a FAANG, and I asked about costs; like, how much do we have to spend, what infra do we already have that we can leverage, and my friend strongly discouraged me from pursuing that line of thought, even though it's a totally reasonable thing to ask in a real world scenario. They really just want you to hit the technical points of ~~scale~~: load balancing, high availability, resiliency, latency, etc. Yeah, as a general rule you don't worry about cost at the large companies until it becomes a problem. It's premature optimization -- almost literally. People will get promoted when they discover that some algorithm that runs billions of times a minute is O(n^3) for no good reason and they can cut the fleet by thousands of compute units...but until you get that big it's just not worth worrying about. Your own time as a developer is way more expensive than throwing more compute resources at a badly-written algorithm. Meanwhile, being unable to handle 1/10th of the world's population hammering on your product is perceived as making it de facto unviable.
|
|
#
?
Dec 10, 2019 06:25
|
|
|
asur posted:I guarantee you that the interviewer is operating under the assumption that this is solving for the current Amazon scale. It's not bad idea to assume that it's the largest relavent company if the interviewer doesn't clarify the scale after you ask. Man... OK, that makes sense but I completely started from the wrong assumptions, which explains a lot
|
|
#
?
Dec 10, 2019 12:22
|
|
|
|
| # ? May 9, 2024 22:25 |
|
|
Don’t feel too bad. Amazon-scale problems are outliers, and them expecting you to read their mind on that is just another stupid (albeit predictable) job interviewing thing. I was at a Facebook recruiting event disguised as a conference and one presenter’s theme was “Almost everybody doesn’t need to sample distributed traces, you can actually grab ‘em all, which lets you do some really cool things.” The first question she got was “Facebook and Google just showed us their fancy sampling-based distributed tracing systems, are they wrong?” and her answer was “I said almost all. You aren’t Facebook.”
|
|
#
?
Dec 10, 2019 14:24
|
|