3 ms·

This is great, but it would also be great if they accept other solutions than monolith Ruby on Rails on MySQL for their systems design interview rounds. I’ve i

This is great, but it would also be great if they accept other solutions than monolith Ruby on Rails on MySQL for their systems design interview rounds. I’ve interviewed twice and there seems to be a resistance from engineers both the times I argued that MySQL wasn’t the right approach. Sure, MySQL could possibly run any use case possible in the world if you throw enough engineering resources at it and highly optimize for that use case, but why do that if there is another engine specifically designed for your use case. The argument was “Shopify runs on MySQl and we can handle millions of queries… blah… blah…”.

pas 3y ago
what do they use to shard MySQL? are they using upstream? fb's fork? what storage engine? innodb? myrocks? at millions of q/s "mySQL" is a bit meaningless :D
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.
threeseed 3y ago
> but why do that if there is another engine specifically designed for your use case And what engine is that ? MySQL has been proven by Meta and numerous others to scale to ridiculous levels.
mrweasel 3y ago
> both the times I argued that MySQL wasn’t the right approach Looking at it holistically, MySQL is ALWAYS going to be the correct approach, if you already have an internal team of MySQL DBAs. Either your problems are small enough that it really doesn't matter if you use CSV files, MongoDB or MySQL or they are large enough and important enough that you want to stick with technology you know and understand, even if it requires 25% extra hardware. We did a project where we where looking into OpenStack, which was objectively the technological correct choice. Factoring in training, ramp up cost and hardware, it made more sense to just pay VMware. Without knowing you, I suspect the issue is in how you answer such questions, not whether or not that you're technically correct. I'd go with the route or presenting two options, the one you find to be "the right approach" and the one that fits into the company's current infrastructure. Coming mostly from the operation sides of things, I find that developers can be pretty clueless about the cost and complexity of operations. Often to the point where you wouldn't trust them to design anything unsupervised, because doing so would end up in an operations nightmare.
- 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.
  - mrweasel 3y ago
    Okay, then yes that's not normal. I'd never tell a candidate that they are just flat out wrong, that honestly seem unprofessional and kinda aggressive. I still might say something like "So I'd go with MySQL here myself, can you guide me through your reasoning for picking another database system or which circumstances that might cause you to go with MySQL as well?".
HatchedLake721 3y ago
Have you worked at Shopify before to know that MySQL is not the right approach? If not, how do you know it was wrong for them? FYI Uber migrated from Postgres to MySQL https://news.ycombinator.com/item?id=26283348 https://news.ycombinator.com/item?id=26283348

pas 3y ago

what do they use to shard MySQL? are they using upstream? fb's fork? what storage engine? innodb? myrocks? at millions of q/s "mySQL" is a bit meaningless :D

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.

threeseed 3y ago

> but why do that if there is another engine specifically designed for your use case And what engine is that ? MySQL has been proven by Meta and numerous others to scale to ridiculous levels.

mrweasel 3y ago

> both the times I argued that MySQL wasn’t the right approach Looking at it holistically, MySQL is ALWAYS going to be the correct approach, if you already have an internal team of MySQL DBAs. Either your problems are small enough that it really doesn't matter if you use CSV files, MongoDB or MySQL or they are large enough and important enough that you want to stick with technology you know and understand, even if it requires 25% extra hardware. We did a project where we where looking into OpenStack, which was objectively the technological correct choice. Factoring in training, ramp up cost and hardware, it made more sense to just pay VMware. Without knowing you, I suspect the issue is in how you answer such questions, not whether or not that you're technically correct. I'd go with the route or presenting two options, the one you find to be "the right approach" and the one that fits into the company's current infrastructure. Coming mostly from the operation sides of things, I find that developers can be pretty clueless about the cost and complexity of operations. Often to the point where you wouldn't trust them to design anything unsupervised, because doing so would end up in an operations nightmare.

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.
- mrweasel 3y ago
  Okay, then yes that's not normal. I'd never tell a candidate that they are just flat out wrong, that honestly seem unprofessional and kinda aggressive. I still might say something like "So I'd go with MySQL here myself, can you guide me through your reasoning for picking another database system or which circumstances that might cause you to go with MySQL as well?".

HatchedLake721 3y ago

Have you worked at Shopify before to know that MySQL is not the right approach? If not, how do you know it was wrong for them? FYI Uber migrated from Postgres to MySQL https://news.ycombinator.com/item?id=26283348 https://news.ycombinator.com/item?id=26283348