I thought it was a simple interview question

The last two jobs that I have had I have experienced numerous interviews where I am phone screening and performing face to face interviews with candidates. These candidates are anything between a brand new graduate right on the job market to engineers with 20+ years of experience. I have read the articles and I have come to move away from the old way of thinking that says experience on the job relates to how good you are. It is just not true anymore with all of the libraries, frameworks, SDKs, devices, archi… . If you are still doing COBOL and only COBOL are you worth anything? Yes. Someone is looking for your skills.

HERE IS WHERE I START TO SHAKE MY HEAD.

If I ask a candidate “How do you store a list of integer values?” (don’t judge, this is the first question I ask) most of them respond with a common answer – List (note: I interview for C# and Java positions). Not that this is a wrong answer, but is it the best answer? I have only had one, count it one, candidate out of 100+ give me a very thorough answer that hit all the points you want any candidate to know if you are lucky. If I had my choice between arrays and lists to store integer values, then you have to start asking questions. Can you sacrifice direct control of the array and hand it off to a list? Do you have a finite number of integer values that need to be stored? Is there any reason for optimization? In most cases the right answer is List, but from a computer science foundation the answer is array. The next question is “What if I only wanted the unique numbers from the list of integers?”, survey says! The top answer – “Iterate through the list and check to see if it already exists.” Whomp! Whomp! I have only been in this industry for 8 years now, and I have 10+ years experienced engineers that don’t know the common definition for a set/hash table and how it works from a high level. I am not sure where the void is? Did you just look at blog sites on how to use syntactic sugar to create websites and then call yourself a web application developer on your resume? I am really lost on this. The weird part is that they know the answer for the map question more times than not. A map uses the concept of set as an internal data structure!

THEORIES

1 – LAZY

No need to explain. You just don’t care enough. In the Army we call that an oxygen thief.

2 – SELF TAUGHT

Ok, so not everyone can keep up with everything. So you do what you can.

3 – BOOTCAMPS

Self explanatory. You went to the Ruby on Rails bootcamp to learn how to be a web developer and now you want $120k+ in salary for spending $5k-$7k on an 8 week course. I can see the debate here if you are applying yourself to learn the intricacies of what is going on under the hood. I might have gone the bootcamp route myself if I had the same passion I do now that I didn’t back in college. I can self reflect and say that I had no idea what I was doing in most of my classes and somehow just made it work so that I graduated. The optimism is that I would have failed out of college more than likely had I pursued any other major.

4 – CURRICULUMS

Are curriculums lacking to teach data structures and algorithms properly? I can’t imagine that is true. My university had a course specifically for each of those subjects. These are must knows, right?

5 – JOB MARKET

Where I currently reside there is an inflation in what software engineers should earn in salary for their job position and performance. If you don’t know the difference between an array, set and map, or you cannot answer basic questions around that concept, then you are a no to hiring. If you can somewhat answer them, but then you tell me you want $130k in salary, then you are an absolute hell no to hiring. Your experience of 20+ years doesn’t mean crap to me if you cannot answer collegiate level questions. If you are the next startup co-founder about to make millions, and you can’t answer these basic questions, then you are hacking it to the top.

CONCLUSION

If you have made it this far, then I can tell you that I am not the best software engineer out there. I failed miserably on a Palantir interview 4 years ago, which led me to be better about what I am doing and learn where my voids are. I failed on several technical interviews since then, and it help me refocus again about what my next steps are and it is also embarrassing so it reinvigorates my passion for this stuff. I say all this because I think people need to do technical interviews in order to find their weaknesses. If someone doesn’t want to hire you, then find out why and figure out a pathway that fills that void that was discovered. Furthermore, I would gladly hire a high school candidate that can prove he knows what he is doing and pay him the salary that comes with that knowledge. Yes, there will always be years of experience taken into account because that’s how business works. If a high school graduate can create an awesome web application and architect third party services to boot, then he is getting paid, but I don’t expect him to be a tech/team lead. There is still a business understanding that most young candidates don’t know the ins and outs about. This business understanding is where you move from being tech savvy to a business enabler. Can I rely on you to have the best interest of the company in mind when you say no to new features or delay the product timeline for unforeseen blockers.

Leaders are Teachers

BLUF: You won’t be able to scale without being able to teach in order to grow.

Becoming a great a leader means that you need to be able to teach.  Not teaching anyone about your experiences is a selfish approach to not spread your knowledge and understanding.    Jack Welch introduced many to the idea that leaders are teachers.

They have to see their roles as a combination of teacher, cheerleader, and liberator, not controller. – Jack Welch

Teaching team members fosters team communication and imparts a sense of “you know what you are doing” and gives team members a sense of confidence in a leader.  We have talked about how you are not going to know everything and you rely on others knowledge and experience to complete projects, but imparting your experiences is key as you are the more than likely the senior leader and have been involved in enough situations to apply past experience.

In my experiences in the military you see senior non-commissioned officers (NCO) that teach brand new lieutenants the ways of the force.  These NCOs have over a decade of experience in the military.  I had multiple NCOs during my time on active duty that pointed out my many flaws and showed the right way to execute.  You rely on your NCOs more than anyone else when you are a young lieutenant  My one caveat is that you cannot rely on every NCO to point you in the right direction.  Always apply common sense when choosing those that you want to be your inspiration in your career and life.

Everything that you teach your team are small dividends that you are investing back into your culture.  If you have teaching points and not demand points, then you allow your team to learn from the past and filter those experiences in order to provide a more productive environment in the company.  Give them the leeway to make their own mistakes and learn from those, so that they can pass on experiences to the new guy.

I keep going back to this book – Jack Welch: Winning.  This is one of my top books to read to learn how to be a understanding leadership and learn how the people you are leading will make you great and that you need to take care of them.


SOAP BOX

I do think there are issues in the OSS community for those new developers that are trying to get involved with projects.  If you are the one making snarky comments about a pull request or make the commit so complicated that no one wants to put aside a week of free time to fix a label misspelling, then you need to take an inner look at what you are trying to accomplish and if it is truly open source.  Yes OSS projects are “free” libraries to help out others, but open source also means that others have the possibility to help if you give them the platform and culture that allows for that help to emerge.  It takes more than just adding a tag that says “newbie” or “low hanging fruit” to get people to help out.  If they have questions or look lost, then don’t chastise them, guide them.

Servant Leader

BLUF: Provide your team members with servitude so that they get to where they want to be mentally, physically, and emotionally.

I was listening to Tim Ferriss’s podcast featuring Ray Dalio this week.  Ray laid out a great way to think about being a leader; be a servant leader.

What does it mean to be a servant leader?  You establish a position in which you put the needs of everyone else in front of your own.  Lifting your team members up and allowing them to efficiently and productively perform their work is going to keep you far ahead, then pushing them down below you all the time.  This is not a cream rises to the top situation.  If you are never providing your team members with a culture for them to grow and give them what they need, then you are ultimately telling them that they don’t matter.  This in turn reduces productivity and esprit de corps.

Your job as a leader is to provide many of things to your team members with one being to provide mentorship.  Your guidance and feedback to a team member is crucial in building a strong culture.  You should always want to see your team members succeed even if it is moving on to a new opportunity outside of your team.

This mindset goes with my previous musings about being a participant in your leadership and not a dictator who doles out tasks and just oversees.  I cannot stress enough how it looks to team members when you hand out all the work and then go have a nice 2 hour lunch break and then come back and sit on the phone for a while talking to a “customer”.  Finally, they sit back and take all the credit for the great work the team has accomplished.

I am pushing all of my chips in on servant leadership and participative decision-making.  Here are two books to help out with this subject.

  1. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t
  2. Start with Why: How Great Leaders Inspire Everyone to Take Action

Accept Failure and Learn

BLUF: Failure is not a purposeful mistake, but you need to be able to learn from those failures.

No matter how much you plan it will never be perfect and sometimes failure is an outcome.  I have failed.  Too many times than I can count or even care to admit probably.  I probably would not be where I am today without those failures.  Every failure I had I came back stronger from them.

As a leader you have to know that failure is always a possibility, but how you respond to those failures is what makes you a leader.  If you become the one who turtles into your shell and cannot rally the troops, then you’ll lose the team right there.  You can be pissed off, sad or disgruntled about what happened, but your attitude cannot resonate that same tone in front of the team.

If you do fail at a task or project.  You have to be able to look back on it and make things better.  Answer three questions.  What was suppose to happen?  What did happen?  How can it be better?  You also have to be able, at a minimum, to provide 3 positive things that happened and 3 negative things that happened to help lead into your answers.  I have been a part of or used this procedure for my entire 16 years of experience in the military.  The outcome from this process is to learn from our mistakes and update the process, plan or procedures next time that allows for a better outcome.

In the military there are tactics, techniques and procedures (TTPs) that are built from learning from past events.  “Doing the same thing over and over expecting different results.”  You cannot apply the same procedures to the same problem every time if failed already.  It WILL fail again.

There are times at which you have to lean on team members to help get you through the hard problems.  Without being able to lean on others to complete the tasks, then you can definitely accept failure.  The best part about utilizing your team and failing is that you did it together.  The worst part about failing with a team is either you do it alone and you are the sole loser because the team knows they didn’t play a part or you blame the team for actions that you had control over.  If you are delegating appropriately and not asking for the moon, then you have given it your best shot at completing everything and you have to accept that and learn.

Tasking – Edge of Success

BLUF: Give team members tasks that put them on the edge of success or failure.

Providing the right level of task to the right person is always a tough decision because there has to be thought that goes into it; time, priorities, experience, and knowledge.  Not only these definitive decision points, but also do you have the right team makeup to provide a solid foundation to solve problems.  You have to build a team that makes sense.  If you are using C#, then don’t hire the technical expert that has been building Java Applets his entire career.  Unless you have the project runway for him to learn C# first and then get going on the project, they will fail.  Either because you are pushing them to fast and then don’t have the knowledge and experience to provide productive coding or because they get fed up and leave with the environment that they are working in.

When assigning tasks out take into consideration which ones will put team members on the edge of success, but a critical step left or right could put them in a failed state.  Having team members that you are excelling to succeed, then you are doing no favors for them or yourself.  They will not have challenging work and you will ultimately have a product that falls flat.  Engage each member equivalent to their technical needs and wants as well as their experience.  Once again you have to have the right team make up to make this achievable, but that includes still be able to solve problems that occur that no one knows how to solve.  You just need the team members that are willing to venture into new lands.

It becomes a team balance to provide the best culture and environment for your team to both have technically sound and creative work that they are proud of.  You have to know when to back off on the pressure and let your team have a break.  Software engineers have a known ebb and flow in projects.  You are going to have days or weeks where there needs to be full pressure to get something done or fixed, but there has to be a down time for them after the fact.  If you don’t provide that type of environment, then you run the risk of too much stress and fatigue for too long and they start to hate the job and career.

I treat my team like they are my kids.  You have to be able to teach them and give them life experiences without dictating how to perform every task step by step.  If you start to fall into the realm of micromanaging or dictating, then either you are the wrong leader or your hired the wrong people for the team.  Take a look at yourself first and adjust to see if people will break out of their shell to provide productivity and creativity.

“Watch the ice rate meter.”

BLUF: Utilize everyone and if you aren’t, then let them go so they can flourish somewhere else.

It used to be in aviation that even though there were two pilots needed to fly only one was actually flying.  You would get a very experienced pilot that has over 5,000 hours and turns to the inexperienced pilot and says “Just sit there and watch the ice rate meter.”  The ice rate meter tells you when there is ice forming so that you can turn on your deicing system.  Obviously this doesn’t make sense to get someone to watch it during the summer because you don’t need to.  This means you are only relying on someone’s ability during a partial time during the year.

As a team lead you have to be willing to give people tasks.  It is your job to make sure you give the right people the right task to succeed.  Sometimes people will fail, but if they failed horribly, then there are many factors that you need to look at in order to determine who’s fault it actually was.  If you hire a software developer straight out of college don’t expect them to know how to do everything and don’t expect them to have a quick solution.  It will take them longer to solve a problem and they might come into a situation where they don’t know anything and they want to learn but the timeline will take even longer.  Be able to accept that when you give them a task.

A couple months ago I had a team member that was fresh out of college and did not have a lot of experience with web development.  When I hired her I accepted all of this because she graduated #1 her class.  What the problem was is that she felt overwhelmed and/or unguided as a junior developer.  I was giving her task that took her a while to get done, but I never complained about her timeline or the final product.  They were all learning points, but I was bad at helping her progress and she was working on large problems that needed just a little bit more experience.

In this situation I can’t just tell team members to work on things that don’t matter.  Most people that look at software development as a career are not looking to be subject matter experts in a specific language with a specific design pattern (…or maybe it is just me).  And what I mean is you don’t want your whole career to be creating Factory patterns in Java for the rest of your life.  You know what else?  Employers don’t want that either.  You have to be dynamic and be able to market yourself in multiple disciplines so that companies feel like they are getting a valuable asset.

If a team member is not performing like you expect or want to and it is not because they don’t want to try, then you need to look at yourself as a leader and ask if it is your fault.  If you are attempting to give them tasks, then you need to have the conversation to see if they are happy with the tasks/work.  If not, then find the solution to get them to a new team or help them move on to another opportunity.  This becomes an investment they will talk good about you to others because of their experience.  Help them with their career that is your job as a leader.

Be Humble

BLUF: Own your mistakes and know your limitations.

Humility is a characteristic that has been shown to present a strong leader.  Humility gives you the chance to learn and not enforce your will but be willing to risk the vision of others to let them shine.

I have a Type A personality and I am stubborn and competitive, but I know I am nowhere near the smartest or best in my job market.  I have been humbled way too many times to count.  About once a year I submit a resume to interview at a place that requires subject matter experts; Palantir, 18F, and Instacart.  I failed to get an acceptance in all of these places.

I can admit that I am not a great software engineer, but I know just enough to make me dangerous.  As a leader I have to be able to accept my shortcomings and rely on other team members that are more skilled in certain areas to accomplish tasks.  This means that sometimes I have to purposefully put risk into the project.  But remember in previous posts where we talk about letting team members be creative and allow them freedom to think without chastising their work or decisions.  This risk that, by nature, gets injected allows for that creativity to flourish in other team members.

If you are going to put tasks that you cannot accomplish on other team members you also have to be willing to accept failure and be quick to forgive others for their mistakes.  Doing this keeps your team culture strong and lets the team know that you can make mistakes, but you have to bounce back.  Give them as many chances as they need.  As a leader you know the difference between giving someone an achievable task and giving someone a risky task, so you cannot be quick to judge when you give someone a task that you know could possibly fail if you don’t mitigate the risk.

One of the best things that the military does well is an after action review (AAR).  These AARs are personal critiques on overall performance at the individual or team level.  A team can be a 4-5 man team or a Brigade of troops.  You have to have thick skin during these AARs.  You are being personally attacked for decisions you recently made, but it is up to you whether you want to accept these critiques as an attack or a learning point to better yourself.  As a humble leader you must always be willing to learn through feedback and know your limitations.  Feedback from peers and others allows you the best learning experience.  It is an opportunity to not make the same mistake again.  Jorge Santayana famously said “Those you cannot remember the past are condemned to repeat it.”  You might have heard the more common phrase “Those who do not learn history are doomed to repeat it.”

Be a humble leader.  Know you strengths as well as your weaknesses and being willing to accept them.  Be willing to take risk, but be quick to forgive those that fail with the risk.  Finally, be willing to learn from your failures and accept help when presented.

What do I work on?

BLUF: It’s not the worker bees job to prioritize everything, be creative and work on items that you think need to be fixed if no other tickets are available.

Last week I had a team member start a discussion revolving around how we don’t have a full list of tasks for a feature set that we are working on.  He also mentioned about how we should be more agile about our tickets.

We are working on a SaaS product that has arbitrary deadlines with feature sets that need to be deployed on these deadlines.  My position with agile development is that agile is built around this understanding that a stakeholder cannot put deadlines on the team for specific features.  However, what a stakeholder can do is say “Ship it!” at the end of any sprint and it “should” work, but it might not be feature complete.  So we lie in the purgatory category of getting all the features done by a certain date with no ability to defer.  In the last couple weeks we didn’t have a large backlog to go diving into to grab more features, so the team member started coming up with ideas that he wanted to fix.  Awesome!  I always want people to be proactive about what needs to be done.  Don’t waste the day away by waiting for me to tell you what to do.  I am not always going to be able to tell you the next step right when you need it.

However, what did happen is that the next day I retasked him to focus on a different feature to fix that I thought could get done before our deadline.  The task I wanted completed would have been a better bang for the buck feature to demo to the client even though it wasn’t a big deal to code.  He wanted to know if he wasted his time doing something else for the day prior.  Absolutely not!  Taking the proactive initiative to do something else with the project without me telling him was the best event that could have happen.  The average of 4 hours that you waste on a task that didn’t go forward is part of the agile process (IMHO – i’m no “certified” expert).

During this whole conversation I wanted to get my point across that I want my team to be able to operate independently of me and a backlog.  This instills confidence in one’s abilities, creativity in the project, and independence from micromanaging.

I concluded the discussion with letting the team know that I would let them know if I thought they were underperforming.  I do my best to be very transparent so that my team knows I am telling them the truth aways and I admit when I don’t have the right answer or I am humble to admit I don’t know how to code something.  Being able to talk to people candidly is my only policy.  If I can’t tell the truth, then I need to hang it up and find something else to do.  Take a look at Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity.