It's mainly because the way budgets are setup in most companies. Recruiting/new hire budgets are separate from retention. The retention budgets are much smaller and managers have to go through a lot of red tape to give non standard raises especially when it's not during the normal review cycle. For example my counteroffer needed approval from my skip's skip (3 levels up). It's just easier to change jobs, because that's how the system is setup. Some companies are smartening up and proactively give good stock refreshes to retain top talent.

Thanks yeah was pretty bummed. 5 panels, got all of the algorithm questions. For one I spend a good 3 minutes in silence at the start being like I don't know then I figured it out. But for the O of N I completely blanked and had another awkward 5 minutes of I don't know then never really got it. Have fairly bad anxiety so interview situations can cause me to blank. Like when they asked me about differences between technologies I had super bad answers. But no panic attacks so that was cool.

Meh, happy enough with my performance.
Yeah government bureaucracy is nuts. That is how long it takes to process background checks on average, as long as there are "no delays". LOL. Was rejected for advanced entry, because reasons. My contact can't even ask for more information or anything because of the shutdown.

The interview for the government job I totally thought I wouldn't get. We pair programmed some game like battleships in Ruby for 45 minutes. I never wrote ruby before the interview. Fortunately he was the one typing.

Still bummed about it, because the team seemed really tight, the tech would be something I wanted to work on, and the mission was making a lot of positive impact. Oh well, technically I am hired pending a background check. It just won't finish until 2021.

@goofy - make an offer to current employer to buy your claims to equity at half their value. See what they say. Or if the books need to stay “tidy” as you suspect ask them for more options, whatever. See what they say. I suspect you will get turned down.

Yea if the books really need to stay tidy then they will put up.

Seems more like a pathetic attempt to keep you.

Every company I've ever worked for was a small private company when I started, and was acquired either while I worked there, or shortly afterwards. Not all of these would be considered "startups" to most people, since they'd been around for several years.

Only 2 of them really handed out shares.

1. I had a ton of shares, we were bought by another private startup with more money, my shares got converted, that company has never gone public. I think it's still around but as sort of a skeleton.

2. I had a fair number of shares, 1/3 were vested, 2/3 were not. They gave me cash for the vested shares and converted the rest into retention bonus at the current face value of the shares. They also added a significant amount of money to the retention bonus. It was "a lot" of money but not "life changing" money. The retention bonus scales over time, X this year, 2X next year, 4X the year after (which seems like a pretty smart way to retain people).

You can estimate what your shares will be worth, but to do it you have to have an idea how many shares are issued and what the buy price might be. The first should probably be available to find out, the 2nd is going to be a WAG but you can probably guess within an order of magnitude. It might help if you know the current estimated valuation of your company - that's something the place I work kept us up to date on. The number they sold for ended up being somewhere between 1.5 and 2x the most recent number.

Be careful. My options where granted in common stock which were valued at 0.00 a share when the company merged. Only 2 classes of stock made any money so be clear on what you are getting. I knew people who left within a few months of this happening who weren't given the option of converting their options, so if that is still an option it may be because the deal isn't really that close.

Your company's finances may be different than mine of course but if the deal is months away the founder may not actually know how the rank and file are going to end up getting treated.

Non-standard equity agreements like this are generally tricky and can involve tax/legal implications or require things like Board approval. I'm not sure there's a lot to learn here.

How do you guys deal with a co-worker who is difficult to work with?

Last week was trying to understand what this "fix" that this senior engineer was doing. He explained the solution and when I asked him to look at the data ETL query that would clearly point out that his solution would solve nothing, he got extremely irritated and kept saying that what I was trying to do was a different problem. He gets extremely childish and often goes on rants during meetings where it often gets awkward and tiresome to work with.

He eventually opened the PR at the end of the day Friday while everyone was either out on vacation or off for the day and he got one approval from one junior engineer. Then eventually forced merge the PR Monday morning before anyone was in despite the fact that you need 2 approvals before merging.


His "fix" absolutely did nothing and brought in more risks to our service. Do you just try and avoid working with this person? Bring it up to my manager? I'm not the only person who has difficulty collaborating with this individual. There has been a lot of friction between him and the whole team, except with the junior engineer who is a yes-man to everything.

@Barrin6 that definitely sounds like a management problem and not something you can fix on your own.

I would start with a conversation with your manager but try to avoid too much finger pointing or blaming in the beginning. Perhaps start with a discussion of communictaion or teamwork issues and steer towards the problem employee in that context.

Definitely wouldn't try to avoid the issue and hope it goes away.

yikes you need a process review. I'm the sole admin of our project on github enterprise and even I can't merge any code or push to master at all without another person accepting.

Agree with just_grinding.

