Some Thoughts on Interviewing

I recently had an interview where a development candidate didn't make a good impression.  It wasn't unique.  When I used to do department-level intern and new hire interviews for college grads, I'd get a number of bad interviews on a consistent basis.  Even after pre-interview winnowing from HR and development phone interviews.  Even if their parents were developers (if you want an unpleasant discussion, tell an architect they could have prepped their kid better).  Coupled with a request from a friend about product management skills, I got to thinking, what am I looking for when there's a software developer interview? SE...not SSE or lead.  What kind of tech and soft skills are useful to know about in general?

I know the short version I look far: ability and motivation.  And I need to see signs that you've acted intelligently on that ability and motivation (insight and problem solving). As one of our tech leaders used to say, we can teach you programming; we can't necessarily teach you how to learn or to want to learn. Longer version, if I'm interviewing a developer: OOP, SQL, REST, Quality.  Only somewhat longer version: variations on those that prove you can learn them or have a skill that's transferable. 

If you're an intern or in your first job, someone should probably be teaching you these things.  You don't always know to learn what you don't even know exists.  But you shouldn't expect them to structure it for you in such a way that you're fully prepared for future interviews and jobs.  Even in an internal bootcamp, there's at least a minimal focus on what fits within the bootcamp that readies you for the upcoming role/s at hand.  That said....you are the owner of your own career and there are skills you should cultivate, be able to spin a story around, and at the very least know that they exist and why.  I'll give you the advice my prof (and former Strib how-to-write author and prof for the MBA/Dev degree at the U of MN), Scott Edelstein gave me and a friend when we were younger developers...you should be able to talk about almost anything for 30 minutes.  I know, horrifying.  Even scarier in practice the first few times, particularly when he makes you do it in front of an audience of MBA-level participants.  And he didn't mean, "Tell me about Galapagos finches for 30 minutes," where it's obvious you're unlikely to have a PhD in geolocated bird species.  He meant "Tell me about Galapagos finches for 30 minutes" and you could deftly transition to and explain how Galapagos finches were tool users, and that in humans software development is a tool, and the software ecosystem has become one of specialties in security, cloud, ops, microservices, analytics, and a host of other tools.  Developers are finches.  Let me tell you what kind of finch I am...

 

In that spirit, one goal should always be a wide knowledge, with a few deeper areas you can transition to as needed.  The Pi-shaped and eventually E-shaped developer. Not T.  Not I.  And definitely not an "I" that fell over and can't get back up with no depth at all.  So what would I recommend as a broad source of knowledge?  This isn't comprehensive.  Not at all.  And it's subject to debate.  It should be.  And you can get by with less. Much.  There are a lot of jobs out there so an option usually finds you, although I'd posit that owning your interview allows you more leeway in picking a good fit.  And I'd hope you have topics of your own to leverage to demonstrate mastery and knowledge transfer.

 

Before we start, I offer one, overriding, piece of advice.  Talk to others.  More importantly, listen to others.  The wider your network, the more examples you'll have at your fingertips.  If someone mentions tech you don't know, ask for details and examples, and look it up.  Don't lose your mind and do a full day personal hackathon each time (although I'll admit to going a bit crazy with things I think are interesting when I find the time and you'll find examples on this blog), but touch it enough to speak to it with someone else and try to explain to your friend/acquaintance what you did.  They'll reveal more.  Everyone does something different.  Everyone uses different tools.  Embrace your inner finch and learn from the other finches.

