Do You Even Code?

DEV.BIZ.OPS
5 min readAug 6, 2018

You can learn a lot about a company through blogs. Not the official corporate one, but the side blogs where people really share what’s up. When I was with Stack Overflow, I would sometimes read the blogs of my fellow employees. For example, the head of architecture blogs here, and the founder of Stack Overflow can be found blogging here.

I can’t recall my exact steps now, but awhile ago I came across the GO-JEK blog. If you are not familiar, they are an Indonesian tech unicorn that started as a ride hailing app for motorbike taxis, but now does a whole lot more through their app. Anyway, GO-JEK’s Engineering blog is super interesting.

I read a post by Niranjan Paranjape, the CTO of GO-JEK, on why they ask for code in interviews. That is nothing earth-shattering, but then he said:

“EVERYONE at GO-JEK codes. Seniority does not preclude you from the basics of the job. Because we believe Leaders who code are better judges of technical skill in people.”

That apparently includes the CTO.

It is not often that I come across a senior IT leader that can code. A good portion of CTO’s and CIO’s never even had a developer background or a computer science degree (or any technical degree at all). That is especially the case in large enterprises where the value of a leader is perceived not to be in their coding skills, but in managing budgets, delivery, and teams.

There are a few tinkerers though in the C-suite. One SVP Engineering in NYC that I know still actively codes on small side projects. An investment banking CIO out of London that I work with is also a serious coding geek and actively trying to build a great developer culture.

We don’t really expect senior IT execs to open up an IDE and start committing code into production. But what if you just hired a programmer that could not even write a single line of code?

That was the other thing that fascinated me about Niranjan’s post. About 60% of the candidates for an engineering position either do not submit a solution to a simple programming challenge or do not even know the basics. Which makes we wonder what jobs these folks are finding?

There is this coding “challenge” that an engineer created several years ago based on the children’s game FizzBuzz. He wrote this as a way to weed out candidates that “struggle with tiny problems.” Even a good number of computer science grads were stymied.

Real-life image of frustrated engineering manager trying to hire real developers…

Now this is not an opportunity to show me your elegant version of FizzBuzz. Jeff Atwood already documented the many places FizzBuzz solutions reside. Apparently that is what happens when you comment on the subject. But Jeff brings up a really good point:

“I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs.”

Why are we seeing this? How is it even a thing? Would we be so casual if we came across this attitude with doctors? Imagine the conversation in the OR:

“Doctor, the patient’s femur is fractured in three places.”
Doctor replies to nurse, “Sure, sure. Where again is the femur?

Then again if developers are writing the script for the future, our doctors may end up becoming robots, run by software written by engineers that may or may not know the answer to FizzBuzz.

No bad code here, man.

But back to the topic, it means finding developers is not getting easier. There are an increasing number of candidates, especially with the influx of coding bootcamps and academies. Computer science enrollments are rising. But again, how many are even prepared to solve FizzBuzz after graduating? How do you find truly talented or potentially talented programmers?

It is increasingly clear that the traditional ways of hiring are not working at the scale that is required by many companies. I highlight a few ideas to help reorient your strategy:

  1. Double down on internships. As Joel Spolsky says towards the end of this post, the great developers are never on the job market. It is best to get them before they even hit the market, which means when they are still in school and more open to exploring good opportunities.
  2. You do not need “the best”. Joel has emphasized this point in many of his past talks. Most coding needs do not require the best, they simply require developers that are willing to do the work and okay doing that work on more mature systems that only need to be maintained.
  3. Develop people. Following from above, because you do not need the best for all tasks, be willing to take smart and motivated people and upskill them for the work that is required, and then continue to offer training and professional development opportunities.
  4. Use Stack Overflow Talent. They have a proven solution and where else would you have access to a community of over 50 million developers visiting the site every month. You also can skip the FizzBuzz as you can see which users have high reputation scores and what they actually know.
  5. Get involved in the community. When you support local developer communities, meetups, hackathons, and events, you build up good will as an employer and get the attention of developers as an employer with a positive and reaffirming developer culture.
  6. Share your projects. Leading companies are publishing code publicly and contributing to open source, which one Canadian bank did, and it shows developers you are committed to innovation and openness.

What are some strategies that have worked for you in finding the right type of developer talent? Do you have your own version of the “FizzBuzz”?

Why can’t the IT industry deliver large, faultless projects quickly as in other industries?

Some valid answers and I do think things are improving…

We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.

--

--

DEV.BIZ.OPS

Thoughts on developers, digital transformation, startups, community building & engineering culture. Author is Mark Birch @ AWS 👉 https://twitter.com/marksbirch