Rest assured their goal is full return to office despite the current "hybrid" model they are pushing, and you are not important enough to them to keep your job while being civilly disobedient.
495 karma · joined May 9, 2017
Rest assured their goal is full return to office despite the current "hybrid" model they are pushing, and you are not important enough to them to keep your job while being civilly disobedient.
-I should speak to someone at the company before having to write code
-Interviews go both ways
-Coding problems should be appropriately sized, encapsulated, and reproducible
-Coding problems should not be real work
LeetCode is just what you get when you ask Software Engineers to solve the interview problem - they like showing off their chops so that's what you get. It doesn't need to be that complicated though. I know with about 80% certainty whether someone will work out based on how they solve that "SimpleProblem". The other 20% - just fire them if they don't work out. It doesn't need to be that hard. You don't need 100% certainty for a hire, you'll never get there. Just fire the ones that don't work out. You don't even need to feel bad for them - in this market they'll find another job by the end of the month.
Signed, someone who works at a company with a culture of sending blank meeting invites
It's easy do dehumanize a voice on the phone. Many people don't want to even use cameras for video calls. How much empathy do you have for a voice on the phone versus a human being you interact with in person on a daily basis?
I think the benefits of remote work far outweigh the work that needs to be done to maintain culture remotely, but it is a new challenge that doesn't have a lot of good understanding around how to make it work.
If you have no goals that's your failing, not the meeting's. If you lack the imagination to see where you want your career to go or the introspection to see where it's headed then, again, your fault - not the meeting.
Questions I get in my one on one's with people who care and are going places: -Why is the organization failing at x/y/z? How can I make that better? Is it worth fixing? -I am having trouble accomplishing e/f/g goal - I've hit q/r/s roadblock. What do you recommend I do about this? -I want your job, how can I change what I am doing to get me closer to what you do?
I also use them to get information I need from these people: -How is your team doing? Is anyone under/overvalued? -Are your commitments on track? -Is there anything I can do to make you or your team more effective?
I mostly have these meetings monthly. A month is long enough for things to change. 6 months is too long - too many things have changed, too many have been forgotten.
Do you know what the sales people in your organization do? What about the legal department? Procurement? HR? Your lack of knowledge is not evidence.
"lol, do some coding instead"? And what should I code? How do you know what _you_ should be coding? Where does that work come from? Who makes sure that you're writing quality code and not some shit spaghetti mess? When the lawyers come knocking who answers the questions about security and compliance? You're just going to write some code for that?
Your myopic complaints do nothing to further your own goals - rather than make baseless accusations, look into the problems yourself and try to solve them. You might get some career growth out of it. At the very least you'll understand that not all problems can be solved with code.
There's no such thing as a hard deadline. Everything is made up. What your manager is saying is: "To be successful in the market, I think I need to have X thing in Y days."
It's the engineer's responsibility to provide information and estimates that will shape the business's direction. If you don't clarify or negotiate requirements based on your technical knowledge and experience and just take requirements as law written in stone you are not providing the true value of an engineer.
If you are doing that - pushing back and grounding requirements in reality - and the business plows ahead with unrealistic goals anyway, then that simply means the people you work with are unreasonable and you should seek employment elsewhere. If they're not even willing to listen to people they're paying to have expertise then they're probably reading the market wrong too and I wouldn't trust them to be around long anyway.
There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.
I understand that you are highly compensated and may not want to spend time trying out for a new job when you already make so much money, but from my perspective: I have a team of highly compensated individuals who are evaluating a candidate for potential hire and I don't want to waste all of their time if the candidate can't even write a simple algorithm to rearrange the characters in a string.
Since it sounds like you're pretty happy where you're at you have the freedom to choose to participate or not. I am guessing that the only way to pull away a candidate like you is by referral anyway, so I am guessing there's not actually a problem here.
If I am getting someone via referral, then interviews can focus on what you find valuable - I can sell you on the role, I can ask you personality questions and make sure there is goal alignment. If I have someone to vouch for you. If you're a stranger? You better believe you gotta write some code.
I think that if you take a step back and ask yourself if you'd really like to work at a place where they hire people who they haven't seen code, you'd probably rather choose to just write some code for 30 minutes in an interview.
The author did a good job expanding on situations that are now not funny, but here’s another one that I see all the time:
Butts in seats. As a manager, anything you say about the clock, the vacancy ratio of an employees chair, anything about time management really is not a joke. It is making the employee feel as though the work they do is not valued and that you expect them to be meat decorations prettying up an office chair.
I used to think that when I was promoted I could still be “one of the guys” - and I try hard to get quality time with the team, joke around, etc - but over time it’s become clear that I can never escape the new context in which my words and actions are perceived.
I can no longer shit on bad code like I used to - I now need to discover how we ended up with the deficiency, plan to correct it, and assure the rest of the engineers that we do have high quality standards we need to live up to.