3 ms·

I dislike MySQL as much as the next guy, but if you go into an interview-situation and argue that their technology choices are wrong then that is a big red flag

by vidarh 3y ago

I dislike MySQL as much as the next guy, but if you go into an interview-situation and argue that their technology choices are wrong then that is a big red flag not so much because you're wrong, because you might be 100% right, but because it is likely to indicate to interviewers that you will be difficult to work with, possibly pushing for changes they don't want to happen, and that you won't read social and political situations within the team well - for starters by arguing with an interviewer. It's fine to argue with interviewers, but the threshold where it indicates to both sides that you're probably wrong for that job is pretty low.

intelVISA 3y ago
As much as producing 'technically sound' decisions is paramount so is being able to work with other people, namely your boss whose decisions are always technically sound if asked. ;)
- vidarh 3y ago
  I think if asked it's fine to probe how much disagreement your boss has the stomach for. Sometimes you're being brought on because they know they need to fix things. But, yeah, don't start to rip apart technical decisions they appear wedded to from the first moment. Not least because a lot of the time as you say 'technically sound' decisions aren't everything. A whole lot of technical decisions we - me included - have very strong opinions about don't really have that much of a measurable effect on technical outcomes. I once, many years ago, had a conflict with someone reporting to me because I refused to entertain rewriting our entire frontend in Rails. This was just after Rails was released, and we had a lot of PHP code. We had PHP code because PHP frontend devs were "cheap" and plentiful, not because any of us liked PHP. I agreed with him about the preference for Ruby, and we used Ruby for other things (ironically all our Ruby use was on the backend), but he kept pushing on the basis of no insight into the relative market conditions for hiring at that time and on the basis of making assumptions about how "trivial" a rewrite was because he had no insight into why our then-current frontend had all of the capabilities it had which he'd chosen to ignore because he didn't know the roadmap. He went to my boss - the CEO and co-founder - and tried to get me fired. The CEO went to me and asked if I wanted to fire him instead. I didn't, but I did have a rather serious chat with said developer about our respective roles, and how it was about more than technical preferences, and how he might get a lot further if he actually tried to work more constructively with me instead of thinking he had the clout to get me fired. Said CEO hired me to run a development department again in my previous job, while he to my knowledge has never again worked with that developer - looking like a troublemaker to the wrong person can have long term effects.
darth_avocado 3y ago
I am not arguing their decision is wrong on their real world system. It is a system design interview with a hypothetical situation completely unrelated to their prod system, where I suggest a different db than MySQL. They are the ones arguing that my decision is wrong and MySQL is the correct choice, at which point you have to defend your choices.

by vidarh 3y ago

intelVISA 3y ago

As much as producing 'technically sound' decisions is paramount so is being able to work with other people, namely your boss whose decisions are always technically sound if asked. ;)

vidarh 3y ago
I think if asked it's fine to probe how much disagreement your boss has the stomach for. Sometimes you're being brought on because they know they need to fix things. But, yeah, don't start to rip apart technical decisions they appear wedded to from the first moment. Not least because a lot of the time as you say 'technically sound' decisions aren't everything. A whole lot of technical decisions we - me included - have very strong opinions about don't really have that much of a measurable effect on technical outcomes. I once, many years ago, had a conflict with someone reporting to me because I refused to entertain rewriting our entire frontend in Rails. This was just after Rails was released, and we had a lot of PHP code. We had PHP code because PHP frontend devs were "cheap" and plentiful, not because any of us liked PHP. I agreed with him about the preference for Ruby, and we used Ruby for other things (ironically all our Ruby use was on the backend), but he kept pushing on the basis of no insight into the relative market conditions for hiring at that time and on the basis of making assumptions about how "trivial" a rewrite was because he had no insight into why our then-current frontend had all of the capabilities it had which he'd chosen to ignore because he didn't know the roadmap. He went to my boss - the CEO and co-founder - and tried to get me fired. The CEO went to me and asked if I wanted to fire him instead. I didn't, but I did have a rather serious chat with said developer about our respective roles, and how it was about more than technical preferences, and how he might get a lot further if he actually tried to work more constructively with me instead of thinking he had the clout to get me fired. Said CEO hired me to run a development department again in my previous job, while he to my knowledge has never again worked with that developer - looking like a troublemaker to the wrong person can have long term effects.

darth_avocado 3y ago

I am not arguing their decision is wrong on their real world system. It is a system design interview with a hypothetical situation completely unrelated to their prod system, where I suggest a different db than MySQL. They are the ones arguing that my decision is wrong and MySQL is the correct choice, at which point you have to defend your choices.