I had basically this exact thing at my last job (that person was a contributing factor to me leaving).

My boss (vp eng) always came in early so I went in early one day and went into his office saying I wanted to discuss something. I said very clearly and simply that I had seen some concerning things, and that i would be happy to go through the code as well.

You repeat the things that happened, that the person was unwilling to discuss the fix and was stubborn, that they had a single review from the junior, and that they force merged it, with the dates and times. Then you discuss how their code increases risk and does not solve what it is supposed to.

Any half decent eng leader with any experience will be thankful and will know how to deal with it.

lol tbh i’d ignore it if it didn’t directly impact my work

if i were your PM or engineering lead or whoever runs things I’d want to know though.

Every single person on my team except my boss is a “difficult personality” in their own unique ways. You just gotta be really good at not pointing blame, use “we” kind of statements instead of “you” especially when talking about work they did.

I am trying to overcome it by just developing good personal relationships with everyone and it’s helped a lot.

speaking of reviews, how does that process work at your guys’ companies?

Our flow is issue gets created, assigned, worked on, then pull request. Reviewer is usually requested but not assigned. A lot of times the work is so specific to that person’s domain of knowledge that no one can really adequately review it except my boss who is too low on bandwidth most of the time. So our pull requests pile up. i’ve been trying to think of a good solution but coming up blank

Maybe other shops work differently, but pull requests sitting around for more than a day waiting to be reviewed is bad imo. Ideally things should get merged fast, and devs working on that same release should be pulling in the latest changes daily. Much less chance for weird conflicts down the line.

So no idea about your review situation - but I think not tolerating backed up PRs is a start.

no one wants to tolerate it it just never seems like anything can be done about it, there’s a lot of unhappiness about it.

we’re merging two of our projects into one so we should be more focused in the next month or two that may help things. I know it will certainly help me manage easier when we’re all working on the same thing and not being pulled 40 different directions

Thanks guys. We have a retro after every sprint so I’ll bring it up. But I’ll also bring it to my manager on how to best deal with this. I think key thing here is to focus on the process rather than trying to single out the person.

I'm working on the same thing with one other person and it's perfectly manageable, but I can see even having 3 people would be difficult and getting more difficult with each additional developer. Version control isn't magic. If you can't separate what you're working on from someone else you have to coordinate very closely. Though I'm in no position experience-wise to make such pronouncements, it seems pretty obvious.

I would rather just designate some people as leads who can merge their own PRs after a day if no one else is available or able to review it.

The first rule should be no PRs sit for more than a day. A bad PR is less bad than a PR that sits there for 2 weeks imo. Fail fast, fail hard, etc.

Review is great, and maybe even a junior dev sees something obvious that a senior dev missed because they were too buried in the weeds. But like you said - if it's a PR from a lead-level developer, a lot of the time they're really the only one who can really do a deep, thorough review anyway.

Ultimately imo the only reviews that should be 100% mandatory imo are leads reviewing jr. devs' stuff - for training, internal consistency, best practices, big picture stuff that the jr. dev might not be aware of, etc. The only time we really got burnt was when a lazy lead was just rubber stamping stuff from jr/offshore devs. But the leads learn pretty quick after that.

Best one yet.

Definitely make it about the process and detach it from any type of personal issue.

That you are concerned with a potential issue of code quality and process breakdown and you want to bring it up the ladder to help everyone be better.

This. It's very hard to thread the needle of reporting something to your boss w/o seeming like a tattle-tale, especially when you are emotionally invested and already have some personal issues with this person.

If you can find some way to bond over some other issue, or happy hour or something - it's incredible how much impact that has on these supposedly non-related code issues - from their side and from your side.

Personally think bringing something like this up at retro isn't great. It always feels passive aggressive when it's bright up as a team wide issue or an attack if you call out one person.

Ultimately it's a coaching opportunity. You could talk to the junior about not being such a doormat and finding their own voice. And you can have your manager talk to the senior about taking and soliciting feedback

Yea it really makes a huge difference. Every management book ive read lately mentions some form of doing this.

Classic example was of some bug ridden process we had that drove a lot of other processes. There was a lot of infighting and disagreement about the person responsible for this process. So I just took him for a walk, explained what we needed it to do, why it was important that this worked smoothly, and the impact on the rest of the team - the issue was fixed in a week and there hasn't been a single hiccup in like 4 months. But it was a really hard conversation and one I could not have had if he didn't like me on a personal level.

My advice was based specifically on the above. This is a team wide issue and imho needs some sort of team wide intervention which should be handled by a manager and not a teammate. Even if the manager just tries to build commeraderie amongst teammates.

I agree that developing 1 on 1 relationships with your teammates is awesome and should be highly encouraged.