Remember that you are also interviewing them. They won’t expect you to know all the answers, but will want someone that they can work with. If you can, answer questions with the STAR method (situation, task, approach, result), but don’t waffle. You can use one piece of experience in a variety of ways: teamwork, research, urgent deadline etc.

It’s ok to say that you are nervous, they should try to put you at ease.

You may be asked ‘trick questions’, these are not usually to to you up but to see how you work an unknown problem. There is no right answer. Not knowing stuff is ok. Not being able to think up a plan is less so.

Remember whatever the outcome, this is really useful experience. See if you can get a site tour, ask about the tech used… You can then add this to your knowledge for later. In my experience, industry is frequently several years ahead of academia so you get a good chance to understand the real world.

It’s like everything, practice slowly, get good form wired in, then when you write fast for exams your writing will be worse than normal, but still legible.

Practice writing slowly and with good form. Write regularly, give yourself practice pieces. At uni you will be writing FAST, so it’ll get worse if you don’t keep disciplined.

Alternatively, learn to touch type, and type any work you need to hand in. - if your handwriting is so bad, you may want to make your notes legible to yourself for revision.

I’ve avoided the conversation entirely. Ever since the pandemic I’ve done my own hair with clippers. Made a good enough job of it, even if I’ve sometimes needed to do a small adjustment the next day.

For a simple style it’s not that difficult if you take your time.

Thought I did so well on my phone. It kept auto correcting code to coffee. Maybe it was telling me something.

Yes, plan for it!

All the other comments are great advice. As an ex chemist who does quite a bit of code I’ll add:

Do you want code that works, or code that works?! It’s reasonably easy to knock out ugly code that only works once, and that can be just what you need. It takes a little more effort however to make it robust. Think about how it can fail and trap the failures. If you’re sharing code with others, this is even more important a people do ‘interesting’ things.

There’s a lot of temporary code that’s had a very long life in production, this has technical debt… Is it documented? Is it stable? Is it secure? Ideally it should be

Code examples on the first page of Google tend to work ok, but are not generally secure, e.g doing SQL queries instead of using prepared statements. Doesn’t take much extra effort to do it properly and gives you peace of mind. We create sboms for our code now so we can easily check if a component has gained a vulnerability. Doesn’t mean our code is good, but it helps. You don’t really want to be the person who’s code helped let an attacker in.

Any code you write, especially stuff you share will give you a support and maintenance task long term. Pirate for it!

Code sometimes just stops working. - at least I’m my experience. Sacrifice something to the gods and all will be fine.

Finally, you probably know more than you think. You’ve plenty of experience. Most of the time I can do what I need without e.g. classes, but sometimes I’ll intentionally use a technique in a project just to learn it. I can’t learn stuff if I don’t have a use for it.

I’m still learning, so if I’ve got any part of the above wrong, please help me out.