RSS Feed

Latest Entries

First time here?


A Realistic HackerRank Developer Interview Question List



When I was looking for a new job it always puzzled me that companies looking for senior developers, team leaders, architects and Dev managers were asking me to fill out silly hackerrank style questions such as :

* How to effectively measure the diameter of a tree

* How to compute Prime factorials

* If two eggs are all you have and you have 100 story building...

Unless you are specifically looking for an algorithm related developers, can we stop this lunacy?

This is not the stuff 99.9% of developer and tech leads have to deal with in real life. Here are some questions that will tell you if that person can really help in your team. Unfortunately it's hard to "measure" the answers. But I'll try.



If I were building a "hackerrank" website:


1. You have a team of 12 people spread out across three different locations. It takes an hour to get to one location (A) from your house. 90 minutes (without traffic) to get to the second location (B) , and 3 hours (no traffic) to get to the third location (C). Each person in the team seems to be over committed: they are behind on things they haven't even started yet.

The people in site A have knowledge abouttechnology T and T2. The peoplein site B have 1 person who knows about technology T and all the rest know about a technology T1. The people in site C know about technology T but not about T1. 

There are 7 people in site A, 6 people in site B and 2 people in site C.

The project manager for the highest priority project is hounding you because a project with technology T is 2 months late. However, all the people who know  technology T are already busy working on solving this and everyone else can't help you from your group.

What is likely the root cause? what can you?

A. Root is cause is the project is demanding things that are unreasonable. Plow onwards and hope for the best.

B. Root cause is project is demanding things that are unreasonable. Tell that to the project leader and your manager. 

C. Root cause is there isn't enough cross training. Plow through and do some cross training when the fire is out.

D. Root is cause id there isn't enough cross training. Stop all other work by your group and do cross training so people can help the folks in site A get the job done.

E. A and D

F. B and D

G. Other (open ended)



2. The project manager is complaining about the amount of of bugs found in production, and you know that your code quality sucks (you just joined and took a look at the code). What questions must you be able to answer before starting to fix this?

A.  What's our deadline(s)?

B.  What other commitments do we have?

C. Why are people writing bad code?

D. Is bad code really the problem?

E. What's our code coverage?

F. B C and D

G. A D and D

H. B D and E

I. all of the bove

J. none of the above

K. Other (open ended)


3. How would you measure your success as a tech leader?


A. The quality of the code my people write

B. Our code works in production

C Our code works in production and is maintainable

D We live up to the targets provided

E It's fun to work in our team

F The project manager likes our outputs

G I am not a bottleneck for making decisions



4. You have a developer that no one wants to interact with because they are very aggressive. What do you do?

A. Fire them. No asshole rule applies.

B. Coach them for a few months and get them off the team if it doesn't work out.

C. Have 1-1 and tell them to behave better.

D. Ask the people that complained to talk to your developer about his/her behavior

E. other (open ended)



5. A developer sends you an email showing that he's being requested by various stakeholders to work on a project that is not top priority. What do you do?


A. Send a stern email to the stakeholders with CC to my manager

B. Ask developer to send email to stakeholders with CC to me, with the promise I will back him/her up with what he thinks is the right thing to do

C. Tell developer to find a way to support this in spite of time pressure

D. Tell developer to ignore that email

E. Find another developer to support this activity. If none are available use A or B

F. Find another developer to support this activity. If none are available use C or D



6. Which of the following design patterns would make it harder for you to follow SOLID design rules? Select all that apply.

A. Singleton

B. Chain Of Responsibility

C Composite

D Decorator

E (more pattern names here)


7. Write down as many uses for a blanket that you can think of within the next 60 seconds. Think out of the box.



Can you guess why I'm asking the last one?




I want to see how creative the person is. Less creative people might come up with 5 or 10. The really creative ones might find up to 20 in a minute. If you give them 5 minutes you might get 50 uses or more. Less creative folks might give up after 10 or less.


When I Want to Give Up

When I'm at work and I suddenly feel like everything sucks and the world can just burn as far as I'm concerned, I take a look at this picture I found on the web a while ago, printed it and mounted it on my door:

It helps me take an inward look and try to identify what exactly is it that I currently feel. When I can name the feeling(s) it generally becomes less of a blocking issue. Like a shadow under the bed that you shine a light on.

I go through each one, asking myself:

"Do I feel like this now? Why?" .

Maybe I just left a meeting where I felt the rug was swept under my feet.

"How do I feel about that now? does it fit one of these things? Oh, I think I'm just expecting fast results." Then I can plan my next steps. 

This also reminds me that everyone feels these things from time to time. They are universal.  

Some of them are temporary shortsighted views on a long running path (expecting fast results..).Some of them are just something to be acknowledged and dealt with (overworked).

These things are also called "Gumption Traps" (Thanks, John Crowe) and I find them quite helpful.


Dangers of Survival Mode

I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that create chaos).

The goal of that exercise, where I play the customer, is to win by delivering to the customer what they expect to be delivered.

This does not mean that what was initially discussed as the requested building is what will be delivered. Team leaders are expected to negotiate and try to change their surrounding "reality" by discussing and explaining to the customer what they can and cannot deliver, and negotiate on time, feature scope, or amount of people they can work with to achieve the task.

It's always a very interesting experiment to see how people handle the stress associated with Survival mode.

Survival mode is that awful place where you are over committed and have no time to learn, so you are left only "reacting"; fixing fires, cutting corners, and never really proud of your work.

Many times it is a spiral, since lack of time to do things "right" leads to much more messy fixes, and slower release cycles, since everyone has very little confidence in whatever it is they are building.

