FAQs For a Software Engineering Hiring Manager - Part 2 of 5: Companies & Interviews

Technical Interviews have evolved a lot since I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person, which I think is an important and welcome change.

Over the decade of interviewing hundreds of coders, I've also had the pleasure of working with various boot camps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout The questions I get asked.

With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager?While this is my perspective, it's based on years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you land your dream job. At worst, I hope they'll help you form your own ideas on how to approach your career.

In this part, I’ll focus on the questions I’ve received about different company types and interviews.

---

On Companies

1. Should I consider a start-up?
   Yes! Start-ups are extremely exciting places that offer a lot of valuable experience at the cost of additional challenges, risks, and demands. You get exposed to so much more than you would at a larger company, and you have a lot less red tape.
   
   Depending on how much risk you can stomach, find a start-up that has adequate funding so that you don't have to worry about the budget running dry. If the start-up is a B2B*(a company whose customer is other businesses)*, it's best if they already have some paying customers and an active sales pipeline *(I've worked at start-ups that had as few as 3 and as many as 1,000 - with a few that ranged in between.)*If the start-up's primary customer is an individual consumer, you'll want to at least be sure they have an established revenue stream and adequate funding.
   
   Start-ups come at all different stages - so assuming you can stomach the risk, the next thing to do is get a sense of what areas you'll participate in. Will you strictly be coding, or will you act as a Sales Engineer at any point? Will you also be doing QA? Responsible for infrastructure & DevOps? Get a sense of where they need you as a resource so you can determine whether it's for you.
   

   
   

2. What challenges exist in a small company, medium company, large company?
   It's wrong to think you're ever "safe" at one company or another. There are plenty of horror stories about companies of all sizes - and from people who are well skilled.
   
   Generally speaking, your roles and responsibilities are inversely proportional to the size of the company. The smaller it is, the more they'll have asked you to play a broader role. The larger it is, the more the role aligns directly to your title.
   
   The larger a company is the slower it moves. There's plenty more red tape and internal politics - but you also have the opportunity to work at a scale much larger than you would at a smaller company. Your contribution is, however, smaller. With a smaller company, you have a voice and say in more and have a closer connection to the company's mission and its customers.
   
   Benefits will also vary - but not in a predictable way. I've seen both large and small companies that give great benefits and have better work/life balance - it's a question of leadership.
   
   I recommend it all. You'll definitely find one that suits you more - and what you find suits you will also change with time.
   

   
   

3. Am I missing out on anything by being fully remote?
   Just about everyone out there has an opinion on in-person vs remote work. It's all a trade-off. Personally, I've found that remote work definitely creates more flexibility, but it also makes it more difficult to form stronger connections and build up your network*(which I'm big on.)*

   
   

   Being in-person allows you to collaborate and learn more organically. I've learned a lot from just hearing what others were struggling with or what they'd solved - and not when they formally present it to the group, but when they're in the thick of it.
   
   Especially when you're starting off, it's incredibly helpful to be immersed with other coders and collaborate with them. It's also likely that your good work is more likely to get noticed and praised.
   
   As with everything though - it's not for everyone, and especially if you've been hired as a remote employee, it's almost impossible.
   
   If you are remote (and don't have many positive experiences from being in person), I'd encourage you to be aware of what you could be missing out on and consciously make the effort to supplement those: get connected with your community, get a mentor, talk to the seniors on your team more regularly, participate in the technical chat rooms on your Slack or Teams.
   

   
   

4. Someone pitched me an idea and can't pay me but will be a reference to me. Should I pursue it?
   I hear about this a lot - and while it sounds like you're getting*"paid with exposure"*I'd treat it like you would any personal project. Provided you don't overcommit to where you can't work on your own projects, then pursue it. You may want to ask for an equity stake in whatever is being built - but what I definitely would encourage avoiding is doing free work for a brand-new company that is just getting started that isn't offering any equity. Yes, I've heard of this happening, and no, it didn't end well.
   

On Interviews

1. How should I prepare for my technical interview?
   There are so many great resources out there these days that not only help you refresh your technical skills but also help you improvehowyou interact with the interviewer. Many technical interviews are just as much about the coding as they are about the collaboration and discussion.
   
   A couple of books I strongly recommend checking out are:
   

   
   Both these books will give you tons of common questions and ideas for how to approach them. I wouldn't memorize these questions though - a lot of hiring managers come up with their own questions. It's all about the approach, but the questions make for good practice.
   
   But: practice. Practice by yourself, practice with your friends, and practice with your mentor. Practice using online resources. But also - practice with someone who isn't technical. Ask them to pick a coding question and ask you to do it. Then ask for their impressions. While they can't measure your technical response, they'll be great at providing you precise feedback on how you handled the collaborative/conversational aspect.

   
   

2. Are all interviews going to be whiteboard/virtual coding sessions?
   No. Sometimes you get a whiteboard, sometimes it's using an online tool, and sometimes it's a theoretical question that you need to talk through. And sometimes, the technical interview is very different.
   
   Companies are always exploring good ways to assess someone's technical ability - I'd recommend sticking to these basics:
   

   1. Practice coding questions relevant to your stack/role; Try all kinds of problems, but don't just focus on getting the answer. Focus on why the answer works. Generalize the solution: did you introduce something new, did you transform things, did you solve a simpler version first, etc. These are little tools for your toolbelt. If you run into a question you don't know, consider it from those angles.

   2. Practice thinking out loud. Make sure you understand the problem. Make sure you demonstrate understanding of the problem. Practice finding areas that could use clarity. Practice finding the edge cases and talking through them.
      

   3. Be comfortable with saying you don't know how to answer something, but don't stop there. You've encountered problems you couldn't answer before - what did you do? Talk through what you do when you run into a problem you've never seen before.
      

   4. Remember the technical interview is not just testing your technical abilities. They're also watching your soft skills.

      
      

      
      

3. How should I introduce myself at the beginning of an interview?
   Another question that's not been asked, but I needed to include. For years and years, I've started every interview the same way. I've told candidates I want to hear about them first - to get to know them and who they are, and to tell me about themselves, to shamelessly brag about themselves and their accomplishments without fear of judgment. I've had great responses, and I've had terrible responses.
   
   I'm always surprised when people struggle to talk about themselves. Some people are shy, some people are anxious, some people are very humble - they're not the ones I'm talking about. It's the people who say a lot while saying very little. They overshare in the wrong areas, under share in the right areas, and otherwise seem like they're generally unfamiliar with their own careers.
   
   My advice is to get good at summarizing your career into something you can say succinctly in no more than 2 minutes. But don't just summarize it by rattling off a timeline of events. Synthesize your story and build it around common themes. What is your career narrative? How are all those events connected so that they make sense? What are some unique qualitiesabout you thatyou want to highlight?
   
   For example...
   
   Interviewer: So, tell me about yourself...

   
   Interviewee: Sure - so I've been coding for 9 months now. I just completed a bootcamp, so I'm really only getting started out. But how I wound up at the bootcamp is pretty interesting. I've always been pretty technical. I built my first gaming PC when I was 11, and I'm the guy everyone calls when something on their computer or tablet isn't working right. I think it's because I really like to get to the root of issues and understand the technical reasons for why something is failing. Before the bootcamp, I was a team lead at Olive You Glad I Ordered Pizza. It may seem pretty far from being technical, but because we're a small pizzeria we didn't have an online ordering system. We only took phone orders - and I was feeling that we were less efficient than we needed to be. I started to Google some strategies and landed on Kanban and Lean principles, and I realized it could really help us out. So, while I implemented that with our team, I also started tumbling down the rabbit hole of Lean development and the Agile principles. Long story short, the bootcamp's program coordinator was ordering pizza and we got to talking - and I realized I had to start coding. I've loved it since. While I've not had any professional coding experience, I think I've been a coder all along.
   

   
   

4. What questions should I ask at the end of an interview?
   First, please, have a few questions. It's such a great opportunity to stand out and just to shake your head and say "No questions, I'm good..." is such a missed chance.
   
   You can ask about the role, challenges, why they're hiring for your role, was it a backfill or a new role, who are some of the people you'll be working with, the size of the team, some of the major challenges they team is struggling with. Ask about the product, ask about the tech stack, the methodologies being used, the size of the backlog, the structure/format of dev meetings, the opportunity to learn, mentorship opportunities, how work is prioritized, the QA process, the users.
   
   You can also ask the hiring manager about themselves: how often will you work together, what their approach is to management, one on one, growth, and what skills do they most value in employees.
   
   You can extend the same line of questions to the department or company leadership.
   
   You can ask about Covid: How did you all adapt in the early days of Covid? What were some of the challenges? How have you worked through them? How did you maintain a baseline of productivity with people being remote? Has Covid shifted any priorities for the product/business/team?
   
   There's so much opportunity to ask exciting questions - a bonus if you can come up with a question based on something that was discussed during the interview. The more relevant your question is, the better.
   
   Finally, remember there's such thing as ; a bias that favors recent events over historic ones. In other words, how you end your interview can be more important than how you started it.

   
   

---

It's worth noting, all these responses are my own subjective views that I've generalized across small and large companies. They reflect my personal style, but I'll also happily submit they're not 100% right either. It's what's worked for me - but I love getting input and thoughts from others.

Have any questions I haven't answered?  and send them to me!

Also Published .