Category Archives: Software Development

Interview Questions: Types of Coding and Algorithm Questions

Part of a continuing series on Interviews and Interview Questions.

Today, we’re going to look at types of coding and algorithm questions. As discussed before, these can be divided up into ‘Problem Solving’ and ‘Knowledge’ questions.

As mentioned before, ‘Knowledge’ questions are very close to ‘human glossary’ questions. ‘What is the Big-O order of QuickSort? Average case? Worst case?’.

But there are some questions which straddle the line between knowledge and problem solving, answers that few but an expert in that topic would be able to exactly recall, like ‘what exactly happens between when you type into your browser and the page appears?’, or ‘compare and contrast various sorting algorithms’.

For those questions, you have to be as widely read as possible, they tend to select for those who are more naturally inquisitive for things outside their specific area of expertise.

Now, for coding questions. There seem to be a few different types, which I’ll try to separate out by data structure[1]:

Arrays and Strings – Any data structure where any element is addressable in O(1) time, where elements are allocated together in memory.

Linked Lists, Stacks, and Queues – Data structures in linear form, where elements far away from the origin are O(N) difficult to access.

Trees – Data structures arranged in a tree form, with a clear root and directionality. Often sorted.

Graphs – Data structures with nodes and edges, where the edges can connect the nodes in arbitrary ways. Home to at least the plurality of the known NP-Complete problems. Note that Graph problems are a superset of the above.

Search and Optimization – Problems where you’re trying to find an optimal (or close to optimal) solution in a large multidimensional tensor or vector field. Many in this category are easily mappable to Graph Theory questions, but many are not, such as 3-D Protein Structure Prediction. Most interviews would likely not ask questions in this category, at least not very complex ones.

Machine Learning and Statistics – Somewhat related to Search and Optimization, problems dealing with how one trains a computer to solve a problem. Likely to become more and more important.

Hashes – Data structures where space is traded for speed. Generally assumed to have 0(1) insertion and retrieval

[1]Hat tip:

Interview Questions: Behavioural and Situational

Balancing factors. Persuading people.

Yesterday, I talked about three types of interview questions:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Technical’ questions ask ‘Solve this defined problem for me.’

Today, I want to talk about the ‘Behavioural’ and ‘Situational’ questions.

First, how are these questions similar?

Both of these are asking you to describe a solution to a problem, a problem from a surprisingly narrow set of options.

Two (or more) factors that you need to balance[1].

Helping people work together when they disagree[2].

The two factors might be technical, like how you would balance ‘Reliability’ and ‘Performance’, or they might be human, like Legal disagreeing with Marketing. Already, you can see these options blurring together. Really, these questions are really asking about how you balance things and make decisions.

The follow-up is often ‘So, once you made this decision, how did you implement it? How did you convince people that this was the correct route?’

Balancing factors. Persuading people.

So, how are these questions different?

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Behavioural’ questions ask you to tell a story about something you’ve done. You want to look at all the things you’ve done (especially everything you put on your resume), and think about what kinds of problems each of them were. What factors were you balancing there? How did you persuade people to work together and solve the problem?

An interviewer may ask you this question from a number of different directions. It’s up to you to fit one of your stories into the narrative question they’ve created (or to rephrase it such that your story fits).

‘Situational’ questions ask you how you would solve a hypothetical situation. An interviewer would present a situation with multiple factors to balance, where people disagree, and you would need to mediate, make a decision, get buy-in for your decision.

In this case, it again can be calling on your experience, but be careful that you’re actually trying to solve the problem presented, not a different problem that you’ve encountered before[3].

Summing up:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.
‘Situational’ questions ask ‘Given this situation, how would you solve it?’

In both of these:

Balance factors.
Persuade people.

To answer:

‘Behavioural’, fit a story from your past into the question.
‘Situational’, put yourself into their story, and tell them how you would resolve it.

Next time, we’ll look at the more ‘technical’ side of interviews. Stay tuned!

[1]If you didn’t need to balance between two things, you would just choose one of them, and really, no decision is required.

[2]If people are in agreement, what decision is required?

[3]Or something from your childhood, natch.

Mastery and Starting Anew

Earlier, I had written about the new flows and new structures which confront you whenever you change jobs or organizations.

Today, I was reading an article about feelings of ‘mastery’ (and actual ‘mastery’), and how they vanish when you change careers.[1]

Interestingly, it ended up becoming a story about transferable skills, and how you develop blind spots as you become entrenched in your 10-year or 20-year (or more) career.

For me, I discovered that I had learned how to look at a software project, see the flow, find the risks, and then work to route around and/or mitigate them. Perhaps more relevantly, I found this was an uncommon skill. Interestingly, being new and not knowing the project in as much detail probably helps me more easily see the bigger picture.

