bas_ta
Some questions I ask the interviewer: "What is currently your greatest challenge here at work?" "How long have you been working here?" "What do you like about this job?" "Is there a programming language/technology you enjoy working with and why?"
Some interviewers really like these questions and I think it's a nice way of learning stuff along the way even if you don't get the job. The "favorite programming language" questions gave me some pretty cool insights.
Also, I think it's better to ask specific questions. Rather than asking "how's your tipical day?", ask "how was yesterday at the office?" People tend to approximate, forget or just skip the details when answering generic questions. Of course, they can always lie, but a specific question might just be a better shot at getting the information you want. Also, questions about product development workflow can say a lot about the company. I once got the same answer to every single question about the company's internal processes and communication: "It depends". They had no clue what they were doing.
- drawing and lettering in Procreate (this is what I do most of the time, I've been practicing lettering on paper before and this is just so much more convenient)
- writing notes in Notes app (that way I can see them on my iPhone) or OneNote
- browsing Pinterest (the app works better than the web app I use on Safari in macOS)
- YouTube (much more convenient to carry around home than my MacBook Pro)
I don't use iPad for messaging, because I mostly use my iPhone and MacBook for that. I decided I don't need a keyboard for the iPad ATM, but maybe that'll change in the future.
I also miss my artistic side (I don't do web design as part of my job) and I would easily switch jobs if I could work for a more art-oriented or creative tech startup. The reason I often doubt whether software development is my true calling is because I don't like concentrating on just one thing in my life. Work-life balance could be better, for that matter :)
Right now, I work on a smaller project, we use similar workflow - we haven't implemented feature flags yet, but I suppose we will in the future (the project hasn't been released yet actually). I personally don't like developing an entire feature in a separate branch and then merging when it's all over, because code review becomes tedious (and ineffective) and the risk of merge conflicts increases. I would suggest you invest time in writing tests, so you can become better at it (if you aren't already) and it becomes a natural part of your development. Same goes for feature flags :) I was a junior when I started working like this (I still am, kind of) and it meant the world for me :)