So, how do people, even leaders with experience, react under this situation? In a very human way. The most common reactions are:

  • Give up almost immediately. As a customer, I tell them they have x minutes to finish, and not even a hint of trying to negotiate, or saying that this time frame doesn't fit the work. Many accept this time limit as a given even without asking simple things about the scope such as "how big is this LEGO bridge supposed to be" or "which color does it need to be?"
  • Forget to show demos along the way so they can see if they are doing the right thing. Then failure ensues as what I requested and envisioned in my head is very different that what they envisioned.
  • During the work, fail to notice any team bottlenecks. For example people with disruptive behavior.
  • If helping out as part of the team, forget to look at the big picture, such as how much time is left, showing demos, or are there any inherent problems in the way of work.

As a result, many teams fails to give what the customer expected in the time negotiated. And many teams fail to even negotiate a reasonable amount of time, or even notice they are building the wrong thing in time, or at all.

You might say "It's just LEGO." But lots of the same symptoms arise in real life software development (and other types of teams).How many projects have you been to where, on the first day of the project, you knew it was going go fail?

There is a certain release in knowing something like this. It helps you shed any responsibility to the well being of a project, and you feel less accountable.

Here's the problem with that approach, though. Many team leaders are "thrown" into a dire situation, thinking that the whole situation is "a given". A fact of life that cannot be changed. Doomed project? Guess we're screwed then. Nothing left to do but twiddle your thumbs.

No. You are paid to change the situation you're in, and do good professional work. If that's not what you are paid to do, I think you should leave your job. Most software team leaders have options if they started looking, and there are plenty of companies out there looking for people who want to be proactive bout making things right.

So, what are those things that people think are "given" that aren't really most of the time?

  • The time you have to finish the project is not really a given. It is a direct factor of the estimates that you give at the beginning, and as time progresses you can and should ask for more time/ change of scope or adding team members (although that might make the project even later in some cases)
  • The low quality is not a given. You can change the low quality (at least for new work) by demanding it from your team. Don't have time? make time. Re-estimate. Is that scary to do? Guess what, part of being a leader is doing things that are uncomfortable.
  • People's behavior in your team is not a given. You can influence and help change unproductive behavior. Sometimes leaders avoid directly talking to people in their team about unproductive (problematic) behavior. Part of the work. You don't have to be an asshole about it, but you can be direct without being hurtful. People need to know that there are consequences for problematic behavior. You can even ask people to stop contributing, or ask for people to be replaced. Though usually you should try and work on the problem instead of getting rid of people. It will do good for you as well to try and jump into such a challenge, and you will learn a lot from it.

Ask Royo #1 - Team Leadership and Influence Edition

A new experiment I'm making. Twieet me questions about anything relating to leadership or software dev, and I'll try to answer as best I can if I have any knowledge in the area.

In this episode I answer the following questions:


  • How do you show the benefits of test first vs. test last?
  • When jobseeking, how do I look for places that are in chaos or survival mode?
  • How big should your team be before you need a team lead?
  • Examples of Team "Homework"
  • How to encourage devs to write unit tests
  • The role of designers and architects in agile. is tdd irrelevant?
  • Code reviews with remote teams





A Value System for Code Reviews, and How to Scale Them for a Large Project

One of my customers wanted my help is increasing their code quality.
When I spoke with the developers the following conversation happened several times:

Me: "Wow, this code... how many lines long is this method?"
Dev: "about 700. Yeah I know"
Me: "Have you tried to refactor some of it?"
Dev: "oh.. noooo."
Me: "What if we just extract this small part over here , these couple of lines, to a method with a good name?"
Dev: "Yeah, let's not.  If I do that then I have to do a code review on that, and that can take 24 hours to 3 days. The architects are so busy.. too much of a big deal. I'd rather focus on what I'm doing"

When I went to the architects I heard from them how overworked they were. They meant well, but 2 architects on 30 devs, with more of their own stuff to do as well.. it just didn't scale.

I went to the chief Architect and told him what I saw. I told him I felt that the way the code review process worked (reviews are done through a tool, and take very long) is actually deterring people from changing the code for the better. He was surprised to hear it. After all, they had instituted mandatory code reviews to increase code quality. So we talked about what we can do.

Here's the plan we setup in place:

We will organize a team meeting of all the architect where we will agree on some basic values of what we want from code reviews. I noted that the following values worked for me:

A code review is successful if:

  • The developer who wrote the code learned something new (even if small)
  • The code ends up being better  (even if slightly, even if it's just one character or a name change)
  • To achieve this, an effective code review has to be in person, not through a tool if possible. if not, then through a non text tool (visual+ audio)
  • It also has to occur quickly , or even immediately when the code is ready for check in
  • It increases the amount of people that can review code, or the amount of code they can review well


We decided to experiment for a couple of months with doing reviews this way:

  • When a developer needs a code review, they can just go to an architect and ask for it in person (not using a tool hopefully).
  • The architect will join the dev and review the code, while talking as much as possible about their thinking process, coaching in the process
  • A THIRD person will join (another dev) the review, sitting near and learning how to review the code.
  • The next time a review is requested, the learning dev (third person) will try and do the review while the architect sits back and sees how it goes, then goes over any missing things with the reviewer 
  • Developers will check in early and often so that code reviews are nice and short (a few minutes hopefully)


In this way we:

  1. Make the reviews more effective since they are in person
  2. Less bureaucratic since they happen very quickly
  3. This also  makes developers less afraid to change code and get feedback on it since it doesn't take a long time
  4. We make more developers able to be code reviewers, thus making the code review process more scalable. Anyone can review anyone's code within a couple of months.

I wrote more about code reviews in the face of horrible code quality here.