• Language/s and IDEs
• Scripting: Python (or PERL, but c'mon, really, Python) – touch IDLE, maybe Turtle (teach it to a kid), and definitely Anaconda so you can use Jupyter notebooks, the line-by-line execution of a Python script.  You do not have to do anything like machine learning or a full Jupyter notebook - you can run a print("") statement on a cell and you'll understand the basics.
• Front End: React, Angular, Vue >> understand how these are templated/@-driven languages that differ from older languages. Bonus, do you know basic markup that some of these tools share even if you've never coded in one (mustache - aside: if you do the code security challenge, proper mustaching in Vue is the answer to at least one exercise), and some alternatives that have other uses.  E.g. something esoteric like Hugo as a framework for websites.
• Old School is still current.  It never goes away.  Be able to talk Java (Kotlin) or .NET.  Can you compare them and things you like/don't like about the languages and their IDEs?  For Java folks, Visual Studio Code is free and you can play with pretty much everything.
• Know that Android can generally be handled via Kotlin and IntelliJ, but that Apple products have a separate IDE for Swift even if you never want to touch it.
• Know Git > source control (Merge request, candidates). Bonus: be able to compare it to Microsoft Team Foundation/Services and that they both talk to Git so it's not an appreciable difference, only a philosophical one.
• Know that there are lots of online systems for playing around with the tools w/o installing an IDE. Say Fiddle a lot. Host something out there so you've done it.  You might feel foolish hosting a pizza to people ratio calculator, but it'll get you past the common bits of Fiddle.
• SQL
• Say this enough times that you can repeat it like someone hit your knee with a hammer, "SQL is fundamental. Even if you're not using a transactional database, the general concepts transfer to Node databases, NoSQL databases, cloud services, and more.  Almost all systems with a SQL-like structure, and even some without a SQL-like structure, support a SQL-like wrapper for ease of use."  Don't believe me?  Go use AWS billing from the API.  Here's an article from this week: https://www.zdnet.com/article/top-programming-language-for-data-science-python-still-rules-followed-by-sql/
• CRUD – create read update delete (Insert, delete, update, select from).  Be able to scribble a variation even if it's not semantically correct. 
• Understand the concept of a relational database and how to lay out tables (similar to object oriented programming – how to lay out the data).  Look up tables, joins, ids.  Complain a bit about using a profiler for query performance, caching of prepared statements, locks, running out of space, transactions, and your sincere dream that there's a DBA who takes care of the gory details for you.
• Install >> can you install a database or use a database in the cloud.  MySQL or PostGres (relational) and Elastic Search/Kibana (noSQL) are easy to install locally. It's a nice connect to talking about fast prototyping.
• Understand a noSQL database.  ElasticSearch is easy imo.  Dump your relational data into a noSQL database and wrap your head around where performance improves and where searching gets more difficult. Comes with the benefit of probably having to write a transform to get data from point A into JSON for point C (sometimes there's a point B in the middle).
• General persistence even if not SQL (writing to JSON, XML, or text files or really anywhere.  Pickling is a good word to know, but isn't on everyone's radar.  See that comment above about fast prototyping.)
• Bonus - learn some esoteric database uses like Node and when you'd use them.  Plenty of free cloud and local Node databases out there to play with.
• OOP
• There's a thing.  It has properties. It does things. It has other things. Pet store. Types of pets. Video store.  Categories of videos.  Wait...someone has to sell those things.  Who can sell what and has access to what. Card games with card objects. D&D games with character types and dice rolls. The rule here is to be able to turn anything you so much as look at into a decomposition of objects.  Manager, developers...sure.  Types of finches?  Coffee shop? D&D? Subclasses and inheritance.  So very much like SQL on the surface, but a bit different.  Be able to explain how to string OOP and SQL together conceptually. 
• The best advice here for an interview is that it isn't always whether you can break down a system conceptually accurately at first glance.  Rather, practice a few so you can transfer the details to any variation.  And so that during the interview you can do a quick swipe and then rather than get it right on the first pass (and you may want to get it just slightly wrong or rough on the first pass on purpose), go back and do little iterations of improvement/refinement.  You can fake deep thoughts if you're prepared in advance.
• REST
• Microservices and how to break down a huge legacy app into lots of smaller apps.  E.g. copies of data for each “part” so it’s not dependent on anyone else where you can avoid it.  Although sometimes “write” to a central location for everyone where it supports it.
• Go read the 10 commandments of microservices.  Don't be able to state them top to bottom, but know a few obvious ones.
• GQL – GraphQL >> not necessary, but turns very specific one-function calls into a more dynamic ask-for-anything-get-anything version.
• Remember what I said about SQL above?  GQL looks a lot like SQL in practice.  REST calls that return pointers to additional calls have that smell to them as well, just more disconnected in practice.

• Cloud
• AWS, Azure (Microsoft), Google – no one knows all three, usually only one.  Know the services for your cloud of choice.
• Don't know all the services, but know the big ones and then some: S3 storage, EC2 (machines in the cloud - retiring!), lambdas (standalone functions/scripts that scale), SNS (messaging), SQS (queuing), Cloudwatch (monitoring).  Go out and play with them.  Touching them gives you some anecdotes where you can say, "When I was experimenting, I found that it was difficult to understand..."
• If you can stomach it, find a good source for updates.  5 minutes every week or month can make you seem very well informed.
• Quality
• All the testing types: unit (dev), regression (quality), integration (UI) << and where they overlap.
• Unprompted, if given a coding exercise, break into extensive detail about how you'd write the various tests and what conditions you'd test for.
• Configuration >> what do you run into if you’re installing your own tools > can you get yourself unstuck.  Can you write a script to handle installs so you don’t have to remember the steps. Do you have some anecdotes you can pull out to prove you've done the time (local build horror stories are perfect and even better if you can talk about how you contributed to improvements).
• General
• Imposter syndrome - everyone feels like there's more than they can ever know.  They're right.  It's not a problem.  Be able to talk to how you get past feeling like there's too much to ever find the right thread to pull on to start.  Might be a peer group.  Might be picking the hardest piece first.  Work it into any of the tech discussions.
• Common sense - this is more straight forward to prove than you probably think.  My advice to developers in the past is show that you can apply a structured approach to a problem.  So if you're talking about an architecture you worked on, describe it at the 10,000' level, all the big pieces and where it connects to other systems.  Then take it down a level.  What was your team's piece of it all? How did you expose it? Where did you store your data? What were the tricky parts?  Then take it down a level.  What did you work on?  Classes or frameworks?  How did your piece fit in.  Take it down even further into some aspect of the code.  You can also go the other way....code, objects/services, team/feature, company/product.  Know how to do the same exercise with a bug or performance problem.  Where did you start, by reproducing the issue?  How did you do discovery.  What was your testing process.  What was the root cause? How did you verify the fix.  Pick an example with some chew to it (cross team, cross service, cross tech).
• Dealing with Management: managing up, down, sideways, indirect influence.
• Your role in relation to Ops (hint, your role has a strong relation to every other role and a certain amount of overlap and there's usually a tool such as New Relic to facilitate it).
• Timebounding yourself – when do you ask for help, take another approach, tell someone you’ll be late, or early, what do you go after first (most unknowns/hardest/most dependencies with others and other teams) to ensure you don’t have hold ups, when and do you decomposition and delegate.

These are useful, but less so in my opinion. But they'll add to your ability to have a conversation in an interview rather than a Q&A: 

• UXE (User Experience – the general idea of working with a layout/color/internationalization team to ensure you have a product users like.
• How to track it  and prove value (third party tools like Mixpanel, Kibana, etc.)
• How to use that tracking to make decisions in conjunction with product. 
• General rules >> don’t make users click too much, don’t leave things open all over the place, be transparent, etc. More product owner centric, but it goes toward showing you understand there are roles and that those roles are important and you should understand their concerns as stakeholders.
• Subject matter expertise – how you’d build something in the specific area, what’s the minimum viable item you can create and deliver that makes users happy, but gives you enough info about whether to do more.
• Business Intelligence / Data Warehousing
• Tools for playing with data to get observations – Power BI, Mixpanel, Datameer, Microstrategy, others.  But they’re all variations on Excel in some ways >> I have a lot of data, how do I get observations about it, particularly timeseries driven data.  Again...to be flippant...smells like SQL with a lot of visualization dropped on top.  This is probably a good place to state that knowing data, talking about data, and being able to show people the value in data makes you invaluable.
• Pillars >> AWS concept, but it holds true for lots of things, e.g. think about Quality, Cost, reliability, performance, scalability, usability, maintainability – e.g. the nonfunctional requirement or -ilities.  Be able to give example in the context of tech and architecture you've talked about previously.
• Agile
• Same as it always was, don’t plan too far ahead, break things down into little chunks (points) that fit w/in a sprint (2 week cycle usually, but can vary), worry about your capacity (developers x time less vacations and meetings) and delivery dates.  Communicate all those things all the time.  Always remember you're probably not communicating enough and you're probably not providing enough context and, when you are, you probably didn't break it out in the most consumable manner for all audiences.
• Big Agile – comes in a lot of flavors to align across teams: SAFe (4 sprints then 1 two week period of planning and innovation, repeat 10x/year, “streams” of multiple teams that work toward similar goals)
• Can you name some of your ceremonies (retro, planning, standup, I+P) and what you liked and didn't like and would improve if you could.  Can you talk about what makes a good standup (hint, it's not listing exactly what you did yesterday and what you're going to do today with no other context).
• Machine Learning
• Can be done locally, but there are cloud services as well., some that are turning common algo into black box exercises more suited to ML devs than data scientists.  For example:  AWS Personalize (recommendations), Forecast (forecasts), Fraud (fraud).  Sagemaker (Studio) is the full service in AWS where you can deploy algorithms and test and compare all the hyperparameters (math “constants”) and features (columns of data: birthdate, times clicked, country, et al).
• Have an idea of what you can do without a data scientist and when you need one.  Be able to articulate where it gets fuzzy and how to decide.
• Make sure you've communicated how all the skills above the fold (data knowledge, OOP, REST, SQL, et al) contribute before you launch into your love of machine learning algo.

Last advice.  Practice.  By yourself when you're explaining something to a friend or a team.  By talking to others who give interviews and doing interviews yourself when participation is an option.  Out loud where you can.  Putting voice to what you're going to say allows you to iterate on how you deliver and will directly translate to an interview so you're able to slow down and think about what you're going to say next and how it dovetails what was asked in a way that resonates with the interviewer, not whether you're going to say anything at all.