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:

http://code.google.com/p/google-styleguide/

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:

1. Do you know the appropriate algorithm/data structure for a given problem (as discussed above) and can you implement code using them (depth vs. breadth searches, looping over the elements of a list, using a hashmap)?
2. Do you use good coding practices (descriptive variable names, passing variables into and out of functions properly, etc.)?
3. Do you have a firm grasp of object-oriented concepts ("is-a" vs. "has-a", when it is appropriate to use composition vs. inheritance, what are the trade-offs)?
4. Do you really know the languages you claim to on your resume (e.g., if you claim to know C++, can you work properly with pointers? if you know Java, what is the contract for an implementation of Iterator or List? for python, can you work with list comprehensions?)?
5. Can you calculate running time of the algorithm you've written (i.e., O(n), O(n^2), etc.) and find a better algorithm if the current one isn't viable?
6. Can you detect and account for corner cases in your implementation?