Earlier this year I broke one of my rules and interviewed with a tech company you HAVE heard of, they aren't a FAANG but if the next tier down had an awkward acronym then they would be in that. I applied because I used this company's product daily for the better part of a decade and genuinely like it. It's well made, solves a huge pain point in the market and they have a loyal and growing user base.
I need to stress how much I like this company's product because I genuinely don't think applying for Big Tech is worth the time and effort (doubly so for non-traditional programmers like me) due to the number of rounds and the puzzle like coding tests they tend to use. I was making a big exception with this one.
1. The Application
I applied for a Senior Backend role, spent around 90 minutes on the initial application and then thought I would never hear back as, quite honestly, I didn't think I would cut the mustard on what they were looking for. I have a PhD in Electrical Engineering but I am a 100% self taught developer and they are big enough that "CS Degree" could easily be one of their initial filters. Given how the process went, they probably should, but more on that later.
Well, 24 hours after applying I had a request to book a coding test! To say I was excited is probably an understatement, I was grinning from ear to ear for the next day or so.
2. The Coding Test
The first coding test was very enjoyable. The problem was to make an algorithm where, given an array of numbers like:
[1,2,3,6,7,8,12,13]
I needed to produce a number of ranges to "describe" the series, so the above would be:
[[1,3],[6,8],[12,13]]
I initially didn't understand the requirements so I asked for it to be explained another way and the interviewer said "think of it like a compression algorithm" at which point it clicked.
I used a two pointer approach leaving one pointer looking at the start of the range and the other pointer traversing until the next number was greater than "the number I'm at + 1".
Had a fun chat at the end with the interviewer, asked about their deployment times, team make up and what their favourite thing about the company was.
Lesson: if you don't get the task on the first read ask for another interpretation rather than sweating and stewing on what you're supposed to do.
Overall: 9/10, would do again.
3. The Life Story
I was invited to the next stage a few days later and asked to arrange an hour to discuss my life and what brought me to this point. This was a non-technical discussion with an internal recruiter that was very enjoyable and overran by 10 minutes. I made two errors here that, while didn't damage my application I don't think, certainly made the interview more challenging.
I went to an odd but interesting 6th form college (last two years before university) and I started there, I planned to cover this in a couple of minutes and then move on. The problem was that this was 17 years ago and the interviewer got very interested in it. I spent nearly 10 minutes covering off the period of my life between 16 to 18 and immediately left me feeling pressed for time and added some stress.
Due to the above I then rushed some later sections and didn't really do them justice when those sections were far more relevant.
Lesson: Leave space for the recruiter to derail you, stick to relevant times in your life initially and if time allows reveal less relevant parts later on.
Overall: 7/10, would do again but would plan less content.
4. Technical Conversation
I was invited to the next 3 stages in one go, blocking out a whole afternoon for 3 calls. The first was a technical chat with a principal engineer about a project of my choosing.
I felt like this went well however this was the first time I made a real misstep that I was later told contributed to me not getting the role. I am a talker, I can often get on a bit of a roll and not leave enough opportunity for others to interject, apparently I did this in this interview and the interviewer felt I lacked some self-awareness.
Wether I agree is somewhat irrelevant since it was how they felt and I am aware enough of my personality to know I do this sometimes. In person it is much easier for me to pick up on the body language that indicates someone else wants to talk, on a video call when sharing my screen this is all but impossible for me.
Lesson: Leave intentional breaks to allow the interviewer to interject and ask questions.
Suggestion for interviewer: Don't raise your standing desk and awkwardly track you head up at the same time just after asking your first main question, it's incredibly distracting.
Overall: 7/10, it was an enjoyable experience and it was fun to talk about what I had spent the last 8 months working on.
5. Coding test 2
This. Went. Badly.
This interview is why I didn't get the job, I knew it half way through and my experience in this interview is why I just don't think self taught devs should apply to Big Tech unless you are prepared to waste a lot of time.
This was a "Pair Programming" test, in reality it was a coding test just like the first round and I was asked to implement Conway's Game of Life.
In speaking to lots of people afterwards this is apparently a common task to be set on degrees and in coding bootcamps, I had never even heard of it, let alone solved it before. I was also told by a number of that they thought it was "a bit harsh" to ask in an interview. I don't really have an opinion, I trust the interview knows what they are looking for.
I stumbled my way to a solution in 50 minutes, went down two dead ends, didn't understand a suggestion from the interviewer and generally wasn't proud of the code I had written.
When asked what else I would do at the end of this I said:
"I would significantly restructure this code, given that this is a solved problem I would research the best solution and implement it that way to get the best result".
The follow up question was "if this wasn't a known problem with a solution what would you do if this were a work task" I said I would speak to my team to see if they had seen something similar and have someone review where I had gotten to and make suggestions.
Apparently this answer didn't make up for the code I had written as the feedback I was given was "Inelegant solution and poorly structured code" 🤷♂️ I will come back to this line at the end ....
Lesson: try to cover off as many of the potential interview puzzles ahead of time so you are reimplementing a solution rather than solving it for the first time.
Overall: 1/10 I really didn't enjoy this interview.
6. Final Coding Test
After a 20 minute break I had one more round to go. It never even crossed my mind to back out but my brain was fried and I was not feeling confident.
This interview was to implement and LRU Cache. I hadn't come across this before either but this is the kind of programming that is right up my alley. A known set of requirements, a tangible problem to be solved and a clear outcome.
I really enjoyed this test, it actually did almost feel like pair programming as well. The interviewer was very friendly, we had some side chat about Swift (even though I was testing in JS) and their experience with it which helped ease me back into a relaxed coding mode.
I was told in feedback that the solution I chose was their least favourite approach however that was fine because I discussed all of my reasons, the trades offs I knew I was making and why they were probably ok given the end use case.
I was also told that in response to the previous interviewers line of "Inelegant solution and poorly structured code" this interviewer said "Did we interview the same candidate?" which is nice.
Lesson: never quit a process until it's over, if I had walked away after the previous interview I wouldn't have experienced this one, I would have had a sour taste in my mouth over the whole thing and I would have missed out on an hour and a bit with an awesome person who I thoroughly enjoyed my time with.
Overall: 10/10 would chat with again just for fun.
Feedback
After 5 days I got an email to say I was unsuccessful and that I could have a 15 minute chat if I liked to hear why.
I have weaved that feedback into the above narrative and it was very welcome. At the start of the call the recruiter asked if I had any ideas on why I didn't get an offer and I said "Conway's Game of Life" with a grin on my face, they chuckled (nicely) and said "yeah, pretty much".
They they also told me about talking too long in the technical conversation which was extra useful information.
Summary
Overall I am glad I went through this process however, I don't intend to apply to a company with a lengthy interview process again. This took up 7 hours of my time and, while the process was managed well, the people were nice and I gained some experience, I still ultimately fell down on a puzzle that if I had a CS degree I would probably have come across before.
Outside of this I've had 10 job offers in the past 2 years off the back of 2 to 3 round interview processes so it is totally possible to get job offers without the hoops described above.
If you want more of this sign up to my mailing list at Career Switch To Coding
Top comments (12)
I am not sure what you mean by "self-taught developer", but from the beginning of my CS degree, I have been learning my own with the help of online resources.
Next thing is that, I am always afraid to apply for the jobs where the ask to solve these sort of problems to apply specific algorithm. I know my limitation and would ingenuously say that I lack the knowledge these algorithm based solution.
Finally, you got to know that you didn't get selected. One month ago, I was interviewed by the HR and on the same day had a technical interview. I was informed that I will be notified if I can't make it within 15 days. On the 12th day, they asked me to complete an offline coding test/assignment. It's been 20 days and they didn't reply yet. And I am not sure when they will get back with the result.
Anyway, it was a nice write up. Cheers.
If you haven't heard back in that long there are two possibilities:
You should get in touch with them to find out which it is. If if the first then contacting them won't hurt as you already don't have the job and you might get some feedback. If it's the second then contacting them is a good thing because they do want you and don't realist that something has gone wrong.
If they are still deliberating then really it's situation 1 and it won't hurt your chances to get in touch any way to see what's going on.
Thanks man for the suggestion. I'll try to get in touch with them then.
No problem, here is the "Is it over" email template from my book, might be of some use.
Dear contactName,
I’m conscious we are a little over two weeks since our last conversation and I’m hoping to get a status update on my application.
I understand that things can get caught up internally however I have other applications that are progressing and I’m keen to know where I stand with companyName as, while you are my first choice, I need to know if it’s time to move on.
Look forward to hearing back from you
Kind regards
yourName
Hopefully this is of some help
Taken from careerswitchtocoding.com/
Thanks mate for the template. <3
Well, I think it's a shame if one bad experience is all it takes to not apply for a similar position again. I just landed my first frontend developer position after doing several recruitment sessions. I would think an interview should be considered a week worth of work. There would be 3-4 interviews, personally test, tech interview or test and I would have to do a lot of reading and preparation beforehand. I think this is a skill you need to learn, because it feels very different from coding and development on a real project.
I appreciate the comment but disagree with:
Companies have gotten so wound up in the hire slow, fire fast culture that was spouted years ago that they are wasting peoples time and missing out on good candidates because companies with quicker hiring processes are getting in first.
This isn't a case of "one bad experience". I have believed for years that more than three interactions is a waste of time, even back when I hired people running a company.
I totally get that it's a different set of skills, I just don't feel that trade off in time and effort is worth it when you can be de-railed by poor performance when so many other companies will get you an offer in 2 or 3 rounds 😀
Cool, if you can apply for jobs and get hired in 2 rounds go for it! But here in Denmark the interviews I have been going to have all been 3 or 4 rounds. This is certainly not the norm outside of the it field, so can only agree that it's aggressive. But this is how things are around here...
Great piece, love that you took something positive from an otherwise exhausting process. I've had lots of different types of interviews - some of them successful, some of them not - over the past 3 years since I changed careers. And just like you, I've received plenty of offers within 3-4 rounds of interviews. I had to do 6 rounds to get my current job, and while this interview process was quite nicely structured I would definitely not go through the same process for just any company.
Often, the types of so-called "pair programming" tasks you've described turn out to be nothing but stressful solo programming exercises. It takes one bad interaction or one moment of confusion to ruin the whole interview. And a lot of companies don't even give you another chance to redeem yourself. The way I see it, there's very little you can learn about a candidate (or about the team you'll be working with, if you're the applicant) in such interviews, as there's a very specific type of software engineer who will thrive in this environment. And they always get the job.
Great that you went through with it anyway and learnt so much in the process!
Thanks for this comment, 100% agree. The middle test where I messed up was like you describe, a bad stressful moment that ultimately (I think) cost me the job and no amount of other positive indicators of my abilities could change that persons mind I guess. Basically it’s a process where you need to be perfect the whole way through with no slip ups 🤷♂️🤦♂️
Good write-up. I enjoy reading about how other companies interview their candidates. Not everyone has the position or privilege of turning down interviews because of their length, though, and a lot of companies follow FAANG interview styles. I don't think we're going to get away from leetcode-style interviews any time soon. The "let's chat about a project of your choosing" is great, though, and the LRU cache problem sound pretty interesting.
Yes, there were elements of this process that were good but the overall feeling that I came away from was "waste of time other than confirming what I already knew about long interview experiences"
There are enough companies that don't do FAANG style that I don't think you have to be privileged to turn them down. In fact I think that you have to fairly privileged to have the time to be able to go through long interview processes. People who are in desperate need of a job (more likely a career switcher with family obligations and the like) are blocked from the FAANG tiers not from ability but from circumstance.
Thanks do the comment and glad you enjoyed the write up 😀