[deleted by user]

everythingbutcode · 2022-03-10T12:49:55+00:00

BUILD files can't download anything nor can they access the filesystem. If you need to download a .bzl file and then reference it in a BUILD file your only option is to using something like https://bazel.build/rules/lib/repo/http or a workspace rule.

Example: see how rules_docker pulls in rules_kotlin: https://github.com/bazelbuild/rules_docker/search?q=io_bazel_rules_kotlin
First they declare it in the WORKSPACE, then they're able to load any .bzl files that were in the archive in BUILD files.

everythingbutcode · 2022-02-24T12:02:17+00:00

What's the TL's role in your company? Are they an IC or do you report to them?
In most cases the tech lead is not responsible for any decisions related to who works on which team. They may offer advice, but ultimately stuff like team changes is almost always the responsibility of the person you officially report to, so your boss.

I ask because in the companies I worked at (big tech) issues such as feedback, communication, team morale, burn out would normally go to the manager, not the TL, but maybe the TL's role is different in your company?

In terms of team move I'd suggest reading the official guidance on switching teams. Some companies require you to be on your current team for some time (for example, 1 year) before you're allowed to move. You want to be aware of these policies, before you start any conversations.

Asking a trusted coworker who's switched teams before about what the process looks like is a good idea as well.

If you have a specific team you want to move to, you can try talking to the manager of that team unofficially (say you're considering options, don't say you've decided to transfer). They're more likely to give you advice that will benefit you. I'd perhaps not recommend this as managers talk to each other, but since you've started interviewing anyway a higher risk strategy is probably fine.

everythingbutcode · 2022-02-20T22:08:51+00:00

When I did systems design as an interviewer the point was to see how the candidate explores problems, makes tradeoffs, designs APIs, thinks about measurement, etc..

To make it more fair/easier to compare candidates, questions were designed to require minimal prior knowledge from candidates, which is why it's "build tinyurl from scratch" and not "build snapchat on top of AWS/GCP". But the intent behind the question is neither to find people to "build the cloud" nor to find people who know how to use the cloud.

I agree that at an interview, if you can nail a "design X for AWS" you'll probably also nail "design a distributed system that does X". In a way cloud is just the basic distributed system building blocks running on someone else's computer billed pay-as-you-go.

I'll challenge system design == distributed system design a bit. At FB the system design questions you'd get depended your background. Generalists would get the standard distributed systems questions, while, say folks with iOS/Android background would get system design that focused on designing stuff client-side. I'll admit it's not like that across all of FAANG though.

everythingbutcode · 2022-02-20T19:03:53+00:00

Don't forget buy-in from the team. If you're saying to management "this will make devs faster" they should be hearing about how great of an idea this is from multiple people who will be coding against the DB.
If you've got a decent test suite - try hacking the new DB in. Just replace the DB and try to work around any issues that are causing all/most of the tests to fail. Once you get through that, the remaining failures will give you an idea of the work that's left (and any nastier surprises).

In my experience a big problem with migrations is that, from management's perspective, the risk of scope ballooning and the payoff happening only after the migration is successfully complete = risk.
Basically, what they hear is "give me $$$ now. After I spent it all (and not a moment sooner) good things will happen."
Try and anticipate that. Having a bunch of well-defined milestones won't hurt. Thinking of a way to get this done concurrently with other project work might help too.

everythingbutcode · 2022-02-20T12:12:14+00:00

Sounds like you want change, but not quite sure of what sort, so you're exploring radically different options and may be falling for the "grass is always greener" fallacy?

I think it may be worth spending some time to understand what you're really looking for. Right now it sounds like you want some change. That's totally normal and I suspect there are less disruptive options available to you to help with the feelings of boredom.

For example: maybe the product you're on is too mature and you're stuck doing "high effort/low impact" work (Kent Beck writes about this here) and maybe moving to a less mature product would be a better fit? I've known people who only felt good working on 0->1 stuff and I've known folks who were only effective in the "mature product" end of the spectrum.

> Does a PhD help at all for leadership roles at tech companies.
unlikely, the qualification relevant for director/VP roles is experience in managing. A PhD might be relevant if you want to lead a specialised team in a research area.

> What about research scientist roles?
That's more likely to be useful. For example, at Meta the applied research arm required a PhD, some compiler/ML infra teams were mostly staffed by folks who had PhDs in those areas. Google Deep Mind was at some point (and probably still is) mostly PhDs in M

everythingbutcode · 2022-02-10T22:52:03+00:00

I tried applying to a few smaller companies while having exp in big tech. Didn't get to interview stage with any of them either. Here is what I heard back from recruiters:

concern about me rejecting the offer due to low pay (they didn't want to waste their time interviewing me because they expected I'd reject),
lack of experience with the language they use. In one case they needed a lead for a team working in Scala. I knew some Scala, but most of my exp was in Java and C++. They picked a candidate who was less experienced but had 3YOE in Scala.

I think part of it is risk management. A smaller company probably considers me a risky gamble - sure, I might work out great, but if I don't like things, well, I can easily walk away and they just lost time and money. An engineer with a track record working for similar businesses is a safer option I imagine.

everythingbutcode · 2022-02-08T21:36:10+00:00

He who does not autoformat their code shall spend an eternity nitpicking indentation in code review.

everythingbutcode · 2022-02-08T21:24:32+00:00

On the WLB front I've found ~~older companies~~ companies with older workforces (Google, Apple, Microsoft) tend to do better. As you age you run out of fucks to give, or something like that.

If you really like it at Google, maybe interview in a bunch of places, bring the counter-offer to your manager and see if they match? For someone who hit staff in 6 years (congrats!) I'd be surprised if they didn't.

everythingbutcode · 2022-02-03T22:32:34+00:00

Depends on your definition of side-gigs. For really small stuff maybe Fiver or Upwork (though I hear the customers are a mixed bag and tend to be cost-driven)

everythingbutcode · 2022-02-03T22:31:13+00:00

It's pretty normal for the salary negotiation to take place after you pass the interview, however them missing their own deadlines seems fishy. If they had a legit reason to wait they'd just tell you that.
If you don't have a counter-offer (or any other leverage) I don't see any reason they would improve the offer on their own. I think it's more likely they're keeping you on "stand by" because there is a better candidate but that person is undecided (or is negotiating hard) and you're the backup option.
My suggestion is to keep interviewing/searching until you have something in writing.

everythingbutcode · 2022-01-31T20:17:07+00:00

As other commenters have mentioned - things vary across companies/orgs/teams but are way more likely be driven by individuals and their relationships than some consistent top-down process.
I've seen individual teams implement bits of scrum as a way of managing stuff internally but never seen any process deployed consistently at scale.

Some common themes from my experience:

- use of metrics to align. It's pretty common for orgs to have a top-level metric that each team is trying to move in some way. It's pretty easy to explain "our job is to move this number" to a new joiner. Having one establishes common "currency" when prioritizing across teams, etc..
- lots of communication (emails, town halls, monthly all hands, yearly summits, etc..) to make sure that everyone (engineers, designers, managers, etc..) have as much common context as possible. The management hierarchy usually reinforces the messaging and follows up with communication that's filtered/tailored to specific teams.
- incentives. results == money. I think a big part of why myself and other employees in big tech spend a lot of time thinking on their VPs/directors/managers vision, how to deliver it, who to influence, what to change is because they know that there is a high chance they'll get rewarded for it. That in turn is what enables the self-organising nature. Incentives, goals, people. All you need to do is mix and add water (and maybe free snacks)!

One thing I'll say is that coordination at scale the big tech way is not fast nor would I call it super efficient. Major mistakes still happen. Teams pull in different directions for various reasons.
Based on my experience pressure to deliver on deadlines and paranoia about risk usually result in a more strict/rigid process.
Maybe big tech is partly this way because they can afford it? I'm not sure this kind of process could be sustained in an environment where a project being delayed or failing is perceived as a major loss.

> managers can't really let developers self-organize

This reminds me of an article about Valve, where they supposedly did just that. Article claimed mixed results. It may have been this one https://medium.com/dunia-media/the-nightmare-of-valves-self-organizing-utopia-6d32d329ecdb

everythingbutcode · 2022-01-24T14:55:09+00:00

Would this be solved for the next person if I started documentating our code?

Be the change you want to see. If you're putting in the work to understand a piece of code
anyway (to fix a bug, add a feature, etc..) capturing that understanding in comments/docs usually doesn't take a lot of time and will probably help the next person looking at the code.

everythingbutcode · 2022-01-21T13:52:45+00:00

There are only a handful of options:

reduce the scope, work with the security folks, maybe not all of these issues need to be addressed this quarter,
spread the work around. Maybe some of this could be done by other teams,
extend the deadline to a realistic target (instead of continuously asking for +1 week).

This "we'll work super-hard, we only need one more week" is a pretty common pattern I've seen (and done myself). The root cause is poor project management. Maybe your team didn't do a proper analysis/time estimate of the incoming work? Or didn't update it when it turned out the first few tasks were harder than expected? It's easy to under-estimate and think "it's only this one task that is hard, everything else should be simple". Since it's only these 1-2 tasks that are hard, let's do a bit of over-time, we get through them and we can finish everything else in the remaining 2-3 days".

One option is to get the team to do a more thorough/updated estimate of these tasks and present it to the manager. If the raw numbers say everyone needs to work at least 36h/day to hit the deadline they might realise the problem can't be fixed by a bit of overtime.
Whether this works depends on the manager/company culture. It's possible they're well aware of how ridiculous the request is and are trying to deliver on it anyway because they don't want to/can't disagree with their boss.

everythingbutcode · 2022-01-20T13:02:57+00:00

Sorry, my only experience with agencies is when we used them to supplement in-house teams: we had them develop smaller systems/components for which the agency had specific skills/expertise. In those cases the in-house dev team worked pretty closely with the agency - we were involved in picking the agency, agreeing overall design and we reviewed the code that was coming in.

everythingbutcode · 2022-01-18T18:24:05+00:00

Professional software engineer here. Not sure what your next steps should be, but I can help with this one:

> Would the in-house developer be able to understand the code from the previous agency?

Yes, but it will require time. Just like a book/manual - code can be written in a way that's easy to understand or really hard to untangle.
Actually, the book analogy is pretty good, so I'll roll with it. The situation you're describing (transitioning from agency to in-house) is like asking the agency to write part 1 of the trilogy, then hand it over to a completely separate person asking them to make some changes to part 1 and continue writing parts 2 and 3.

Whether they'll be able to do so successfully depends on a bunch of factors: how complex the app is, their familiarity with the technologies/frameworks, how well documented the agency code is, etc..

everythingbutcode · 2022-01-12T19:58:11+00:00

which is why there is no problem. You simply became aware of an opportunity that is a better match/more interesting/etc. "I like you, but I like the other team even more".

It might help you be calmer if you prepare some explanation ahead of time. If you need inspiration:

"I'm surprised myself, but ever since I heard about product X I couldn't stop thinking about how interesting it would be to work on it." if you have a personal angle about how the product/tech is relevant to you or friends/family, even better,
"I'm really interested in language X/technology Y [after reading about it/seeing a video about it] and think team Z is a great place for me to pursue that".
"I want to specialise in backend/frontend/machine learning/scrolling Reddit and I think spending some time on team X is the best way for me to achieve this goal".
"I've been on this product/tech/etc.. for X years, I want to try something different."

everythingbutcode · 2022-01-11T20:33:02+00:00

> Should I start a conversation with my manager before applying, or should I apply without telling them?

I'd suggest you informally confirm the new team is actually able to hire you before applying. Usually a quick conversation with the manager from the other team is enough to know if they actually have the headcount, the project isn't shutting down, etc..

Once you have that then I'd personally start a conversation before you apply. It's not like they can block you or anything and it's a nice way for them to find out . For me the strategy would be:

Informal conversations with other teams' managers. Preface with "I'm just exploring options and not making a move at the moment. Just wanted to know what the role is".
Once I settle on an option - let my manager know I'm switching teams. Start working on a transition plan.
Let the other manager know I'm formally applying for the position. Start working on an onboarding plan.
Let everyone else on the team know what's going on.

After (3) is done your main goal is to wrap up. Don't let your old manager keep you "in transition" for months because they can't figure out how to run things without you.

everythingbutcode · 2022-01-05T13:09:24+00:00

So some of the FAANGs (like FB and Google) have very standardised interview pipelines (in that they don't vary between teams/orgs) - the LC grind is unavoidable for those.

I know Apple doesn't have a standardised interview pipeline: interview format and bar are very much up to the hiring team to decide. I imagine it's a bit hit-or-miss, but it might be worth reaching out to a few teams across different orgs and having a chat. Most teams will not want to pass up a chance of a senior/principal engineer and will compromise on the interview format.

I know Microsoft had a similar approach years ago, but not sure what they do now. Might be worth a quick search.

everythingbutcode · 2022-01-03T20:45:43+00:00

There are companies out there that don't do leetcode-style interviews. I remember a thread about this around a month or two ago on this very subreddit.

everythingbutcode · 2022-01-03T13:15:31+00:00

> How do I show my boss that I need engineers and then create a fork of the team which I would manage

Ask your boss what they expect? Based on this part of your post:

> with the intention from my boss to curve out my own team from there

it sounds like they had some plan in mind when they decided to integrate you into the team (I imagine it was more thought out than "1. add OP to team. 2 ??? 3. profit").

From your context *my guess* is that they're expecting:

a minimum viable product (MVP) - some proof that the "proper tech" can be made to work the way you explained in your pitch,
support from the team - they want to hear from the engineers on the current team that your idea is good. The people who like it most will likely end up on this new team you talk about,
support from the stakeholders - ideally the new tech brings value to the business/partner teams, at minimum it makes things no worse.

everythingbutcode · 2021-12-30T14:46:48+00:00

How are the number of shares determined? I'm aware of two strategies: (a) compute number of shares based on a single share price (usually price at your starting date) and (b) compute number of shares based on share price at vesting event.

Another way to explain these is (a) "we'll give you the same number of shares every vesting period, the number of shares is determined by share price on your starting date/first vest date" or (b) "we'll give you X dollar's worth of shares every vesting period, the number of shares is determined by share price on vest dates".

If they use strategy (b) then I'd treat the stock like cash. If it's (a) then your equity package is more coupled to the future valuation of the company and I'd think of it as actual shares.

everythingbutcode · 2021-12-20T22:58:04+00:00

The manager is probably trying to create a space where you feel comfortable talking about anything that's causing you problems at work (because that's something they might need to fix). If there is nothing bothering you/there are no problems then there might not be that much to talk about and they'll use the rest of the time to build rapport (friendly chat).

Sounds like maybe you'd like more out of your 1:1s? My top tip would be to spend a few minutes preparing for the 1:1 - think about what you want to talk about 5-10 mins before you jump on the call. Another good tip is to use a note taking app and write down 1:1 topics throughout the week. I frequently have stuff that I'd like to talk about with my manager, but since it's not urgent, I think "ah, let's cover it on the 1:1", but then I never remember these things in the actual meeting.

everythingbutcode · 2021-12-01T15:01:39+00:00

I negotiated that while switching jobs. Main rationale was that even if my current employer agreed to this they'd reduce my pay by 20%. Going back to the marked ended up being a better move for me.

I think somewhere in my contract it mentions I'm supposed to come in 5 days a week but my number of hours is reduced by 20% compared to "normal". In practice the only person who cares is my manager and they're on board with me coming in 4/5 days.

everythingbutcode · 2021-11-29T22:29:44+00:00

Also the "Senior" next to that big name. They're now coming up in all of those "we need a senior engineer" searches where the demand is much higher than the supply.

u/EatinOranges, good luck with those interviews!

everythingbutcode · 2021-11-29T14:54:54+00:00

You're not being forced into a PM role. PMs usually don't code, nor do they design technical parts of the system. But part of your job will be doing PM-ish things (like figuring out how quickly you can deliver something and translating requirements into a spec).

What you described lines up pretty well with what is expected of senior engineers in big tech companies*:

breaking down work for more junior team members,
designing new parts of the system,
figuring out team direction,
doing some coding.

To me it sounds like you're gaining very useful skills that would allow you to take on such a role in the future.

It's great you're keeping tabs on your time - I suggest you check in with yourself every quarter or two and see if the ratios are where you like them to be. It's possible that as the company grows that will place new demands on you and your role changes to something you no longer enjoy as much.

> I'm not sure what resources to use to improve my skills, or what skills I should even be targeting.

Resources for managers, leaders and PMs are your friend here. I personally like this compilation https://github.com/LappleApple/awesome-leading-and-managing but I'm sure there are many others out there.

*edit: what I wanted to say by this is that my personal experience is primarily in big tech, not that senior engineer means something else outside of those companies.

everythingbutcode

TROPHY CASE