For an astronomer or physicist considering a transition into software engineering,
there are number of important technical preparations to consider.
First, computer science is not like physics or astronomy, where you can take some core principles like conservation of energy or Newton's 2nd and apply them to the entire world. Rather, CS is more like a toolbox. Each broad category of problem has a different set of applicable data structures and algorithms and they aren't necessarily useful outside of that domain. Hence, a large part of software engineering involves casting a given problem into one of these known domains and knowing the tools used to solve those sorts of problems.
This difference means that you have a greater likelihood of being blindsided by a question outside of your knowledge domains given the limited scope of most astronomy problems, but the good news is that the number of domains and tools is small enough that you can learn them in a relatively short amount of time if you're properly motivated (4-6 weeks). A useful starting point is this algorithms book. You'll also want to look at the data structures book by Sedgwick to familiarize yourself with the sort of data structures that don't usually come up in astronomy (heaps, priority queues, graphs, sets, etc.).
Beyond gaining knowledge of CS, the other important skill that you need to develop is an appreciation for writing good, clean code. This isn't something that most astronomers do, so it's entirely likely that you've never seen what good code looks like. There is no definitive source for what "good code" is, but a good starting point is to look at the Google coding style guides here:
One of the most important things to bear in mind when embarking on a software engineering job is that, unlike in academia, other people are going to need to be able to read and understand your code without talking to you personally. If the code isn't well written and commented, then it's a big drain on resources to basically force someone else to re-write your code in order to understand it. Coding style is going to show up most directly in the programming interview (discussed next) and bad coding style will be an obvious problem.
Finally, it is useful to also prepare for the interview itself. Pretty much any silicon valley software engineering interview is going to involve writing code on a board, so it's worth getting an idea of what sort of questions get asked in those situations. This book is a pretty good guide to the sorts of questions that get asked.
In general, interviewers are looking to check off a couple specific boxes: