First of all, read about NALSD. Not every company leans that hard into the scaling aspect but even if they don't, having it in the back of your head helps.
If they give you any numbers on scale at all, write them down. You will need them shortly. For online interviews, have something you can draw into. If something is provided in the invite, play around with it ahead of time to make sure you can draw boxes of different shapes and connect them with arrows. If not, have an empty canvas ready in your online drawing tool of choice.
Figure out the general shape of the problem. Is it a request-response type system (we want a website that does X), a stream type system (we get events and process them as they come), a batch type system (we have a pile of data and want to get through it)?
Clarify anything you are unsure about – this is about communication as much as system design. Listen for what they want you to do – ask them for every underspecified detail, or use your general knowledge to make reasonable assumptions? This also says something about how much you're supposed to think about product on the job.
Start sketching out the simplest possible system if that shape. A web app with a database, a queue with a worker, a map-reduce job. Where data is stored, write down a draft database schema. Use the numbers they gave you to estimate data sizes, request throughput, network bandwidth.
Can your simple design handle these? If not, start thinking about ways to split the work or the datasets. You can handwave in a scalable database where needed, but specify the sharding key you would use and why. In general, don't get too hung up on specific technologies – for each box in the diagram, name a possible example but focus on what properties it needs. You really don't need to get into a MySQL vs PostgreSQL fight here.
Extend the design to meet any additional needs as they are brought up. Some interviews give you the whole problem up front, mine builds it up slowly. Don't overdesign for things that aren't asked for unless you think they're always a necessity.
Be clear on what you handwave. You cannot possibly design everything in detail in an hour or so. Focus on the key points, be open about the points you disregard. For example, I mentioned network throughput because Google loves to ask about it, but with modern machines it's very rarely worth more consideration than multiplying up the throughput once, seeing it's megabytes per second or less, and saying "so that's not a problem".
Make sure to check in with the interviewer from time to time if they haven't said anything in a bit. This is usually meant to be an interactive session. Share your thoughts – what design you come up with is less important than how you thought about getting there. Use drawings and notes to illustrate. Redo some or all of the design as needed, but start simple and you won't have to backtrack much. Keep an eye on the time – it is totally fair to draw a box for a subsystem and roughly describe what it needs to do, then come back to it later if you can.
If you know of an existing system that solves the problem, mention it, and crib from its design as appropriate, but don't robotically draw out an prefabricated solution.
Be chill, be friendly, ask for input when you feel like it would help.
See also the System Design Primer for many many more resources.
Designing Data Intensive Applications is a great overview of the common base technologies and their tradeoffs.