Computer science as practiced in an industrial setting is usually applied computer science. Outputs are typically products that consist largely of software, but may also involve hardware, documentation, publications, and patents. That means that pure computer science is enriched with elements of software engineering (an engineering discipline) and programming (a craft). As with other crafts, one becomes more proficient by practice, especially when doing so with guidance from a more senior practitioner, e.g. via code review.
Typical discoveries when transitioning from theory to working code are "integers are not unbounded" and "floating-point arithmetic is not math", plus how many different ways one can commit off-by-one errors. An interesting account of one such exercise is given by R. Lesuisse, "Some lessons drawn from the history of the binary search algorithm", The Computer Journal, Vol. 26, No. 2, 1983, pp. 154-163 (online):
Then, the important errors found in the 26 published algorithms are pointed out, with an attempt at discussing why these errors were made.
One modern way to practice the craft of programming is to provide answers to questions posed on our companion site Stackoverflow, especially when they include concise self-contained code with a test scaffold. This is one way how I as a retired software engineer with a CS degree try too keep my skills fresh. I highly recommend lurking on the site for a few weeks prior to writing a first answer to develop a feel for what are considered good and poor answers in this specific context.
Interview questions in an industrial setting that involve programming often use simple algorithmic concepts and simple data structures such tables, arrays, linked lists, or bit manipulation of integers. They are designed to be solved in a relatively brief amount of time, and besides testing basic algorithmic understanding tend to check whether an interviewee demonstrates reasonable fluency in the language of implementation. A starter question may be a simple as an implementation of FizzBuzz, of which stories circulate that it trips up a fair number of candidates. If they are posed in an interactive setting, the questions may also be designed to assess how a candidate reacts to hints and guidance by the interviewer and allow on-the-fly adjustments to the degree of difficulty.
Interview question therefore frequently differ from questions posed in classical algorithm (text) books, and are covered by specialized publications such as Gayle Laakmann, Cracking the Coding Interview or Adnan Aziz and Amit Prakash, Algorithms for Interviews.
But working out answers to text book questions can help gain proficiency. When I studied CS in the 1980s, a starting point was provided by Niklaus Wirth's two books Systematic Programming and Algorithms + Data Structures = Programs, followed up by Aho, Hopcraft, Ullman The Design and Analysis of Computer Programs, David Gries The Science of Programming, and Jon Bentley's Programming Pearls. Of these, the books by Bentley and Wirth are closest to what one is likely to encounter in a programming interview. The book by Gries is mostly about constructing correct programs and probably the least helpful in the present context. However, all of them are showing their age four decades after first publication. My recommendation for a modern work would be Steven S. Skiena The Algorithm Design Manual, 2nd ed..