Team Communication 101 – Interview Answers

Hello World,

Occasionally I get asked questions in an interview or from students or some other place.  When those questions come in written form, I like to reply to them on my blog for the rest of the world to be able to see.  Today’s theme is about communication and communication technologies in a software engineering ecosystem.  One item of interest is that our teams are constantly becoming multi-cultural, multi-timezone, more distributed and more diverse.  This has its benefits, but from a communications perspective, it does have its challenges as well.

What is the most prevalent tool used among programming staff to communicate?

This changes shop to shop based more likely on personal preference or sales packages than honestly anything else.  But here are common ones.

  1. Their Persons -> I think we over emphasize tools in this age of technology.  Tools for this, tools for that.  The best meetings I have are usually in person.  70% of what people react to is appearance, 20% is how you sound and 10% is what you are actually saying.  This comedic example really drives this home.  Ask yourself, why was the emoji invented?
  2. Outlook + Skype for Business -> My team would literally disintegrate without this tool combo.  The following problems are solved: email, communication organization, calendar, calendar sharing, time zones, locating open meeting times, org chart, video chat, text chat, document sharing, conference calls, external communications, external calendar insights, calendar color coding, notifications, search and many more.
  3. Slack -> I see this more on small team communication as just a chat channel for interested parties.  It has ability for inline snippets which is nice and history, however it does not solve the key problems.

How does a programmer answer technical questions or concerns about developing applications to employees that aren’t programmers?

This is a very nuanced question.  It really depends on who you are talking to and what each parties goals are.

If I’m talking to a sales person who is going to go sell millions of units to a primarily developer audience, then I will walk that guy through everything I think he needs to know and spend a few days on it.

If I’m talking to a marketing person who wants to do advertising for the general public on a consumer device, then I use high level language, such as “Artificial Intelligence” as opposed to “Convolutional Recurrent Neural Networks”.  Instead of “Reinforcement Learning”, I might use verbiage like “Self Learning Machine”.

If I’m speaking to an executive on why we need a $200,000 server and its going to cost $5,000/month to run it, I explain from an R.O.I. perspective.  This computer will allow us to run more advanced algorithms faster and therefor beat our competitors who are creeping into our cognitive market.  If we do not do this, we anticipate further creep into those markets increasing the cost of customer acquisition in those markets.  By my numbers the increased cost is 5x the cost to run the server and we will have the ability to regain competitive advantage in those markets.

The key here is knowing who you are speaking to, where they sit in relation to you and each parties goals.  If you can understand that and communicate appropriately to achieve mutual satisfaction, you will do well.

What is the preferred method for transferring large files that are meant to be sections of a completed application?

You should never be doing this.  It should be source controlled with the rest of the application and part of a continuous build/test/deploy process.  What the heck are you thinking?  I will kick developers out of my shop for proposing an idea like this.

What is expected in writing comments in bodies of algorithms for other programmers to follow along with what you are doing?

Not too often do we bother with comments mid algorithm.  If you break your code down properly following single responsibility, the explanation of the code goes as a header to the function.  Most seasoned devs can pick apart code fairly quickly, so its usually a waste of time and the algorithm changes over time, which yields issues inside the body of the function as the explanation might not match the code, which could be a worse problem.  I expect every dev on my team to be able to read code like they read a book.

How do you explain your programming work to your superiors who may or may not understand it?

First, superiors are usually significantly more intelligent than folks give them credit for.  Particularly these days where top sales staff and even CEOs are ex-developers.  That said, superiors are usually interested in one thing and one thing only; that is results.  I give them a timeline, a budget and anticipated results.  All they really need to understand is high level architecture, components, investment areas and what the result of that is.  If you receive inquiry beyond this into the depths of what you are doing, you have failed at establishing your own credibility and a trust relationship with your superiors or  have yet to build enough credibility and trust to have discussions like this.

How does newer technology improve your communication?

We use the latest Skype for Business + Outlook + Active Directory and other tools it integrates with such as CRM.  Because we take the one vendor approach the integration between all of our tools is very easy as is permissions handling.  This surfaces in reduced time in tool management and increased time focusing on core business.  We simply just upgrade our tooling along the same stack as it becomes available.  If you wait too long, you end up with a more complex upgrade cycle and can fall behind.

Do you switch to newer versions of the communication technology to use once it becomes available, or do you stick with what we have until you’re sure it will benefit your company?

If its in the same stack, we upgrade as soon as its stable.  You should get into this flow and rhythm.  Not only does this discipline ensure you have the latest and greatest, but it sets an example for your customers and builds your credibility as professional.

Do newer versions of programming and compiling tools interfere with code that is written in a previous version? When is a good time to update?

Usually there are at least a few issues.  This is dependent on what you are programming in, what your target is, how much configuration you do, how good your developers are, how much technical debt you already have among many other things.  A good time to update really gets back to just working it into your development cycle.  Assume 1 sprint, and line it up against the other things you need to work on.  Failure to update incurs additional technical debt, which will rack up, and eventually you need to clear it or become blocked.  When to do this is very dependent on the current circumstances.

What changes or additional training is issued to work with newer hardware that utilizes the software you are writing for?

This is a poorly worded question, but I’ll give a stab at it.  I’m assuming the interviewer means: “What training do you expect to take when the hardware your software runs on is upgraded and what are anticipated changes?”.  Again, this is very dependent on what you are building and where it is going.  If I’m targeting Microsoft Azure for example, the hardware gets flipped on me all the time and I don’t even know it.  Hardware, firmware, fabric and other updates get rolled and my applications don’t flinch.  If I’m targeting something say NVidia GPUs, and new ones roll out, well my code usually still runs perfect on the new ones, but there are new features I can take advantage of to increase performance, run larger loads etc.  If its a complete flip from say a Cuda based device to FPGA, well then we have a ton of learning and training to do as a full stack change just happened.  9 times out of 10 though in today’s world, a hardware change is not going to change anything; of course unless your developers wrote bad code.

Summary

Well this was a long one.  I think there are a few key take aways.

  1. Communication should begin with understanding communication and personal relationships, not tools.  If you fail at establishing credibility, trust and a solid foundational relationship, all the tools in the world will not save you.  Tools really are here to simplify the adherence to these unspoken human interaction rules.  We as humans still need to know and understand those rules and how those rules change in accordance to the huge variety of individuals we now work with in this global economy.
  2. Upgrading things is not scary.  Just keep doing it.  Its like cleaning your room.  If you never clean your room, when you finally get around to it, you are going to find dead rats and nasty things.  If you keep your room clean all the time, its great, you can be more effective and productive.  Just keep your stuff clean and up to date.
  3. Technical Communication.  Folks are usually a lot smarter than we give them credit for.  From newbie developers to higher level executives, they are usually fairly competent if you allow them to be so.  Assuming those you communicate with are incapable of understanding your message is a poor attitude, you should realize that they are highly capable beings but perhaps focused in a different area than you are.  By realizing this, you begin a new type of communication style around enablement.  This spans from the comments you write in your code to the way you explain to your boss that reworking your AI algorithms into new ones will increase revenue and decrease costs while putting out competitors.

Leave a Reply

Your email address will not be published. Required fields are marked *