Are you in control of your career?
If not, now is the time to learn:
I recently did a coding challenge as part of the screening process for a well known software company. It’s the modern way, screen out people as soon as possible to avoid HR time on people you won’t hire anyway.
I FAILED IT.
There is a twist, it got upgraded to a pass and I subsequently passed the rest of the process and got offered the job.
Here's the whole story…
I agreed to take the challenge and a minute or two later I received the the code test by email. Thoughts crossed my mind. If I take too long sending it back, it will look like I've spent far too long on it.
After all, I can’t just drop everything and focus only on this test. I reply indicating I’m at work and I’ll try to find time to do it tonight, which is met with a warm response.
I relax with relief… and then I drop everything, and get cracking with the test :)
Each challenge has it's own quirks but the question in my head is always the same - "what are they looking for?". This is subtly different to what they think they are asking of me. They think they are trying to find out how I'd solve their problem, but all I'm really doing is trying to get inside the reviewer's head. I already know I'm good enough, I got over that road block years ago. I care about code, I care about quality. So, for me, this is about me trying to condense into their test all those little clues that tell them I'm a modern developer who does all the cool stuff the modern devs do - follow SOLID principles, expressive naming, outside-in, meanwhile leaving that breadcrumb trail that makes it obvious that I TDDed it.
There is a huge psychological operation in play here and I'm second guessing the faceless reviewer's coding preferences.
'The test should take no longer than 45 minutes to complete' it says. Bullshit. By the time I've read the challenge, fired up my VM, opened visual studio, created a project, created a test project and written my first acceptance test, I have 6 minutes left of the allocated 45 mins. This is gonna take 2 hours!
I've decided what it is they want to see: patterns, extensibility, BDD. 3 hours 30 minutes after opening that email and I'm done. Ok I was doing my other job at the same time, so probably 2 hours is a fair “actual time spent”. I'm not worried about what I've produced, I'm worried about how it is going to be interpreted by the reviewer I don't yet know.
They might think I'm an idiot for not considering something that’s not explicitly in the spec. Do they actually want the app to run? or would they be happy with running it from a test only? Will I be wrong whichever I decide? I need a second opinion.
"Will I be wrong, whichever I decide?"
I can't ask the audience so I phone a friend - "I'm doing a coding challenge, can I run it by you?" - Is this cheating? No. They don’t take your phone away when you are actually doing the job. As devs, we all love a problem to solve, especially if it isn't relevant to anything in the real world. I can't think I would ever refuse an opportunity to chat about a coding puzzle. My friend is busy at work, so he promptly drops everything to talk to me about this puzzle.
We agree that I've done enough to show I can code, think about a problem, solve it clearly and more importantly make the code communicate. Uncle bob would be proud (maybe). Shall I do more? shall I make it more robust? No, I decide, I’m only supposed to have spent 45 minutes on this. But what about that one suggestion my friend made. I know it isn't needed, my code is enough, but he is right, I don’t need a default constructor. Oh crap, I can't stop myself, I'm already changing it, another 30 minutes of my life gone forever. The code was good enough an hour or so ago, just ship it.
Just before sending, I read the code one last time, or crap I missed an obvious test, I retro fit it in while making it look like it was part of the TDD cycle.
I've had enough, I'm done. I zip it, ship it and wait.
For some reason I expect a quick response but it takes 5 days. I'm expecting the reviewer has marked this test a hundred times. I'm expecting them to open my submission, see it's fully tested and a well known pattern and it's game over, an instant pass?
In comes the result: "We regret to inform you that your code didn't meet out standard"
As steam bursts out of my ears.. I try to gather my thoughts and respond professionally
WTF, WTF WTF, What the... What the hell sort of code are they writing there if they can fail my code? Is there some new fancy code that makes mine too complicated all of a sudden? Still, my ego takes a nose dive, my pride is on the line here. I can't sodding fail it!!! They don't understand, I wasn't showing them 'my' perfect code, I was giving them the perfect answer they sodding well wanted, they can't go and fail me, they just can't, it's just not possible.
I'm not saying I'm god's gift to coding, I'm really not. Far from it in fact, I just protect myself with good tests and let the code pretty much write itself so that I don't have to :). My point is I can code, I can write maintainable software and it is actually what I'm all about. To fail on the grounds that my code is not up to standard like it is not maintainable is an attack on my manhood.
I'm about to reply angrily - somehow out of some weird stroke of genius I manage to stop myself, I delete my 2000 word angry essay and leave in only the first line
"Thanks for this. It would be good to talk to the developer who marked my test and explain my design decisions".
At this point I've kind of forgotten that my professionalism kicked in at the right time. In my head I still think I sent over my angry essay about why the reviewer probably learn to code by collecting 8 tokens on special packs of Kellogg's corn flakes. I'm still fuming and I call all my dev friends to tell them about the misjustice and the disgrace to our industry.
To my surprise, I get a call saying that the developer would be happy to have a chat with me and I'll have the opportunity to discuss/defend my code.
Oh wow, shit, crap, fu*k. Oh dear, this is happening, where has my mouth got me this time?
What if he tears me apart?
It's one thing to have feedback in an email, it's another to be told to your face. I get ready to have the call with Simon Cowell of the .net world. Ok ok I can't sing, I'm a complete imposter, I'm sorry ok, I'm sorry I wasted your time making you mark my pathetic 45 minutes of coding fame, I'm sorry you had to see my terrible use of white space. It is possibly the worst test he's ever had to mark, I might need to give up .net and get a proper job.
Then the record scratches abruptly to reality,
Woah! He's a cool guy, a peer in fact, someone who knows his stuff and is as equally graceful in conversation. We get on well, I concede to some of his points and he concedes to some of mine. Truth be told, if we'd pair programmed this exercise, we would have better code than if either of us did it on our own.
He changed his position and decided I’d passed, and for this I'm truly grateful - I’m not sure I would have done the same if I’ve already decided someone is a ‘no’, I hope I would.
He contacted HR and informed them that the fail was now a pass. I later went on to do the pair programming and a chat with a partner and passed the process. All of which started with a fail.
What can we learn from this?
Firstly, I learned that NO is not always NO. Persistence does sometimes pay off and you should stand up for what you believe.
I learned that approaching the situation professionally as an adult was the correct course of action. The mistake would be to go child-like, complaining about unfairness, and injustice.
I heard that some people who fail the test are so angry that the company are just unable to have a sensible conversation with them about it - clearly you can’t hire someone who ends up in an uncontrollable rage.
Maybe a good test would be to fail everyone, just to see how they react - but that is too risky and dare I say it immoral (that’s my parental side coming out).
The truth is, both I, the company and the reviewer learned more in this 5 minutes of conversation than from the 3 hours I spent doing the coding challenge and the hour or so he spent marking it. In the end the coding challenge just became a means for a professional conversation - this is exactly what it should be for!
Coding challenges are fun to set and fun to do, but they are all too easy to get the wrong impression from.
I'd even go as far as saying that if you want to fail someone, when you read their code, you'll find a way. That's not what individual coding challenges are about. It is about screening out the extremes. Screen out the people who don’t even attempt the test, fail to solve the problem at all, write confusing code or make no attempt to test drive it. Screen those people out, but don't screen out the people who made a few different assumptions about the spec, write readable code and even have a few question marks about them.
Pairing challenges, on the other hand are a completely different kettle of fish - they are more than screening out the extremes. I believe you can make the correct judgement purely on a pair programming exercise, but I’ll save that one for another day because there is more to it than watching someone code.
I learned that the reviewer of a coding challenge isn’t the enemy, they are in as just an awkward position as you. They are trying to judge you based solely on the code they can see on their screen. They don’t see your assumptions, and are trying to interpret the way you think. Furthermore, marking this test was probably imposed on them with very little guidance as to the purpose - is this test the final stage? How strict shall I be? What if I let someone though that then costs the company money? It will all be my fault?
The easiest result to give is FAIL because it seems the safest - “at least no one can blame me if they turned out to be bad”. I would go as far as saying that even a test that doesn’t quite work but the code is easy to read and easy to change and communicates intentions is a pass. That is, for the purposes of a tech screening only, it is a pass.
Consider this. If the reviewer points something out that is a major problem, and you immediately see the problem too and agree with him it’s a problem and know the fix - Is that really a fail? That’s like saying…unlucky mate, doesn't matter what you think now, you got it wrong, fail, you’re out.
The real world doesn’t work like this.
The problem people are the ones who stand by and stand up for their bad decision…. e.g. “I didn’t write any tests, because my code always works and tests just waste time” - that is a fail, because no matter how hard you try, they won’t see the light (until they find it themselves that is)
Conclusion for the company
Your coding challenge may be creating an amplified problem of the very thing it was trying to solve. Agreed you might now be interviewing less people and having a higher conversion rate but you've thrown 10 babies out with the bath water in the process. That's 10 people you would have hired if you'd spoken to them and not based it on a completely code code submission and those 10 people will now take you another 100 leads to find again.
Use it to screen out the complete cruft. Even use it to raise question marks about people ready for the conversation or interview.
I don’t care what you read on LinkedIn or HR blogs, you cannot find the best candidates from a coding test.
A reviewer may be led to believe a fail is safer than a pass, but that is because they don’t see the bigger picture in hiring costs.
The truth is for a screening test, a pass is safer than a fail.
To lose a good person is a very expensive mistake, to let through a bad person through, just costs a few hours to eliminate them at the next stage, after all you don’t write off all the other due diligence just because they passed a test.
Here is a mantra for the screening test: When in doubt, don't screen out (have a conversation instead), or in other words, a question mark about someone is a PASS.
Let me know if you agree with me about coding challenges, personally I love doing them, I just don't think their value is that high - discuss.
You’re familiar with the benefits of becoming a specialist in one area of technology, right? I wrote another article on the topic so I won’t go into the detail here.
For now, it’s enough to know that specialism makes the conversation with prospective clients so simple hiring you is a no-brainer. When clients have the type of problem that you solve, employing your services is a no-brainer. Are we good so far?
Great, this article is about finding your specialism. Time is short, you don’t want to waste it on the wrong specialism. Let’s take a look at some examples…
So, from the top of my head, here is a list of suggested specialisms. Feel free to add your own to the list.
- SQL and NoSql databases.
- Multi threading/concurrency
- Application security
- Application design (Architecture)
- Distributed systems
- Programming languages
- Client side development (overcrowded hard to stand out, but worth a mention)
Pick one from the list and stick to it. You may have accidentally started your journey toward specialism already. Are you obsessed by a particular topic? The more you find out the more you want to know. This is good, think about where it fits into the bigger picture of application development. That broader topic is your specialism.
Join the community
All of these specialisms will have a community filled with people willing to help you learn. Seek them out and join in the conversation. As you hit a brick wall in your understanding the group will be there to help you through.
Be careful not to lean on the group too much, received wisdom does not lead to mastery. Make sure that you are trying everything to understand the topic before you ask the question. Remember that the people willing to help you have put in the hours learning the topic. They will be more willing to help people that show evidence of similar effort.
Focus on concepts
Would you believe there are people that exist today who actually understand the asp.net webforms page life cycle. How useful is that knowledge now? Not very, thankfully, unless your stuck in one of those companies that can’t upgrade! (you are charging a premium, right?) The world moved on and Asp.Net MVC became the web framework of choice in the .net world.
The point is those people wasted their time learning an implementation in depth. When the world moved on they had to dust themselves down and start learning again. There was nothing transferrable from webforms to MVC.
Don’t make the same mistake, the technology landscape will move on. This kind of knowledge will become obsolete. Focusing on the concepts that underpin the technology is a safer bet. After all, the majority of todays shiny new technology toys are just re-purposing past ideas. When you understand the concepts, learning the implementation will be a doddle.
Teach as you go
In his talk on learning Marcin Floryan described three key stages to learning.
- Primed - your mind has to be open to the possibility that there is something to learn.
- Deliberate - you have to take action in order to learn.
- Validated - you have to test your learning in a public forum.
My hope for these articles is that they will nudge you in the direction of stages 1 and 2. By reading these articles you will be primed and take deliberate action to achieve a specialism.
I believe the best way to validate your learning is to teach others as you go along. Software developers have a tendency to hold back until they know more. We tend to focus on the many people that know more than us. We think that they have the teaching bit covered so we should keep our mouths shut until we know as much as them. There is another way to look at it…
As Nathan Barry said in Authority, don’t think of the many who know more than you, think of the one who knows less. Teach for them.
Most technical documentation and research papers are not written with the reader in mind. They are written with a great deal of assumed knowledge. Start to notice your struggles to understand the material, when you pass the barrier of understanding write about it. You have a unique viewpoint, a novice with a little bit of understanding. You can write content that eases the journey from novice with no understanding to where you are right now.
Sure there are loads of books out there on these topics. This is great for your learning, the problem is…
Arcane white papers and thick technical books put most developers off learning. If I ask someone how they gained there knowledge and they point me in the direction of a 1000 page book, chances are I’m not going to get very far. If however, they have an in depth resource written with a novice in mind, then I’m far more likely to read it. Better still, due to the early quick wins in my learning I’m likely to seek opportunities for further learning.
It’s three simple steps to mastering a topic, pick one, join in the community and teach as you learn.
The important thing is that you validate your learning by teaching others. Start writing the missing blog articles that would have helped you in the early stages of learning. Speak to user groups about what you’ve learned so far. The benefit of going public is that you will test your knowledge and build up a following.
The rock star coder is alive and well!
You may not want to hear that but it’s true. There is a breed of developer that delivers working software faster and better than the rest of us “normal developers”.
There has been a trend toward dismissing the rock star coder as a myth. According to this meme an individual that writes code 10 times faster than the rest of us does more harm than good. Leaving an unmaintainable buggy mess in their wake, with the only option being a rewrite. The problem is…
The software world needs rock star coders!
Someone willing to do whatever it takes to solve the complex problems. If that means going it alone then so be it! They will lead by doing, accepting the weight of responsibility for delivering a working system.
Until recently I was firmly in the myth of the rock star camp. In my mind rock stars are not team players. Quick to dismiss colleagues usefulness. Bemoaning the team for “not getting it”. At it’s worst this reaches the point where the team stop thinking, blindly guided by the rock star.
I’ve started to realise that the rock star is misunderstood. The world needs them, the rest of us just have to figure out how to work with them. Here’s my attempt…
Cowboy versus rock star
- Junior Engineer - Creates complex solutions to simple problems.
- Engineer - Creates simple solutions to simple problems.-
- Senior Engineer - Creates simple solutions to complex problems.
- Rockstar Engineer - Makes complex problems disappear.
I like this definition because the emphasis is not on lines of code or getting shit done. The rock star coder is also known as the 10x engineer. To me 10x engineer and rock star are not synonymous. It’s easy to be 10 times faster if you repeatedly work on the same problem space on greenfield projects. A rock star will approach unfamiliar complex problems and make them disappear.
So what does it mean to make a complex problem disappear? Well, here’s what I came up with…
A complex problem disappears when the solution meets the requirement AND the whole team understands the how and why of the implementation.
Let’s face it, complexity never disappears it’s just better understood. The more people that understand a complicated problem the less complex it will seem.
With these two definitions we can start to weed out the cowboy from the rock star.
The cowboy coder
The cowboy is all about the code, they just want to write code. They work with the vaguest of requirements (everything is doable) churning out code with lots of assumptions. They won’t care about what happens to that code after it has been thrown over the wall. Quality assurance and deploying to live are someone else’s problem.
The cowboy doesn’t solve particularly complicated problems. They just take simple problems and make them complicated. They are developers that have little understanding or regard for the underlying technologies on their chosen platform. A cowboy has learned how to get things working early in their career, but their understanding doesn’t go much beyond that.
Contrast that with the rock star…
A true rock star will have put in the countless hours of deliberate practice necessary to gain a deep understanding that goes beyond the norm. They will have read the specifications containing the constraints of their chosen platform. When they write code it is with a clear understanding as to these constraints and how best to work within them.
Working effectively with rock star programmers
A rock star can cause big problems for a team. If they are the team lead they tend towards dictatorship. No design by committee here. Do what I say and we will get there faster and in better shape.
If they are a team member they will be the lone wolf. The person that goes off and does their own thing, ignoring any team decisions. They don’t need to play by the rules of the team, the team doesn’t get it, better to just crack on and show them how it’s done. right?
Despite these issues I hope you are convinced of the importance of learning to work with rock stars. We all want our complex problems to disappear, don’t we? We also want to work with people that are motivated to learn things in depth, right down to the specification level.
We know by now they have a lot of knowledge and they know how to use it. The majority of the rock stars learning has been done in isolation of others. They go home after a days work and do another days work reading the spec, implementing code to gain true understanding.
Being in a team with a lone wolf developer or a dictator is no fun at all. The decisions are made for the team, they can stop thinking. This type of team is to be avoided at all cost. So here are some tips for working with the brightest and best…
Working with a rock star is difficult, they will challenge you to think about everything you are doing. After a while you will start to triage the questions in your mind before asking. You know that the wrong question will receive a barrage of thinly veiled abuse, or worse, reveal how little you understand of what the rock star is saying. You must persevere. You’ve got to be courageous and keep asking the questions, here’s why?
With each question the rock star must explain in a way that helps you to understand. Now both of you are learning. The rock star is learning how to communicate his/her ideas effectively. If they fail to bring you on the journey then your complex problem has not disappeared, therefore they fail the rock star test.
If you keep asking questions and making suggestions the rock star will eventually cut you some slack, giving you the chance to try out your ideas. This can go one of two ways, either your idea fails or it works. If it fails you gain insight as to why and you have the safety net of the rock stars knowledge to get you back on track. If it works, great, the rock star learns something and you gain more trust.
Now the team is being transformed into a high functioning team.
Look past their arrogance
In the face of unshakeable self belief of a rock star coder you may find that you ask yourself, What makes them so sure? How do they know this is the right way to go? We can look to sport to get some clues…
In his brilliant book, Bounce: The Myth Of Talent and the Power of Practice, Matthew Syed points to Irrational Optimism as being key to success in sport:
“World class performers…have taught themselves to ratchet up their optmism at the point of performance; to mould the evidence to fit their beliefs; rather than the other way round…And it is proficiency in these skills that often separate the best from the rest.”
While I’m not suggesting that irrational optimism is a good thing for a software developer. I can see the sentiment of having a high level of self belief as being the difference between the rock star and the rest. Think about it for a second, the rock star will have taken on a position of responsibility. They are willing to put their reputation on the line to make the complex disappear. They cannot allow self doubt to creep in, if they did it would lead to a compromised solution. The compromises may be to much to bear for the rock star.
Being on a team with a leader with that much self belief can be tough. But look at it this way, Imagine if Tiger Woods hired a statistician as his caddy. Every time the caddy hands Tiger the club he reminds Tiger of the statistically low chance of Tiger sinking the put. How long is that caddy gonna last on Tiger’s team…
The point is, give the rock star a chance. It’s up to you to build up a level of trust in the knowledge and ability of the rock star coder.
Become the middle man
Every team needs balance, a middle man will bring the balance between the novice and the rock star. It’s a tough role to play. The middle man will become the translator for the team. Translating the novice questions into something the rock star can understand and vice versa.
There is a danger of becoming the bottle neck. As the less experienced team members gain confidence the middle man must encourage them to ask direct questions. This the only way the knowledge will spread effectively throughout the team.
Relish the opportunity to learn
None of this is personal. Everything has a context. The rock star has come in with a clear vision of how the world works. They will take anyone on the journey who shows a willingness to self learn. After all that is how the rock star gained all of their knowledge, right? It’s only fair that they see the favour returned by the people they work with.
A rock star is not afraid to challenge the common knowledge. They will point out the uncomfortable truth, as they see it. It's an uncomfortable place being under the microscope of a rock star, but if you can get past the dent in ego you will find an opportunity to learn great things. The good news is a rock star is willing to help you on your journey, as long as you show that you are motivated to learn.
When it’s all said and done there is nothing magical about a rock star coder. They are just people who have spent a great deal of time learning a specific topic. Let’s not waste their effort.
We need to enable the rock star to spread the knowledge. It’s up to the rest of us to keep up. It is a challenging environment, but nothing good ever comes easy. So persevere, keep asking the questions that lead to insight and enjoy your time on a rock star team.
Have you ever been approached by a company, directly, because of your reputation? If not, would you like companies to approach you for your next project? What do you think that would do for your career?
If you want that to happen stop trying to keep up with the latest software development trends. Start learning one thing from the ground up. Here’s why…
Yesterday I had a chat with a fellow developer, which blew me away. I asked him how confident of getting a new job does he feel if his current company had to make him redundant? His answer…
Not very confident!
Here’s a developer working 8 hour days (at least) producing code to a reasonably high standard. He’s 5 years into his career trying to soak up as much knowledge as possible during work and free time. The thing is…
The more knowledge he gains the less confident he feels
Wait a minute, that doesn’t make sense, how can it be, more knowledge makes him less confident of getting a job, eh? The problem is, he is scratching the surface on a lot of topics. There is no depth to his knowledge.
Thinking about the interview process forced him to consider answering in depth questions. Guess what, as soon as he started thinking about interviews all of his confidence fizzled out.
So I gave him some advice. I told him to focus. Stop trying to learn everything and focus on one thing. Learn that really well, I mean Jon Skeet well. Become the goto guy for that particular topic. To the exclusion of all others.
The benefits of focus
I understand my fellow software developers dilemma. I too want to keep up with the market. I don’t want to get pigeon holed in some dead end job, trapped in a sea of bad code and practices.
I’ve tried to keep abreast of everything that moves in the tech world. I know enough to be dangerous in every layer of the web stack.
I know what HATEOAS stands for, does that make me a RESTafarian? I can wield clear:both at just the right time to fix a floated div, does that make me a front end guy? I haven’t written SQL in four years but I know how to join some tables, at a push I could probably even group by a couple of columns, does that make me a dinosaur (just kidding sql guys). I know how to reset iis from the command line, does that make me a devops dude? Not likely…
I’m a jack of all trades and master of none. That makes for a difficult sales process in my contracting business. Convincing companies of my worth is harder than it should be. I’m more convinced than ever that companies who want an all rounder don’t really know what they want.
Sustained focus on a particular topic gives a person the confidence to take control of their career. By understanding a technology right down to the ideas and concepts that spawned it you will be able to guide a team through the pitfalls of using it. When it comes to looking for projects to join you know exactly what you are capable of doing and what projects suit your specialism. It makes the search for your next challenge easier.
You can approach companies with a really clear message, I’m the guy that solves X problems. Companies can approach you because they know you are able to solve a particular kind of problem. It keeps the conversation focused.
Another benefit to focus is having a realistic understanding of what it takes to learn something in depth. Whoa, that’s a bit meta, learning helps you understand how to learn? It’s a big commitment to learn one thing in depth. Learning something in depth means you have read the original white papers and spec that the technology is based on. Not only have you read these, but you will have implemented your own version of the spec. Why…
Because reading is not enough, doing is the only way to gain true understanding.
Learning of this magnitude takes a decent chunk of sustained effort. Sustained effort is not easy, which is why not many of us achieve it. We read a couple of articles get a feel for something and think we know it. Guess what, knowing the name of something doesn't mean you know it. Knowing something in depth means we know when to use it and, more importantly, when NOT to use it.
Sounds like a silo to me!
Ok, so I have advised my colleague to focus on one topic to the exclusion of all others. I can forgive you for thinking that this advice is promoting silos. That is not what I'm advocating here. I work in agile environments, cross functional teams are the norm. Having software developers that have depth as well as breadth of knowledge will lead to better software. A team with an authority on RDBMS and NoSQL stores are going to make better decisions, right?
The advice was given to someone 5 years into their career. They have built a good grounding across the full web stack.
The problem is the scatter gun approach to learning stops working after a while. If you want to progress your career you need to be able to focus on one topic at a time. Once you build up a depth of knowledge you can then move onto another topic in the stack. The good news is it gets easier to keep up with changes in the technology. Do you think Jon Skeet has loads of work to do each time a next version of C# comes out? Nope he just builds on the depth he already has.
Focusing on one thing to understand it in DEPTH does not mean you know nothing else. It means you stop being distracted by the latest trends and focus on unpicking the reasons a technology is implemented the way it is.
But, what about full stack development, aren’t we supposed to have good working knowledge of all layers? Well yes, that is true, but in my opinion the full stack developer is a myth! There are not many developers that manage to accomplish an equally deep understanding of every part of their chosen tech stack. Those that do take each one at a time and focus on it to the exclusion of all others.
I don’t know about you but I feel overwhelmed by a constant barrage of noise about new technologies. I scratch the surface, learning just enough to get building something and move on. I just get started when I hear about the next thing. It’s time to stop this madness, focus on one thing at a time. Learn it inside out, until you’re the go to guy on this technology.
Having a depth of knowledge makes future learning easier. You will have built up a habit for learning that goes beyond surface knowledge.
When a "new" (let's face it, their all just a rediscovering old technology) technology is announced you will have a head start on the competition. Your depth of knowledge means that you understand the concepts that underpin any novel approaches.
You may even discover and promote a novel approach to a particular problem (CQRS anyone) which gets widespread adoption, now you've entered the world of the luminary...enjoy!
The other day I was reading an article about the working environment in stack exchange. I have to admit it does look good. Everyone gets there own office space! You can go in there and hack out as much code as you like, no ones going to get in your way.
I sat in my noisy open plan office and thought I wouldn’t mind a bit of peace and quiet to get on with my work. The article resonated, I enjoyed it, read the whole thing through. And then I got to the comments…
A few stood out, made me think, why are we so self defeating? I mean here is an amazing environment to work in (for some people). When these commentors looked around their own work environment they were exposed to how good it can be. What was their reaction? Were they filled with hope and purpose. Nope…
Looking at the workspace at Stack Exchange made them feel worse about themselves and their own environment. The comments were filled with lines like:
“That environment looks amazing but, I’ll never be good enough to join stack exchange”
After reading the comments I was both mad and sad. Because that was ME until recently…
How do you know you’re not good enough?
I spent years refusing to apply for Thoughtworks. I’m not good enough I thought. I need to learn more before I can apply.
By now I had resigned myself to the fact that I would never be good enough. The more I learned the more I felt I needed to know. In the back of my mind I knew that these were just excuses. A way of justifying the fear of being rejected.
In the meantime I carried on learning, progressing in my mission to deliver quality code in agile environments. Then I got the news that gave me hope…
An ex colleague of mine successfully applied to Thoughtworks. Finally, here was a true comparison, someone I felt on a level par with. I thought, if they can get in then so can I. Guess what, I applied and got the job. The truth is…
I was ready all that time.
I could have applied years before, I would have got in. I was always a cultural fit. My work ethic was aligned with that of a Thoughtworks consultant. The fact that I wasn’t experienced enough technically didn’t matter because I would have joined at a lower level. A level that reflected my technical ability. I was technically good enough for consulting at a more junior level.
Worst of all, I had opportunities to find out what Thoughtworks were looking for. To test my theory of not being good enough. There consultants attended plenty of meetups that I went to. I had many opportunities to discuss where I was and where I needed to be to apply. The worst thing is I put off applying until it was too late…
By then I was moving into a different phase of my life, one that didn’t suit the life of a traveling consultant. I managed to stay at Thoughtworks for just under 2 years. I worked with great people, the most engaged I’d ever come across. This was the first place that made me think about every sentence I said. But it all came too late for me to get the best out of the opportunity.
If I had joined a few years earlier I would have taken full advantage of everything they had to offer. Thoughtworks encouraged consultants to travel the world, teach new employees, take on the biggest technical challenges and speak about it publicly.
Test your limits
When a company is formed by people who know what they want and exactly how to get it you can be sure that the bar to entry will be high. Is this a good reason to believe that you will never reach, or surpass, that quality bar. How do you know if you don’t try?
I set my own limitations. I had no evidence to suggest these self limiting beliefs were true or false. The people commenting on the StackExchange article are setting limits that may not exist. The important thing is to look for ways to find out how far away from the required level you actually are. Don’t make the same mistake as me. If you believe a company is the pinnacle, then find out what it takes to get in and go for it.
Here’s what I would do differently.
- Find out what they are looking for.
- Make a plan for filling in the gaps in your knowledge.
- Set a date for applying.
- Treat no as the beginning of the conversation.
Let’s take each in turn
Find out what they are looking for - Usually a job spec or careers page will tell you a broad list of skills that a company wants. My reluctance to apply was partly based on taking the Thoughtworks careers page at face value. It listed experience that I didn't have at the time. That was it then, game over, right? Wrong, never trust the careers page.
Find out exactly what the company needs from the people doing the job. Research the company on LinkedIn, look for software developers that you could approach. Is there anyone that went to the same university as you? Send them an email explaining your goal to work for the company. The idea is to open a dialogue that will lead to insight about team structure and day to day function of the target company.
Fill in the gaps - Once the dialogue is open you can begin to get a picture of what skills the company truly values. If you are confident of those skills go for the job. If you don’t have the necessary experience then it’s time to build it up, quickly.
Make a realistic plan as to how you are going to learn these skills and experience. Are there similar companies where the bar isn’t as high? Could you apply to them as a stepping stone? Maybe there is an open source project that is using the necessary skills, could you join in?
Set a date for applying - Make a firm date in your calendar. The plan from the previous step should lead up to a date in your diary. Having a deadline will increase the chances of you actually applying.
When the day comes to apply don’t put it off. You may be tempted into thinking that you don’t know enough. The truth is you probably do, so go for it. It’s difficult to judge how far you’ve come so let someone else validate your learning by going through the application process.
Treat no as the beginning of the conversation - The big day comes, you do the interview then you get the bad news. You’ve failed to meet the required standard. Disaster, right? Well, not great but far from disaster.
Most companies these days allow you to reapply after a period of time. The first thing to do is to ask for detailed feedback. From the feedback you can begin to form a plan for your next application. By now you should have employees of the company in your professional network. It might be a good idea to run the plan by them. You may get the benefit of more indirect feedback from the interviewer.
The main thing is to remain positive and keep trying until someone tells you it’s never going to happen.
I wasted a lot of opportunity in my early career. I allowed myself to set limitations that didn’t really exist. When I finally had evidence that the limitation didn’t exist it was too late for me to take full advantage.
Don’t make the same mistake. With hard work and perseverance you will be surprised at what you can achieve. All it takes is a realistic plan coupled with consistent action and you will reach your goal of working for that great company.