cntainer

Anyway, the interest from other teams is a good sign that your skills are still valued elsewhere. Moving on might be the best choice especially if you've been struggling with this for some time.

But if this is not the case then maybe your current skill set is not a good match to what is currently needed. I don't know, maybe someone else is already covering the things that you say you bring to the table, or the team's activity and goals are just a bad fit for you specifically.

> because I'm being forced to be something I'm not

Many managers see this as trying to help you grow, by getting you outside your comfort zone. In the end it's your choice if you want to play along or find a team/boss that makes better use of your contribution.

Inconsequential details can be fun in stories but they're not always appreciated, especially not in non-fiction.

It sounds "cool" when you say that the transitions between states can be handled by anyone on staff with this type of system but it would also feel impersonal if you have 4 different people handling each state: take order, pay, bring food, ask feedback.

And then there is the periodic performance review were we want to take a high-level look at changes in impact, outcomes, behavior over longer periods of time.

I think that shouldn't discredit the original concept though.

> My suggestion was to fire Jim but that process improvement was denied.

Funny, and maybe the best solution, given the scenario, but I guess my mind was set on more constructive criticism :)

I've seen examples where the objectives of the management and the teams are sufficiently aligned by the owners to create win-win situations.

Yes, it's not that typical, but it's possible.

If I have reasons to think the person will take it personally or the way it's written is too negative I refrain from sharing it raw and I prepare a tl;dr.

What's important is to extract the main points from the feedback.

> Assuming it actually is anonymous would be all downside and no upside for the employee.

Not sure I understand why.

EDIT: in most successful teams I know manager and team are in the same boat

What I noticed is that, when I have to review someone in my team and I gather feedback from other members of the team, I rarely get any critical input, even if the feedback is anonymous. Many avoid giving what they perceive as negative feedback even if it's framed as an opportunity to help the other person improve.

What happens is that people don't understand that most of these higher level solutions are very leaky abstractions, they aren't the silver bullet marketed in medium articles. Yes, they can save you a lot of time and headaches in specific scenarios but when you encounter one of the leaks it can take you weeks to get to the bottom of it.

If the teams doesn't understand what problems the tool is solving and if they have that problem then they might be just cargo-culting. An example of this is kubernetes. I know teams that used kubernetes just because everybody else is using it, they didn't actually need it for their monolithic java spring app. They think they avoided accidental complexity by using kubernetes but in fact they just added accidental complexity to their project. And then they add a new tool that makes it easier to manage the complexity of kubernetes, and so on.

Anyway, I'm probably just a rambling fool and I should appreciate that all this generating and shifting around of accidental complexity will actually mean future job safety for guys like us.

Sometimes TBD is the answer, sometimes you need something else.

What I did notice is that, with time, mature teams end up simplifying processes in order to reduce friction and increase output.

Of course you can do it like you said but that means longer feedback loops in general. If the team wants to integrate more often and reduce feedback loops then that model evolves.

I'll give you an example. In the team I mentioned in my top comment we were initially using a branching model with master, releases/, hotfixes/, dev, features/, which gradually evolved into master, dev, features/, which finally ended up as master, features/*. With the important mention that for small changes/fixes that needed to get deployed quickly nobody would bother with a branch they would just push to master.

This allowed us multiple production deploys per day per developer with no risk. That's why I said I don't get the point of the article, you can absolutely get those short feedback loops and continuous integration if you want it, just need to setup the process that way.

Of course the CI should always run them, but that should normally be as a confirmation/safeguard.

I've seen too many cases where the devs wouldn't even run the code locally. They would push it and expect the CI to do all the work. That's how you get shitty CI that is always broken.

I can have the normal flow, which takes minutes and runs all the tests and other stuff I might have on my pipeline (security, performance, etc). I use this for typical day to day work on features. I don't care if the deploy takes 50ms or 5 minutes.

I can have a fast-track for critical production patches. I skip all the main CI steps and just get my code quickly in production. If done right this takes seconds.

I didn't know about dark but I've seen this type of promise too many times, so I'm pretty sure there are many tradeoffs hidden under the nice shiny exterior. I can't know until I try it, but that kind of complexity doesn't all just disappear, i always has a cost even if it's out of sight.

Of course there are many pitfalls. Like with any tool it becomes trivial to use it wrong. Integrating less than once per day and deferring all testing and linting to the CI process is an anti-pattern and the issue is not the CI process but how the team chooses to use it.

For example I worked in a team of 10 and we were doing multiple production deploys per day. This was made possible by a great CI workflow. Everyone was running tests precommit and focusing on keeping the pipeline green. Yes I've seen the opposite as well, but that usually is a symptom of issues with the team not the general concept of CI.

Not saying that there isn't room for improvement but all the real-time collaboration features I used on low-code platforms feel like a step back.

Is this some kind of leadership? Or is it just the survival of the fittest? :)

Maybe the job interview is for Space X and they're working on some new system of mini-satellites-on-a-rope called Hyper-rope, or maybe google is trying to pivot their failed Loon project into some kind of air-born connectivity solution, and the rope is actually a very long fiber-optic cable.

Or the interview could be for an online eCommerce platform and the person being interviewed will most likely have to work in a huge heterogeneous codebase with all the important technical decisions already made.

otherwise the question doesn't make sense Well that is my point. I love these types of subjects, but when I'm having a beer with friends and we find a puzzle like this one and we try to take it as far as possible without going into fiction/bullshit territory.

So it could be useful to check/signal for culture fit, and in OP's case it actually worked like that OP: "We value people that love to get into this type of discussions/arguments" Interviewee: "Gosh, you guys bored me to death during the technical interview but it seems like we have similar tastes when it comes to theoretical puzzles so I'll give you another chance"

Nothing wrong with this though. It just proves that interviewing is a complex process and actual merit and success are highly subjective.

I guess this type of question might serve the purpose of finding like-minded people with similar interests (in your case geometry or puzzles) but it might alienate others.

I still fail to see how this is relevant for a technical interview, assuming that we're trying to hire a software engineer. Fun, but not relevant.

is this a technical puzzle/question? to me it reads like a middle school geometry question. it would be fun to discuss it with friends/colleagues but I wouldn't expect it during a software engineering interview

After reading it I feel like Gattaca barely scratched the surface. It was actually a pretty tame movie.

Some of the points made by the author are far scarier: gene editing startups with VC funding and sociopathic founders or amoral autocratic governments (think N.Korea, Russia, etc)

For example if I'm interviewing someone for a technical position and they're very attractive or even dressed/groomed excessively I'm making an effort to not hold that against them. I'm aware that I have a bias on this so I'm actively trying to have a balanced perspective during the interview.

At that point the panel makes the call based on a biased report and it thinks the decision is unbiased which is not true.

I think these 2 quotes by matz describe best ruby's philosophy.

> I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language

> Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.

I guess it never crossed my mind I could do the same when creating company policies and processes.

Every time you revisit a process you can keep it, kill it or amend it. It sounds pretty evolutionary to me.

What I liked is that adding some fail indicators as part of the policy actually gives ammunition to the people that want to change the policy for the better against people that are abusing the current form of the policy.