Story Time
Recently, I applied for a job...
I was asked to do this test task:
Quite simple, I did it with some extra bonuses, like using Vue.js and deploying onto Heroku. Here is the repo url: Debtor Administrator
What I got in response was:
- If you would like to hear the full story, I've written it into the comments.
Setting The Bar
Original pic: https://timcoffeyart.wordpress.com/2011/10/26/setting-the-bar-high/
Don't get me wrong, I'm not saying they should've hired me...
I'm just saying their bar seems non-realistic!
Recently, many companies are just setting the bar too high.
You realize this when they start inventing stuff like:
- 10x Engineer.
- Full Stack DevOps Developer (I'm not kidding!).
- Passionate engineers (who work overtime and learn on their free-time). ... etc
Like, SERIOUSLY?!
Good vs Great
There is a fine line between good and great, the best way to describe it is how Steph explained it in her awesome post:
Perhaps “great’, is just “good”, but repeatable.
Hmm, how many people are "good"? and how many people are "great"?
The reality of how good most people are is just in this curve:
- This is called the "normal distribution" in statistics which you might not even care about 😄
You see right there, the percentage of people who are great and bad is just super small.
The odds are, mostly me and you fall among the GOOD developers.
So, instead of chasing that dream of being a "ninja developer":
How about you stop chasing that stupid dream, FOR REAL!
How about you love being a good developer, repeatedly.
How about investing in yourself and learning new stuff every single day.
How about you accept that it's very okay to take a break sometimes.
Latest comments (125)
After reading the list of downsides you made, looking through the discussion and you have 9 years of experience working as a freelancer, I feel sorry for your past clients.
Jacob Kaplan-Moss - Pycon 2015 Keynote: "I am a mediocre Programmer." youtu.be/hIJdFxYlEKE
zniper.net/posts/jacob-kaplan-moss...
Dear Developer,
Since you didn't pass the interview, it doesn't mean that you are a mediocre, maybe they're looking for someone with different characteristics
Don't worry, there are many other better opportunities.
You will make it!
Cheers
This is why I avoid interviews with coding challenges. One is trying to conform to the incredibly high standards of another developer, and it's a time waster. Coding challenges, in my opinion, should be for those who don't have a portfolio but do have years of experience, otherwise, this is why I think a portfolio is vital for job searching.
Good post! thanks for share your story.. same to me, i just fill like a mediocre developer some times!
@yaser Perhaps you should have stopped when they asked for the first changes (like if you were already employed).
Job interview demo tasks tend to be unreasonable at times but heck this is the nature of the game we have to play.
Thanks for writing this up it is very therapautic for the rest of the community that deals with similar issues.
IMO, being a good developer is always striving for more, and keeping on top of the ever changing development scene. But then, that's just my opinion.
Your implementation is much better than one he shared with you for me. I did just a quick view :D
Thanks for sharing the story. I am sorry to hear that the firm screwed you in a very unprofessional manner!
A great talk about being a mediocre developer: youtube.com/watch?v=hIJdFxYlEKE
Jacob Kaplan-Moss, a self-described “mediocre programmer”, gives a PyCon keynote
Pretty simple.
If a company is unable to/won't pay you FAANG wages, they shouldn't have expectations that of those companies.
"Rockstar developers" don't even make efforts to apply to mediocre jobs. They already work at the aforementioned companies, or building their own stuff.
Never be ashamed of not wanting to jump through hoops for companies that claim they are building "the next big thing". Chances are they aren't, and also they don't understand supply-demand in HR terms. It's a sign of future failure.
Bad news buddy, but looks to me like they just used you get free stuff. There may not have even been a job in the first place.
This an invaluable post for me. Have the opportunity to know both sides of the story and learn how some companies approach the recruiting process is something amazing. I didn’t know, for example, that some companies don’t check the code at all but they check the test coverage or the commit history, this is pure knowledge for me.
Thank you so much for all the parts involved in this conversation, I have grown a lot with some minutes of reading.
One more thing. From my experience you were lucky to get and answer (a detailed one), in my case I almost never get and answer at all :)
I've said much in the last few years on the trend toward using code projects like the one you were given to suss out an Engineers ability, unfortunately though this method is light years better than live white board exercises it is still not the optimal way to suss out an Engineers talent.
The best way to suss out Engineering talent gives you an efficient understanding of these key abilities that you require in a real world Engineering scenario. 1) Tenacity. 2)Problem solving ability. 3) Time management.
That's it. Nothing else matters in any Engineering role on the job. Not if the Engineer can write out Dykstra or a* or any other algorithm. Not if they can tell you how garbage collection works. Not if they even know how to use a particular obscure feature in the tool de jour... Tenacity, Problem solving ability and time management.
The fastest way to get at all three is not to ask them to waste their time on your behalf and without pay (which is immoral IMO) for the hope of being pushed to the next step but to ask for an EXISTING project of theirs that they are proud of that can be used to exercise the three key talents listed above.
For tenacity, you can ask "In this project, did you have any problems that you first thought were impossible but figured out? How did you realize you could solve the problem?" Their answer will zero in on those issues for the project and you can assess if what they deemed difficult matched with your and your teams conception...thus sussing technical fit.
For problem solving skill you can ask "What are the steps you go through to solving a new problem that you've never seen before?" This gets you to the 1, 2, 3 of solving a problem. Do they have some idea in their head already and get going? Do they start with R&D by hitting google and stack overflow? This gets you an idea of how fast they go from clean slate to skeleton project actively being fleshed out.
For time spend you ask how long the project took to complete, how did they task out their work and manage their development process. This gets you an idea of how quickly they can work and if they can do the necesary work on time. To a company this is probably the most important factor as time is money.
Everything else is fraught with bias...of single points of failure (One Engineer) disqualifying good or great candidates because of gotchas put into live coding challenges or discounting people for being nervous while live coding ...it's all fracked. As part of my consulting company I take part in hiring drives and have interviewed many Engineering candidates and I find the best are the ones who excel in the three traits described above...even when they don't have a project that I can look at the code for.
Links:
sent2null.blogspot.com/2014/05/liv...
sent2null.blogspot.com/2013/02/gra...
sent2null.blogspot.com/2013/01/rub...
sent2null.blogspot.com/2012/03/eng...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.