Skip to main content

How to interview your interviewer, Part 1

You past the gauntlet, having nailed every single question your interviewer threw at you, and now the interviewer asks if you have any questions for him or her. Still recovering from the ordeal, your mind draws a big blank. You blurt out something incoherent about benefits and their mission. Before you get yourself into this situation, just as with coding questions, it is helpful to be prepared to interview your interviewer. Though we never can be sure of the outcome of interview, organized interviewers will leave time for you to ask questions about the company, nature of the work, and their experience. It is important that you make the best of this opportunity to show your sincere interest and to learn more about the company and team to determine if it is a right fit and what to expect. Of course, given this is a team member or even the supervisor, you may have to take what they say with a grain of salt, but asking some well thought out questions can help tease out what the work and environment is really like.

Pace of Work

Release schedules vary from company to company. With so much of software moving to a service model with delivery on the web, release cycles have shortened dramatically for some companies. On the one extreme, you have companies which release multiple times a day and you will want to learn if they expect you to release multiple times a day once you settle it. The pace of releasing multiple times a day is quite different from a traditional annual release schedule. Sometimes you can learn about a company's release schedule from their website, but sometimes you have to ask. The matter is complicated some more if there are internal team dependencies. For example, a software team may be expected to pass their work to a QA team every few weeks.
Some teams have daily standup meetings where everyone needs to show up and report progress. On the other extreme, some teams rarely loop in their developers into meetings. There are pros and cons for both. You'll learn what you are both comfortable with eventually, but do note the differences in team cultures in terms of pace.

Deployment and Testing

How does a team deploy and test their work by itself and within the context of integration with the rest of the system? The point of this question is to figure out how much does the team and organization have its act together. In other words, how much of your time as a team member will be dedicated to putting out fires, especially preventable fires. Ideally, a team would have a good story for how software is tested, deployed, and serviced. If they have all their processes lined up, they could have a one step deploy. This is important because it will help make reproducing bugs and errors easier.

Customer Facing Interaction

Somebody is going to use the software your prospective team will produce, whether an actual customer of the company or some internal team. It is helpful to determine what are the parameters of the interaction. Does the team actively solicit feedback from the customer throughout the design and development process? Whether a particular degree and style of customer engagement for the team is a fit for your is an intensely personal matter. If you are happy coding all day long and don't want or need to interact with other people, then you probably would prefer teams that keep a lid on such interactions. If you are the type who is fired up by engaging with other people, then you could prefer the teams that dial it up a notch.

Learning and Opportunities to Present Your Work

By far, in my experience this is where the biggest difference of companies and teams lie. You want to probe a little to see if and how a team learns, not by formal training, but in terms of day to day work. Do team members give and request each other's code reviews? How are code reviews done? Does the company or team sponsor public facing events where team members can share something cool with the public? Some companies sponsor periodic hackathons for employees only or sometimes including the general public. Some companies invite external speakers or invite the public to hear team members' speak about select parts of their experience with technology. A team can arrange lunch and learns by its own to help spread awareness of internal tech developments (e.g., here's a cool new tool or library I'm learning or here's a great way I found to solve a problem) and give team members' the opportunity to both learn and gain visibility for their work. The last point is paramount. I cannot stress that a software engineer should take any and every opportunity to gain visibility for his or her work. This is how you build a personal brand and advance your career. You might have solved a critical problem for your company, but unless you speak about, present it, or write memos explaining it, few people will know. Some companies may go as far as sponsoring team members to go to conferences to give talks or write papers. These truly are golden opportunities to build a strong network and get other people familiar with your skills and achievements. Any of these kinds of opportunities where you are telling the world about something cool you did could be a major turning point in your career.


Popular posts from this blog

Complexity Analysis for Interviews, Part 1

This is part 1 of a two part series. Skip over to part 2 you'd like . For coding interviews, we are interested in gauging the asymptotic efficiency of algorithms both in terms of running time and space. The formal study of analysis of algorithms is called complexity theory, a rich field with fascinating and complicated math. For interviews, we only need a few basic concepts. Asymptotic efficiency is concerned with how the running time or memory requirements of an algorithm grows with the input size, so it is intimately concerned with how well algorithms scale to larger inputs. This is important in Computer Science and in practice because whereas some algorithms work well enough for small inputs of say < 10 inputs, the running time and space grows far faster than the input size and thus large inputs of say 10s to millions of inputs becomes impractical (usually meaning taking hours or even years of execution time). Consider sorting. Say for the sake of argument that sorting alg…

Top 5 Books for Language-Specific Interview Questions

Shrunk and White of Programming When you put down that you know a certain programming language or languages on your resume, you are setting certain expectations for the interviewer. I would strongly caution against putting down "expert" in a language unless you invented or are one of the language's maintainers. You are giving your interviewer the license to quiz you on programming language lore. There are a handful of concepts that are considered "standard" knowledge for each language which go broadly beyond syntax and general semantics. These concepts commonly involve major pitfalls in a given language and the idiomatic technique for negotiating these pitfalls and writing efficient and maintainable code. Note, although the concepts are considered idiomatic, you can seldom infer them from knowledge of syntax and semantics alone. The tricky part here is that most courses that teach a particular programming language do not cover these idiomatic techniques and eve…

Interview Gotchas

It's a challenge to outperform all the other candidates in a competitive tech job only, but there is hope. You can improve your performance with practice and watching out for these gotchas: Make absolutely sure you are solving the right problem: I ran into this the other day. It is entirely a communication issue. When doing an initial screen over the phone, this problem is compounded. For example, maybe an interviewee is hacking out a function that returns the k highest priced products when the interviewer is expecting the kth highest priced product. One can squander a lot of time due to these misunderstandings. A good interviewer will try to guide you back to the right path, but you can't expect this. Be sure to ask questions. Confirm that the input and output are exactly what you expect. Use examples.Don't ever give an interviewer the impression that you are avoiding writing real code. This is an impression thing. This is a coding interview so you should be expecting to…