Skip to content

Instantly share code, notes, and snippets.

@lazywithclass
Last active December 6, 2018 15:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lazywithclass/7f4b96f72c1c0bd29ce71fc8b56c8b4d to your computer and use it in GitHub Desktop.
Save lazywithclass/7f4b96f72c1c0bd29ce71fc8b56c8b4d to your computer and use it in GitHub Desktop.
161

161 - lazyblog

The end of 7 long months

It started in March 2017 and it ended this afternoon 19/09/2017, when I finally realised I am going to sign with this company.

The numbers

161 curricula sent
80 answered
41 "no"s
26 finished at some point during the interview process
3 ended up with an offer that I turned down
1 accepted

Last time I tried I've looked for a job was late autumn 2016

32 curricula sent
17 answered
9 "no"s
8 finished at some point during the interview process

Before that it was late 2015

44 curricula sent
24 answered
8 "no"s
17 finished at some point during the interview process
1 accepted

It looks like that no matter what the response rate fluctuates around 50%. Over time my skills got better, as for everyone else, so I don't think there's a lot to be understood from that data, in the sense that we're deling with different companies with different interview processes. I posted it because I felt this time it took a lot to get the job I wanted.

About the interview processes

I've written about that.

But I'd like to spend some time talking about the last one I was involved with:

  • few questions to be answered offline (you could see it here)
  • interview with CTO
  • interview with colleague
  • interview with technical cofounder
  • interview with CEO
  • send over a couple contacts for reference calls
  • day at the company, attend the standup meeting, then pair for 40 minutes approx with each colleague (5 of them)
  • spend time with them having lunch (or not in my case since I can't eat while I am interviewing, too stressed)

I think this is a long process but at no point was it too hard or stressing, and it did the job of making sure I had enough CS, coding, and interpersonal skills. I said enough, not good :b

Since I had lots of emotions about the current state of how interview processes are handled in the industry, I did the usual "hitler reacts" video, about interviews, showing few problems and a lot of saltiness:

IMAGE ALT TEXT HERE

Not knowing all the technologies

In the past I've been rejected for (for example):

  • not having at least one year of Clojure dev experience
  • not having enough Elixir experience (I have none)
  • not knowing PHP (this was me when I read that)
  • not knowing Ember, despite having used Backbone, Angular, React, Vue

So, my point is that I (might) understand if you want experienced people if you're using languages like Haskell, Idris, OCaml, Clojure, etc... but I don't really see the point in asking for previous experience in PHP. I am not saying PHP developers are second class developers, far from it, I am talking about the steep learning curve of some languages when compared with others.

My idea is that if you're looking for a 100% match you're just going to get whatever you signed for, nothing more nothing less, you don't get the benefits of a newbie, looking at your design choices with a questioning eye.
A developer with experience will recognise patterns and idiomatic code that's usually written in that language, so they will just go "yeah, that's how you do that" and move on, without necessarily pondering on the choice.

I believe a company should look for a partial overlap in a potential candidate, seeking skills they don't currently have in the team, because diversity brings innovation. Imagine the newbie learning your stack and understanding that actually there's a better way of composing modules, and you didn't know about that because no one in the team went through the basics all over again. Hiring newbies is fool profing your codebase to a certain extent. Of course they should have their own area of expertise, in the end there's some value they're bringing to the table, right?

In the company where I'm going to be working at they use C++ and are building a security oriented product.
Needless to say I don't know both, and I don't know them big time. There's the chance to learn on the job, and bring the refreshening presence of a newbie in an environment of people used to the tech stack.
I believe the thing to do now is plan to fill the gap, because one thing is to bring a pair of fresh eyes to see everything with a critic mindset, the other is to arrive completely unprepared with no plan to step up one's knowledge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment