It’s not worth staying at a company that gets acquired, you’ll either get laid off or be asked to do the same work with less people, and awful morale.
I wouldn't be quick to dismiss the idea that this is a show.
I absolutely have done things like this when acquiring companies - sat with people, asked them to basically interview for their own jobs while showing me the most important thing they wrote in the last quarter. I've done this at a much smaller scale, one on one at the employee's desk, because the companies I've done this with have been 1/10 or 1/100th the size of twitter.
I can see why it might make sense to just tell people to print stuff out to demonstrate competency, if you're otherwise planning to cut their entire department. Everyone gets a quick conversation with an engineer to talk about the code and gauge basic competency. If you don't suck, you stay. Seems not super crazy.
It especially makes sense if you've locked out everyone aside from previously identified key personnel to prevent sabotage.
If you ask me to print my code and defend it in a meeting, I will instead skip the meeting and respond to one of the dozens recruiters who reach out every week in my inbox. You can keep the engineers who wrote the slow code in the first place. I'm sure they'll have thousands of lines of code to print.
It's just a demeaning process meant to assert the dominance of the new owners.
Its not about “defending”, its about explaining. Even from your reply one can feel the instant defensive position you take when asked about (your) code. I think ability to disassociate from your code and just be able to discuss it (not defend) and explain what and why (tradeoffs) and how was done is very valuable in developer, and in anyone actually if you extend it beyond the code.
When take over a company ant talk with people and they take defensive position thats a red flag for me. (I take over companies in my head only so far)
It doesn’t matter if it’s about defending or explaining. Either one is an absolutely absurd situation to find yourself in where you have to explain stuff to people with zero context to save your job.
If I was given these instructions I’m out.
(I don’t have a horse in this race. I don’t work there. So not sure why you think I’m taking this personally)
That's your threshold for asking employees to summarize what they've been doing recently?
Management must have some profound interest in the feature being delivered and how it was implemented?
Question: have you ever managed people? And if so, how many?
I won’t go into your ad hominem.
While you're entitled to your opinion, it doesn't seem particularly relevant in discussions about whether or not this process is effective.
no one wants your code just for fun of it or it beying extra nice and smart. code is neded becauae it creates value.
The question itself comes from a place of authority, and the employee has nothing to gain, only to lose. Best case - I keep my job. Worst case - I get fired. That introduces stress into my life unnecessarily.
The new owners can go and read past evaluations instead of boiling the ocean. But, of course they won't do that. It's much easier to assert your authority and stress everyone out, to make sure they know that they are just resources churning out code.
If you step out of the soulless business mindset for one second, I'm sure you'll understand why asking me to prove my worth out of the blue is insulting.
"Prove your worth to the new gods, employee #1337!"
No, thanks.
Not sure from which perspective you're saying "No" from?
If you were a Twitter employee, that means quitting. But apparently from what you just said you don't want to lose your job. (There's no stress if getting fired is something that doesn't bother you)
Or from a management perspective? In which case I think vincnetas did a good job explaining why management might want to do this if they wanted to downsize.
Basically you're saying the concept of laying off people is a ridiculous viewpoint because it makes employees feel stressed. Sure this is just a discussion forum and we're all free to express opinions, but realistically, what makes you think an employee can say "No, thanks" to this?
Sure there is, long painful meetings where you go over your work for the last 30 days sounds miserable regardless of if you care about the outcome.
You also might lose your severance package.
While you can't say no thanks, if put in that situation by my employer I'd do the bare minimum and start lining up interviews with the tens of recruiters that message me daily (as I'm sure is the case for anyone with twitter on their resume)
Isn't that his goal? Reduce headcount before vesting bonuses on Nov. 1st? It seems like you would be just the sucker that Musk is trying to get rid of before one last milestone cash payment.
On top of which, why couldn't you defend that line in a meeting? "I changed this one line cutting the loading time in half for the program. It took 2 days of profiling to find where to change and another week to ensure that it works across all build targets and work on a deployment timeline."
> 's just a demeaning process meant to assert the dominance of the new owners.
It is in fact a bit of that. Employees who quit are cheaper than fired employees or continued-to-be-hired employees. doing something unreasonable to make them quit seems reasonable, even if that might skew more towards the better employees.
But it's also a rough attempt to identify deadweight who cannot explain why they did anything of value in 2 months.
It's about identifying the most extreme offenders and pushing out people like the GP who will rage quit without severance.
Not sure if you personally are a Twitter employee but Twitter fits a certain demographic of employee who wants to traverse that fine line between not wanting to risk an early startup for potential huge upside but also doesn't want a boring cushy job at Salesforce or Google or whatever.
If you value your time and not the money, there's better places to apply your talents and labor than Twitter (pre or post Elon)
Sure, I've done the exact same thing. What's stopping you from bringing that line of code to an interview and talking about it?
> "If you ask me to print my code and defend it in a meeting, I will instead skip the meeting and respond to one of the dozens recruiters who reach out every week in my inbox. "
When you interview with your new employer, won't you be discussing notable achievements such as the single line of code you wrote that cuts app startup time by half?
> "It's just a demeaning process meant to assert the dominance of the new owners."
Are interviews demeaning? In a sense, sure. Sounds like you're doing it one way or the other, though.
GP's answer is essentially "sure, but what stops me from not doing that instead?":
>> I will instead skip the meeting and respond to one of the dozens recruiters who reach out every week in my inbox.
I have to say, I agree. Why stay around for the circus when you can leave and make an honest living as a respected professional instead of playing post-acquisition hunger games as a pawn in a rich boy's ego trip gone awry?
Nothing of course -- and this is always true, every second of every day.
> "I have to say, I agree. Why stay around for the circus when you can leave and make an honest living as a respected professional instead of playing post-acquisition hunger games as a pawn in a rich boy's ego trip gone awry? "
If you see it that way then it seems in everyone's best interest that you leave the company, which means the system worked exactly as intended.
As to the question of whether this makes sense, it would seem we all agree that it does, then.
I don't and have never worked at Twitter :)
> As to the question of whether this makes sense, it would seem we all agree that it does, then.
My comments are mostly about the likely future of Twitter, which is almost certainly atrophy and death.
> "My comments are mostly about the likely future of Twitter, which is almost certainly atrophy and death. "
This was already their future, so I guess we can see if they improve at all.
Review of work based on your last 30 days of code that’s printed out on 8.5x11s is nonsensical. I’ve never heard of anything like it in my software development career and can’t think of any reason one would do it except to encourage people to quit.
This is builds the same dysfunctional system's that causing so many problems for Google - the people maintaining the vital systems won't have anything cool to show, but they will be the ones that made sure the bills kept getting paid.
> I can see why it might make sense to just tell people to print stuff out to demonstrate competency
All they are demonstrating their is their ability to sell themselves.
Look, we all should know how this works. We're viewing selective aspects of their process through the warped perspective of the national media. You're not hearing about any of the reasonable things they're doing because none of those things are interesting. You're only hearing about elements which can be presented as shocking, to get your eyeballs on news bites.
Take a step back and think about perspective.
All kinds of information is exchanged in an acquisition. The acquirer probably has an idea about how the company functions, which departments are key, which employees are key, and so on. They'll also have an idea about which employees or departments have been problems.
I am thinking of a specific example where my large company acquired a small startup. It had a sysadmin team of three people. This team had been identified as a point of conflict within the company - holding up projects and refusing to adopt automated process. It was already decided that the manager would be fired. My job was to determine the extent to which the employees were contributing to the dynamic, to determine whether they were open to change, and to assess their general competency. We needed to know how much of the existing team could be kept on to help.
I flew onsite for a few days. The story was that the acquiring company was gifting me to help their team, because they had been long complaining about needing headcount. I asked to be shown what people did day to day. I asked why it was done that way and I suggested new ways of doing it (how it would probably be done, post acquisition) and listened to their answers. I participated in their daily work routine.
As I recall we decided to keep all the employees. They had been marginalized by a bad manager and they ended up doing quite well helping out with the transition. The information I gathered helped structure the layout of the new team. Their old (fired) manager had not done a good job of assessing their skillsets or giving them latitude to move their platform forward.
Other times, I have identified people that needed to be let go. Sometimes it is clear that someone doesn't have the necessary skillset, isn't making meaningful contributions, or has some kind of personality conflict. I think we have all encountered someone like this in our careers at times.
The twitter process sounds chaotic and driven by a crazy timeline for sure. The scale is far larger. But, the steps they're taking to attempt to achieve this goal don't seem inherently wrong. Asking someone to bring a real sample of their work to discuss in an interview is a great tactic. If you asked me to design a process to hold these kinds of interviews at scale I might do the exact same thing.
Or short term thinking. Maybe take... I dunno, a couple of weeks to assess people's value? Instead of potentially firing people you actually should have kept around and spending 35% more on salaries for replacements and God knows how much in lost domain knowledge.
Not ethical, not rational.
That a pretty bad method finding the bad apples, more of the opposite. Someone like Musk who claims to have Asperger's should know this.
Just shut the company down and start over, don't turn people's lives into a living hell for weeks or months
Have you ever done manual labor for a living? Or worked a service job? Or taken care of a relative who needs round-the-clock care?
Would you really characterize as "summarize the last few months of coding at my software engineering job" as a living hell as compared to those things?
You think manual labor is hard, try living in a Ukraine war zone, you think a warzone is bad, try living as a forced prostitute etc.
And according to Dante there are seven circles of hell and if someone t plunges your future into uncertainty it's a valid kind of hell, just not the worst kind.
I have enough perspective, savings, and self confidence that there's nothing a little prick manager can do at a job that will ruin MY life. But there are a lot of honest, hard-working people out there who just want to do their best and make enough to keep on top of their $7500 mortgage payments and don't need someone putting a boot on their neck
Is this something that literally is happening? Where can we read about it?
edit: Apparently referring to this: https://www.bloomberg.com/news/articles/2022-10-27/tesla-eng...
Doing that seems like an improvement.
Interviewer: So this is just a quick question to warm up with. Imagine you have to write a program that is supplied a number n and prints out, for each number in order from 1 to n, the string Fizz if it is a multiple of 3, the str-
Engineer: Okay, so first I'll install cups. What model of printer am I using?
Edited: technical review isn’t code review.
I've done on paper reviews as well where it was just easier than getting access to the code repos. Sure it's like 50 lbs of paper but whatever. The nice thing with paper is you're basically sorting, you toss the interesting pages to one side and the uninteresting to the other.
Both of these were 20 person companies so I could review the 200-500kloc codebases in around 8 hours. It's not the most fun day :)
I feel like what you could do in 8 hours would be less "reviewing" and more "starting to get a basic sense of the codebase in the way a new hire would" but when you're the new CEO of the company maybe saying that doesn't sound cool enough?
To say you got everything you needed in 8 hours is disrespectful at best (even for way smaller code bases)
If I'm doing dilligence, I'm looking to see if there IS ops, deployment, etc. I'm checking the coverage of the IAC compared to the infra (can spot check in console and ioc). You can ask for an overview of metrics code and how thye monitor their infra (walk through a dashboard). Diligence is NOT being able to re-write the codebase, or even work in it. It's to make sure that what people are saying is happening, is there, is with high confidence, actually there. You're also looking for "oh shit". Such as no IAC, no tests, no monitoring.
My goal was to reduce the risks that the acquiring company felt were the biggest. I did that in 8 hours. Then we focused on specific risks previously identified in the review. That usually took the form of asking the selling company to explain, not for me to read more code. Usually the answers clarify the concerns, or admit them.
Of course, those things are absolutely vital, and must be long and tedious work, and I give you kudos for having these skills :-)
There is no way we're going to see a 70% cut and twitter survives. There is also no way an outside party cam figure out what the "unimportant" systems are in days or even weeks.
Realistically if you want to cut you start by reviewing everything and pretend you just want to understand. You place key people in key positions and help them build an understanding. After 3-6 months of observing maybe you can do some cutting.
I was just saying if I had to (because I was being asked to) cut 70% or even 10% immediately that's what I would do. But I'm also not sure I'd take that job.
I'm just enjoying the popcorn cause no one seems to know what's going on.
When you get to interesting code you then slow way down, maybe 10loc / minute.
Remember, for diligence, you're doing risk reduction, your job specifically is determine that there is in fact secret sauce, the product is there, not to understand it. In fact it's problematic if you 100% understand that secret sauce.
I've worked on due diligence from both sides of the table in the past and this is not how it works.
Imagine if Elon bought an airline and asked them to line up all the planes on the tarmac for review.
I could unironically imagine Elon doing this
What would be wrong with that? In a search for low hanging fruit, the planes that can’t make it to the tarmac would be a group of their own. Of the ones that do, next to others some stand out as being noticeably different. Etc. Then patterns may emerge based on that, iterate iterate. Seems to depend on where you’ve set the bar.
If you were an office space Bob, depending on the bar placement, you may just be interviewing to see if someone loses their cool when asked “what is it you do here?”.
If you were a cop you might bring in every suspect just to see if someone stands out.
So what am I missing? Is it the scale of the operation?
In this case, there is a major scramble to test every employee as quickly as possible by outsiders who have no idea how the company operates, what their standards are like, or what the problem space is about.
Barely self driving cars controlled by touch screens are almost entirely disconnected from a social media network other than that both employ programmers. Everything from the data processing location to the user interaction model is vastly different. The standards of quality of different components vastly differ; a UI bug in Twitter is far from catastrophic unlike a UI bug in your car, but a backend bug in Twitter can sink the business whereas a backend bug with Tesla can be annoying at worst.
I'm sure Tesla's developers are competent but the environment they operate in is completely different from the environment the people they review operate in.
At worst, the entire review produces no usable results because the Tesla developers don't have time to study the code base and validate any of the claims the devs make. At worst, the rushed reports are used to bypass layoff laws by providing a "reason" to fire people.
Either way, the end result is that the entire process is no more than pointless busywork for Tesla's people and has no real benefit to the Twitter code base.
Knowing Elon's intentions to fire half of Twitter but his subsequent retraction (probably advice from his lawyers because of layoff laws) I think it's foolish not to be sceptical of this entire event.
Code review can be a great tool to improve a business when it's done well; however, the rate at which things are progressing now indicates to me that this isn't done well.
That attitude is also why both his successes and his failures are spectacular. When you deviate from the beaten path and run as fast as you can in that new direction sometimes you reach a far better vantage point and sometimes you just get totally lost in the jungle. With Elon you never know which way things will go.
I’m with the GP - sometimes when you have a goal that you need to reach in a very short period of time, you do things that don’t scale and don’t follow standard best practices. I see zero issues with lining up all the planes on the tarmac and walking a pilot mechanic pair through each of them for a fifteen minute review per plane. Do they find every problem? Do they misdiagnose? Of course. Are they able to roughly say “this feels like the industry norm, I don’t see anything you wouldn’t see at another airline” or “I am surprised at the rough shape of many of the cockpits. Yes they fly but there might be other issues. Two planes stood out more than the others I’d start there for a deeper inspection.”
Def not unreasonable.
This was a change in ownership, not an acquisition. There's an assumption about a lot of dead weight at Twitter. There certainly may be, but it's not simple redundancies (ie, you don't need 2 accounting depts.). Instead they'll have to figure out if Twitter really needs that many people.
My guess is Twitter isn't as over-staffed as people think. Content moderation and multi-country policy likely require a lot of staff. To quote Scott Galloway on his attempted company take overs, "I often find out I'm not as smart as I thought I was, and the existing management isn't as dumb as I thought they were."