I haven’t noticed any new blind spots, but I’ll continue to watch. (I also try to ferret them out whenever I see them in myself, but I have no idea how well I do at that.)

In the article, the author says:

In radio, information is not your goal. Someone can talk and talk and talk, but unless they talk in the right way the tape is useless to you. If they are distracted, or overly theatrical, it won’t work. (That was the problem with the first oil guy we interviewed: he was always putting on a show.) The aim is to get them to relive all the emotions they felt at the time, which will translate in their voice. This can be achieved only if you are patient and open, and take the time to establish a real connection.

about how she learned to give people space in an interview, to help them stop ‘putting on a show’ and actually express their inner emotions.

For me, this quote best captures why I think changing things up can be such a powerful tool:

Then there’s the larger matter of how you practice. In “So Good They Can’t Ignore You,” author Cal Newport says that what makes ridiculously successful people so successful is they’re experts at practicing — they can push themselves to the exact limit of their skillset and thus expand their abilities day after day. If you’re not expanding yourself in such a fashion — called deliberate practice in the org psych lit — you’ll never be ridiculously successful.

[1]For those who have not heard of the ‘10,000 hour rule’, it’s from Malcom Gladwell’s book ‘Outliers’. There are also some who dispute the magnitude of the importance of the rule.

New Job, New Flows, New Structures

So you’re moving to a new organization. You know that what you will be doing will be different, you may even have read up on it.

But there are going to be all kinds of unexpected differences, and they’re likely going to come from the most unexpected directions.

Each organization has its own flows (I’m going to talk about software, as those are the flows I know best).

When an organization is writing software, there is generally some sort of version control-coding-testing-release pipeline. However, there are many different pieces of helper software for each of these steps.

There’s the flow of information as clients are using software. Information supplied by the clients, information supplied by your organization, and these all have to work together smoothly to solve whatever the client’s problem is.

The way that feedback from clients is turned into actionable items can be vastly different between organizations.

On the transition line between flow and structure, the way that teams are divided often reflect historical decisions made in antiquity, often the division of labour of the first few people writing the code for the first iteration of the product.

Information will be flowing through this system while the software is running, effectively handing off from team to team.

There will be structured and unstructured information flows in the organization. Many people are at their most effective when they receive all of their new information before it arrives through official channels.

Even the structured flow of information can be very different, for example in a very flat organization such as Valve.

So, be mindful, and watch for the different flows. You may be surprised at how different each organization is (or how similar).

What do Numerical Software Development Estimates Actually Mean?

What do numerical software development estimates actually mean?

What do they mean for you?

(I’m talking especially about team-based estimation, such as that in ‘planning poker‘, but I’m guessing whatever conclusions we may have would hold for other methodologies.)

I see the general objective here as coming up with a number for each task, and a number for how much your team can typically do in an amount of time, such that these numbers are reasonably fungible.

Traditionally, estimates would be given in ‘programmer days’, or ‘wall clock time’, depending on whether you had read ‘The Mythical Man-Month‘ or not[1].

More recently, there has been a back-and-forth between ‘amounts of time’ and some sort of dimensionless unit called ‘complexity points’.

Various teams that I had been a part of struggled with ‘complexity points’. In their strictest definition, something which was simple and repetitive would be worth few ‘complexity points’, even though it would take many hours of some attention or nursemaiding to finish the task.

Strict ‘amounts of time’ are no better, because each person does each task at a different rate.

We had the most success with ‘relative complexity’, or taking some small and large tasks, assigning them numbers, then rating each of the other tasks with respect to these goalposts.

Even this has its limitiations, though. Fundamentally, they question you’re asking when you’re deciding to put something into a sprint is ‘can we still accomplish everything if we include this?’. Because of limiting reagents (specific people who are bottlenecks for many tasks) and interdependence between tasks, this can be problematic. The standard way of getting around this is to insist that all tasks are independent and small.

This worked reasonably well, it’s just that sometimes you need to rewrite or refactor an entire application.

What are your experiences? How have you dealt with this question? How many points would it be worth to research and present on this topic?

(This post came out of a fb conversation with D about what estimation numbers mean, and have meant at various times.)

[1]One of the upshots of this is an observation made by someone at work (I think F) which was that Gantt Charts are excellent for deriving dependencies, but terrible for estimation.

New Divisions of Five Management Roles

Yesterday, we talked about five management roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

In a traditional corporate structure, these five roles are combined in one person (your boss).

However, there are many ways to divide these roles, and many reasons to do so (the simplest being that different people are good at different things).

