(image credit: Jake Hills)
In my career I have worked for 6 different companies, ranging from 4th hire at a startup to a senior developer at a Fortune 100 financial company. This leaves me an uncommon perspective on how a wide range of companies operate. Changing jobs so many times has given me a lot of experience interviewing, as well.
I’ve compiled a list of questions that I ask, wish I had asked, or plan to ask in the future. Each question has details about why I find that question valuable and what answers I expect. It ended up being a lot longer than I expected, so I’m splitting it up into several parts so it isn’t too overwhelming:
- The onboarding process, workplace, and team
- The development environment and emergency situations
- Personal growth (this one)
- Project management
Personal growth is the best investment. It compounds and expands on itself, opening up opportunities that weren’t available before. The best companies acknowledge this and take advantage of it by encouraging employees to learn and improve. All told, a company will receive more benefit by hiring a junior developer and turning them into a senior developer. The developer will form connections with teammates and learn details about the product and business that can only come with time.
To wax poetic for a moment, I like to think about programming in the grand scheme of things to keep it in perspective. “Programming” has only existed in a vaguely recognizable form for around 60 years (dating from FORTRAN’s introduction on punched cards in 1957). We’ve only written code, using a keyboard to write human-readable programming languages, for about 50 years. We’ve been creating mechanical devices for hundreds of years, designing buildings and bridges for thousands. As a discipline, we’ve learned how to make things that work, but are still learning how to make things that last. Given that position, we have to see how what we’ve written ages, and try out new ideas that might age better.
About what fraction of their time are developers given (implicitly or explicitly) freedom to explore or learn?
As developers, we sell our expertise. Exploration and learning are necessary to keep up with the rapid evolution of the tools we use. We must discover or learn new solutions to problems we’ve encountered, or to those we will encounter in the future. The tools we use, the languages we write, and the environments where we run code are always evolving.
Companies need us to be able to overcome challenges quickly. The best way to do that is to have a wide array of background knowledge to draw from. Learning by reading articles, experimenting within the codebase, or by starting new projects will help you in ways that aren’t immediately obvious. You have to be allowed to hone your skills, which will help keep you sharp and expand where you can help.
You’ll get the most honest answers to this question from developers you’ll be working with. Many times, developers aren’t granted explicit permission to explore. But they may find themselves with some degree of free time when taking into account delays introduced by external feedback cycles. As long as the results of their exploration have a chance to be included, this can be a workable situation.
Many employers would be happy to define success as hitting all your deadlines, and growth as shortening time between deadlines. Some companies will have mentorship programs in place, or will help you grow into a leadership role. Others may give you the freedom to work with adjacent teams, dabbling across the stack. They may have a collaborative environment that expose you to non-technical parts of development, like product or design.
Being able to define growth for yourself means knowing what you want, and doing some introspection from time to time. A great employer may give you all the support you could dream of, but you need to have goals for yourself!
Knowledge sharing between developers can be one of the most valuable parts of a job. Early in your career, frequent opportunities to learn from your coworkers’ experience can open your eyes to new ideas or tools. As you gain technical experience, lunch and learns can help you get used to public speaking. Giving technical talks at meetup groups or conferences will level up your career. Lunch and learns are a great way to practice in a familiar environment.
It’s great if somebody in the workplace organizes weekly or bimonthly lunch and learns, but another great answer is “not enough!” Organizing internal events like that can put you in touch with lots of great coworkers, and they’re a great learning experience. It will also get you a reputation as somebody who cares enough to get involved, which is less common than you might think.
It’s generally understood that one-on-ones are a necessary part of effective software management. They provide opportunities to talk about things that aren’t directly related to the immediate task at hand. Managers that don’t have one-on-ones miss the chance to catch workplace issues before they grow.
One-on-ones are often weekly, but having them too often can cause them to become routine or even disruptive. They should occur as needed, often enough that you know that you’ll have a chance to talk. I’m happy whenever they’re scheduled to occur, however. The details of scheduling can evolve as you work there longer.
It’s very easy for these one-on-one chats to turn into status updates, but that’s not what they should be used for. One-on-ones are too valuable an opportunity for direct contact with your manager for them to become routine updates.
They should be a chance to talk about your career growth and future opportunities. You should talk through any frustrations you’re experiencing and get to know each other better. You may not have many other opportunities to chat with your manager, so one-on-ones may be the best time to talk generally about the possibility of a raise after an accomplishment, or how you’re craving more responsibility.
Professional conferences are great opportunities to meet other developers, learn from speakers, and represent the business. Tickets, flights, and accommodations can be expensive, but it’s an opportunity to stay on the cutting edge of new development and bring back knowledge to share with the team.
For companies that pay, it’s not uncommon for it to be a reward for performance, or for there to be an expectation that you’ll share some of what you learned while there. It may also come with a responsibility to represent the company as a recruitment and brand-awareness tactic. I’d like if I could attend one conference a year without an expectation of presenting afterwards, but anything more than that will likely come with increased expectations of you.
Thanks for reading the third group of questions to ask your interviewer! Stay tuned for the final part, with questions about project management processes, in a few days. I’m on Twitter as @vcarl_, and I moderate Reactiflux, a chatroom for React developers (shoutout to the jobs-advice channel), and Nodeiflux, a chatroom for Node.JS developers. If you have any questions or suggestions, reach out!