HN user

binarytox1n

495 karma
Posts0
Comments40
View on HN
No posts found.

Banks in the US are _very_ insistent on the return to office mandate. Noncompliance would be met with termination.

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 believe they meant to use the tildes to indicate a strikethrough text format, as with markdown. The "cul", I would guess is an unfinished "cultists", even though you'd typically strikethrough a completed word. When trying to indicate a "change of mind" it would be better to use a dash: "Better at retaining cul- uh, employees."

No idea why you're downvoted - these points all make sense:

-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

The problem with this is that your previous manager may be an idiot who can't accurately judge your skills. You have the same problem: your manager is no more trustworthy than you are, and it's much easier to just have you write some code in front of me to solve this problem.

You'd be shocked at how bad the average software developer is at writing software. I've interviewed many people who can't solve FizzBuzz level problems. In interviews I have people program a function to rearrange characters in a string, appropriately named "SimpleProblem", and >50% of candidates with experience can't write a function that compiles and solves the problem.

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.

I don't know why you're downvoted - it's absolute nonsense to think that your CTO should be 80% your best developer. Your CTO should not be writing code at a company with >100 employees - why would they maintain 80% of the skillset of someone who's entire job is writing code? Is the assertion that what a CTO does is only 20% different than what a software engineer does?

To expand - every meeting should have a clear agenda that is communicated beforehand. How can anyone expect to be prepared for a meeting if they don't even know what it's about? Spend the 60 seconds it takes to put a description on your meeting request.

Signed, someone who works at a company with a culture of sending blank meeting invites

People here are suggesting credentialing as if it will remove interview requirements rather than simply add a new hoop to jump through. I do not believe required credentialing solves the interviewing problem at all. You see it today with the certifications that already exist in the market. They aren't worth the paper they're printed on. Anyone can trivially study and pass the certification tests and still never have implemented a system, nor even have basic programming ability.

I would think that if anyone is overreacting it's the person who thinks people who struggle to identify with remote workers are sociopaths. I haven't made any black and white statements or used absolute terms such as "no empathy". I know people in general struggle with nuance, but come on - I'm making it easy here.

I am a manager and do have a concern for company culture. Culture is how the teams work together - socially, professionally. It's harder to maintain culture remotely. It switches from something that "just happens" with a bit of care to something that has to be actively fostered.

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.

The two people in the meeting decide it. I'm sure if either of them are creepy then you will end up with a creepy meeting. Otherwise it's just a professional meeting with an agenda and a desired outcome, like any other.

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.

It's impossible to overstate how much I agree with the need for a separate project management role. Project management is the biggest distraction I have from the "things only I can do" and the biggest morale and time suck. I don't have advice to give because I haven't solved my lack-of-project-management problem, but I sincerely believe I could be much more effective if this was off my plate.

One on one meetings are not "creepy" - they are a chance to have an open conversation about your goals; your concerns; and anything else that needs to be discussed about your career, the organization, etc.

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.

I make a judgement call - either I end the interview immediately or skip most of the rest of the interview, let them think they made it all the way through the interview and say that we will get back to them with a decision later. When I end it immediately they usually take it badly but these are times that I just can’t justify wasting any more time on them. The bad reactions run the normal gamut of bad human reactions: angry, sad, indifferent, humor, etc.

You must not have tried to hire a software engineer before. In a hiring cycle I encounter multiple "Senior Engineers" who can't write basic code. Fizzbuzz. Can't do it. Engineers should absolutely expect to write real code in an interview. It's preposterous to think that someone can claim to have 20 years experience writing code and then be offended to spend 20 minutes doing it in an interview.

I agree with this wholeheartedly. The article seems to be written by someone who has not yet learned the life lesson that "everything is a negotiation".

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.

I did address your question - I ask them to write code first. It may waste your time, but it saves time for my team. You can't code? Ok, the interview is over. Thanks for your time.

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'm a hiring manager and I start our technical interviews with coding problems. I have seen too many candidates who can't write code to ever be ok hiring someone who I haven't seen write code with their own hands.

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.

This is how I learned web development. Don't forget photoshopping the glossiest buttons possible. Not sure if that fad was before or after the grunge.

I agree with the sentiment wholeheartedly - It’s easy for technical people promoted to a people management role not to realize that their words now have a significantly greater affect on morale.

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.

It's a common phrase that means to drink enough alcohol to pass out. Presumably because otherwise sleep would be difficult to find, due to withdrawal symptoms.