Valve famously has an incredibly flat structure, where each person has a set of peers (the rest of the company) who handle performance management, and all of the rest of the roles are performed by each person themselves. As they say, occasionally teams will form with people splitting off into roles, but that’s all dynamically allocated by the people involved.

Your standard ‘Scrum‘ Agile shop will tend to put the ‘Performance Management’ and ‘Development Management’ into a ‘People Manager’. ‘Estimation’ is done by the team as a whole, the ‘Scrum Master’ or ‘Obstacle Remover’ is traditionally not the people manager, but is a separate role. The ‘Product Owner’ can be the ‘People Manager’, or someone else, sometimes an external product or project manager, but is generally not the same person as the ‘Scrum Master’.

I would argue that this tension between prioritization and removing obstacles is one of the reasons the system works better than many.

There seems to be a growing trend to separate Performance from Development[1], with some companies having separate reviews in different parts of the year for each of these. This can be especially helpful as many people are unlikely to be relaxed enough to think about how to take beneficial risks in the future when they’re tied up in knots about whether their boss wants to fire them.

I think it might make sense to push this to its logical conclusion, and have separate people for these separate roles in a company. The ‘Development’ role feels almost like a traditional HR thing, but I feel like to best serve employees, it would really need to be a separate department, called ’employee growth’ or something similar.

What do you think? What have you heard about how different organizations split these roles? How do you think they should be split?

[1]Development as in ‘where is your career going?’

Deadlines are a Clarity Crutch

I have a love/hate relationship with deadlines. At one point I said that the amount of work I do is proportional only to the number of deadlines I have, not proportional to anything else. (I think this is one of the reasons I favour daily 5-minute standups. They allow a daily reset of expectations, along with a deadline to work towards each day.)

So, deadlines proportional to accomplishment. Daily blogging something to show for your year something something etcetera[1]. But today I wanted to talk about the mental clarity that arrives as you’re approaching a deadline.

You have a task/deed to accomplish, you have a fixed time when it is due. As the time gets closer, the light cone[2] of possible ways to solve the problem shrinks. You push aside a large number of extraneous things[3], choose how solved you can get the problem in the time alloted, and get it done.

There’s the standard ‘good, fast, and cheap…pick two’. It feels like a lot of this clarity comes from having chosen the speed. As the time grows shorter, the number of ways you can now spend your mental focus budget on the task becomes manageable.

So, knowing this, how do we compensate? More frequent deadlines do actually seem to help, but that’s more of a forcing a solution, rather than relaxing into a solution.

What is it about the problem that is making you pause? Is your brain working on it in the background? (Does this mean the fallow time is necessary?) Are there parts you can hive off? Can you draw a large diagram? Can you put it in a spreadsheet or table?

Or perhaps the elephant in the room: If it is so difficult to find mental focus, what do you need to change about your environment?

[1]Until writing this I didn’t know that the ampersand ‘&’ was a ligature of ‘et’, and ‘etcetera’ was often written ‘&c.’

[2]Light Cones are also fascinating. I use them often in my mental model.

[3]In undergrad, we used to say that we enjoyed exam time, because we could push everything else away and focus, and not face opprobrium.

Five Management Roles

I was talking with my best friend earlier today, and we were comparing notes on some different management roles. Traditional hierarchical management theory[1] tends to have all of the management roles embodied in one person. This can be problematic, as very few people are good at all of the management roles.

This has led to a number of different techniques for dividing these roles among people. To start, we’ll talk about five of these roles, using Agile software development language, as that’s what I’m most familiar with:

Performance Manager (Worker Evaluation):

The ‘Performance Manager’ is probably the most traditional of the roles. When someone talks about their ‘boss’, it is generally the person who evaluates their performance, gives them performance reviews, and decides if they should get a bonus, a raise, or be fired[2].

Estimatrix (Estimator):

The ‘Estimatrix[3]’ is in charge of estimating the amount of effort required to perform a task or set of tasks. This role is often spread out over multiple people, even in traditional hierarchies.

Product Owner (Prioritization):

The ‘Product Owner’ is the other half of ‘traditional’ management. They are in charge of prioritization of the work being done, once it has been assigned to a team and estimated.

Scrum Master (Removing Obstacles):

The ‘Scrum Master’ (my favourite) is charged with removing obstacles. Once the team knows what it is working on, things will get in the way. Some of the obstacles are acute issues, associated with work being done, some of the obstacles are chronic issues, which are generally solved by trying to change habits, and many ‘restrospectives’.

(People) Development Manager (Development Conversations):

As a retention technique (and because it’s the right thing to do), many organizations spend time on development of their employees, helping them figure out what they want to do with their careers, and helping to find them ways to develop while doing their job.

