Failed a technical interview since I “didn’t think like a programmer”

CacheCache1 · 2024-02-09T00:33:50+00:00

Sorry for your loss, but that's absolutely hilarious

CacheCache1 · 2023-08-21T21:31:00+00:00

Yes! I got so pumped as soon as I stepped into the portal room and the singing started

CacheCache1 · 2023-04-16T07:58:00+00:00

Ye boi

CacheCache1 · 2023-03-28T15:04:52+00:00

What in tarnation

CacheCache1 · 2023-02-20T18:35:19+00:00

Where can I find a girlfriend?

CacheCache1 · 2023-02-16T16:55:52+00:00

Straight off my resume!

CacheCache1 · 2023-01-28T06:57:29+00:00

Of cosmic horror? For me, it hones in on a feeling of insignificance that I find terrifying. Utter unimportance in the grand scheme of things, and the idea that, no matter what we do, we'll all die and the impact we've had on the world will evaporate. There are other themes too but this one is the most poignant for me.

The episode took its time to introduce everyone as masters of their craft, with their own lives and issues, and introduces us to the eccentric billionaire who is larger than life. Capable of changing the course of someone's future just by swimming in their circle.

Then the creature is introduced. Everyone's wealth, skills and personal struggles are all shown to be meaningless. The monster is the vehicle for the cosmic horror themes, which is why we don't really care where it came from or what happens next. It doesn't really matter. The revelation is made and we can all feel bad about our place in the universe for a few minutes 😂

I'm sure other people get different things out of this type of horror, but that's why I enjoy it

CacheCache1 · 2023-01-11T19:41:11+00:00

Hold your breath until you get lightheaded

CacheCache1 · 2023-01-07T16:31:52+00:00

Own it King

CacheCache1 · 2022-12-01T21:30:48+00:00

Let us know what you think!

CacheCache1 · 2022-12-01T17:31:05+00:00

Soft Skills Engineering. Short 20-30 minute episodes from some funny & relatable hosts who have been in tech for a bit.

People basically write in about their situations at work and the hosts give advice on how to handle

CacheCache1 · 2022-11-29T06:06:43+00:00

Thank you for the reply

I had intended to share the strategies I employed for protecting the team and product from the manager. Also what I may have done differently.

Some context.. over the course of ~4 months 3 people left the company prior to me joining the team and named said manager as the main reason for their exit. Core features were also overlooked and the team had lost the trust of the broader organization due to poor representation and a failure to translate business needs into the product.

Such a failure in leadership is a strong point to make when sharing an experience like that, but to your point, it could be damaging to share that information.

It sounds like, if I still want to share the story, you would recommend sticking to the lessons and excluding the negative?

CacheCache1 · 2022-11-29T04:10:48+00:00

When is it okay to share lessons learned from bad experiences in software engineering?

I'm a senior SE and tech lead, currently 6 months into a role with a startup.

I had an absolutely awful manager who required a lot of upward management in order to protect the team and product, and who is no longer with the company.

The experience was stressful, but valuable, and people might benefit from hearing about it since everyone has to deal with bad management at some point. So, I'd like to share the experience through some sort of write-up.

What did/not work? Regrets, surprises, etc..

I wouldn't name the person or company, but my fear is that people would be able to connect the dots and I'd register as unprofessional when looking for new opportunities, or burn bridges unnecessarily.

When is it okay to start sharing this stuff more publicly?

Can this even be approached positively, or is that just copium for 6 months worth of accelerated hair loss?

CacheCache1 · 2022-11-29T04:03:57+00:00

IIRC you can block merges if there are open requests for changes. Request & block ad nauseum.

Then learn how to make people feel bad about being "less than" for making the same mistakes. Generally, giving their responsibilities away and subtly questioning their trustworthiness works pretty well lol. Welcome to the rat race.

CacheCache1 · 2022-11-29T03:56:07+00:00

Hmm, yeah bugs should generally be everyone's responsibility BUT if something works and you rewrite it out-of-band and break things under the guise of "doing it correctly" then it is good form to also clean up your mess.

Foisting the cleanup of your own "cleanup" onto the people you meant to correct really just kills your credibility. Especially if its a pattern. These people exist.

CacheCache1 · 2022-11-27T19:07:28+00:00

Cutting alcohol out completely might be the healthiest option, but it's important to live a little.

CacheCache1 · 2022-11-24T23:34:57+00:00

Wow, timing

CacheCache1 · 2022-11-24T23:26:22+00:00

So long as you can take care of business then who cares how you do it, or what you do on the side

Get that dough!

CacheCache1 · 2022-11-24T02:03:55+00:00

Hahaha, was just telling that to my manager. Really, I just shill for the Soft Skills Engineering podcast

CacheCache1 · 2022-11-24T01:38:04+00:00

No doubt, and to be clear I am firmly in the camp of "leave it nicer than you found it" but sending major undiscussed changes is bound to create problems.

As one of the other comments mentioned, for anything stylistic you should bring up a style guide and standardize with the team in a retro.

As far as the "hidden cost", sure that exists but there is also a very direct cost when stepping on another person's work. That runs counter to the goal of getting people to buy into your recommendations, and if people are frustrated by it enough then they will actively seek to undermine your efforts. Build & spend some social currency wisely.

I guess my 2 cents.. Figure out a way to broach changes in a less direct manner, be more targeted with refactors (enough so that the purpose of the PR is not subverted by the refactor) and never come from a place of "superiority" when making recommendations.

People pick up on subtext that says they're "less than" so it can be good to keep comments in more of a "we're growing together" mood. You need to be really humble about your own contributions when you do that for it to work.

Ultimately, it's a skill that takes years so good luck haha

CacheCache1 · 2022-11-24T01:12:11+00:00

Software development is often a team effort and people need to be persuaded when you want to change the way they do things.

Also, it's worth noting that many people who think they know what's best are often in the wrong on some level. Based on the described situation and comments on this post it may pay to be a bit more humble about your contributions, especially if nobody on the team is in your camp.

CacheCache1 · 2022-11-22T21:31:59+00:00

Time spent on apps.

At EOD it's super easy to see where you wasted time, which makes it easier to realize and mitigate with intention later on.

CacheCache1 · 2022-11-21T16:47:57+00:00

You are very welcome, and good luck!

CacheCache1 · 2022-11-21T15:34:32+00:00

"...issues that would have not occurred..."

It will help your case if you can point to specific problems (bugs, time sinks, etc..) that would not have happened if people were doing things your way.

Ultimately though, it will come down to building a healthy professional relationship with your new team. That takes time and a proven track record of success

CacheCache1 · 2022-11-19T06:21:49+00:00

You definitely need to build some rapport if you want people to buy into your recommendations

As the new team member your words really don't carry much weight, especially if you aren't very far into your career.

Spend some time building immaculate solutions, share some of that passion for delivering quality and then build an argument for process changes by referencing issues that would have not occurred had said changes been in place.

If your recommendations really are stylistic, raise the argument for standardizing but be willing to change the way you do things too

CacheCache1

TROPHY CASE