Tomorrow, we’ll look at some ways these roles are remixed.

[1]It’s really more of a default.

[2]Like user stories, anytime your description includes the word ‘and’ or ‘or’, it means you can subdivide it further. That is left as an exercise to the reader, if they are so inclined.

[3]I really enjoy this suffix.

Sufficiently Complex Systems

“Any sufficiently complex computer system is indistinguishable from a biological system.” -Me

So, I like to joke that I find all computer languages equally difficult[1]. The interesting corollary to this is that this also seems to apply to complex systems in general. I approach a complex computer (or other) systems in the same way that I would approach a biological system:

1) Look at the visible behaviour/symptoms/phenotype of the system[2]
2) Assume that there are some number of internal processes in the system, each doing the job they ‘think’ is correct
3) Build a mental model which describes the visible behaviour
4) If debugging a problem, this should greatly narrow down where you investigate

Steps 2) and 3) above are where I think my school training (engineering and science) were the most useful. Our engineering program seemed to focus on the fundamentals and underlying systems, so that one would have a pretty good idea of what individual system components are capable of[3] (and some idea of what the system as a whole is capable of).

The systems I understood most intuitively[4] were chemical systems, probably because my dad and his dad were both chemical engineers. You have a huge number of molecules[5], each doing its own thing, and in aggregate, they exhibit complex behaviour. When you’re dealing with inorganic compounds, you can (most of the time), simulate them in bulk, but when you’re dealing with organic compounds, the complexity explodes and all kinds of strange boundary effects become important.

At this point, you need to switch abstraction levels, also something I remember from engineering, from the micro- level to a level of slightly or substantially more abstraction. At this point, having an intuition about biological systems becomes much more useful.

I’ll use an example to illustrate. At one point, a number of years ago, I and my team were trying to debug why throughput on a system seemed to be capped at a number below the theoretical maximum. Like any flow system, there must be a number of sequential steps that your data or fluid or what have you must flow through. After we built this mental model, it was a matter of looking at readouts and logs to find the graph that had an asymptotic curve showing at which step the system was maxing out. Then we had to fix it, but that’s another story.

[1]This is probably not strictly true. I remember finding Fortran 77 more difficult than usual, and Javascript mind-bendy.

[2]I use ‘behaviour/symptoms/phenotype’, because we might be debugging a problem, or we could just be trying to better understand the system.

[3]This could be why so much of technological advancement is characterized by the advancement in materials. You can only get so far by using a specific set of building blocks. At some point, you need better blocks.

[4]There is a larger article here about how it’s important to follow the things that love the most, whether this is in hobby form or if you’re lucky, work form. You will work harder at doing them better, more importantly, working harder at understanding yourself and removing your mental blocks, which will help you in all the other parts of your life.


Silos and Agile Project/Product Management

Earlier this week, I was talking with a friend of mine who had been recently promoted from Scrum Master/Product Owner[1] to being a project/product manager[2].

The issue they were experiencing was that they had a number of teams (think 10+), each of which was producing a good product, but the product as a whole was terrible. Also, the last time they tried to assemble a team to deal with this, it foundered because of intense opposition and inertia.

So, how do you deal with this, especially as a product manager in charge of the whole project, with no direct reports[3]?

We ended up almost working backwards to find a solution. When they were on a team, their sideways management[4] style was to learn how each of the people tick, and to help fit them with doing the work that was best for them.

My first idea was to have a working group with a member of each of the teams, where they would work together to make all the parts work better as a whole.

To me, this felt like it was iffy, and could easily be torpedoed by a small number of people obstructing it, or even not being engaged.

So, we came up with something simpler. In any project of this size, there must be some more obvious pain points, and some people who are more interested in collaborating to solve them. So, you just need to get a few people in a room together. Maybe only two. You find a few quick wins where they can quickly show the benefits of working together. Maybe the things they’re working on are even useful to their own teams.

To me, this is really using the Agile principles the way they’re supposed to be used. You find the most obvious problem, find a small number of people who are most interested in solving it, get some quick wins, and then spiral out from there.

We’ll see how well this ‘Agile from Below’ worked. Here’s hoping.

[1]This is how they described it, but didn’t go into detail, and I might have misheard it. If true, I’m not sure how this would work in practice, perhaps as a counterweight to supervisory management?

[2]They described it as one or both of these, and the role described above could be defined (as far as I know) as either. Thinking about it some more, it feels more like a product management role, which is how I decided to write it above.

[3]That you can direct. Ha!

[4]I use ‘sideways management’ to mean things positions like ‘Scrum master’, where your job is to remove blocks from people who don’t report to you.