A few months ago I underwent the coding assessment process for a FANG company which to put it mildly, I did not enjoy. You can read more about it here. I also briefly spoke about the interview process on a separate post. To quickly sum it up, the experience did not make me a better person.
When I got a call from a Capital One recruiter I knew it was going to be another one of those startup-y interview process that expects you to know the latest tech trivia and have spent a significant amount of time practicing coding exams on leetcode. To be honest I was not even planning to prepare for this one as I already had a new role lined up. I was totally upfront about it with the recruiter and told her that I am interested but time is of the essence given my current situation. I was half expecting her to quickly lose interest in me but to my surprise this only made her more aggressive in getting me a coding assessment and in front of a technical interviewer in record time. The entire process from first contact to receiving a job offer was done in just the span of 10 business days. Totally unheard of in the tech financial industry where some recruitment processes take as long as 4 months.
Online Coding Assessment Done Right
Capital One uses HackerRank for their coding assessment. I really like this online coding assessment tool as it allows users to use a temporary git repository for the duration of their assessment. This means the candidate does not have to code on a browser! (who does that in real life!?!) The candidate can enable the git repo option and use their development IDE of choice and push changes to HackerRank. This not only provides a better test experience for the candidate but will also give them the ability to show judgement in how they write relevant git comments. A good developer always puts in relevant comments when checking in code. It should at a minimum make sense to you so you can read back the pushed commits and see what you we’re thinking when you made those changes. These little hints will be very useful when investigating issues that stemmed from older commits.
Letting candidates use a git repository would also show how the candidate thinks about project progression as they check in logical code checkpoints. This is extremely useful during early development stages when you are structuring the projects and classes. I do not believe that anyone can get this perfectly right the first time around, so having good comments while checking in parts of code that logically makes sense to be pushed in together is critical. A reviewer will be able to deduce the candidate’s judgement on what needs to be implemented first and how it should be structured. These are little nuances that will be very difficult to tease out if the assessment only focused on functional correctness of code.
The code assessment also had a time limit of 72 hours. Most of you will ask why it should take that long? Is it because the problem case is extremely complicated and requires a lot of coding? No, not really. The problem case was rather simple and even had a lot of boiler plate code for the candidate to start with. I personally spent around 4-5 hours doing my assessment because I was pressed for time and did not take any breaks (but also because I was having so much fun coding that I actually finished at 4 am 🤣). There were also a number of existing unit tests that needed to pass. So, in fact the coding assessment does not require 72 hours if you just wanted to meet the minimum requirements and pass the unit tests. But I do not think that is the point of this coding assessment. I think what they are trying to test is if you are able to write mature code instead of just efficient functional code.
I think what they are trying to test is if you are able to write mature code instead of just efficient functional code
Mad Computer Scientist
Writing mature code requires real world experience. It is the little things that a developer would do to make their code more readable, maintainable, debug-able and extensible that really matters in the real world. Whenever I write a method that returns a value, there would only be 1 line that has the return call and that would be the last line of the method. I also would never do any additional operations on a return value on this line, no matter how trivial. This would mean that at a minimum I would have at least 2 lines of code in a method that returns a value. It may sound inefficient but my experience has taught me that debugging that return value is always easier if you only had this on the last line of your method:
return variable;It may sound nit picky but most code defects that take hours to fix are caused by lack of basic code hygiene. From naming your methods and variables aptly to writing decent code comments. This is the foundation that good developers are made of.
It is the little things that a developer would do to make their code more readable, maintainable, debug-able and extensible that really matters in the real world
Mad Computer Scientist
A Phone Interview With the Right Person
After passing the code assessment I was quickly scheduled to have a phone conversation with a senior member of the team. Actually, it was the person that was running the whole project. I was pleasantly surprised that this Director level person was an actual developer. We had a hearty conversation about technology and coding languages. A type of conversation that is rare in more traditional tech financial institutions as Directors are more relegated to a pencil pushing role that is measured against the amount of money they save on the balance sheet instead of the amount of good code they write on a daily basis. His questions focused on the WHY of the technology instead of the WHAT. The interviewer asked WHY I made certain technology decisions in my current and previous roles instead of just asking WHAT those technologies we’re. Drilling down into technical details are best left to interviewers during the in-person interview where you can better gauge the candidate’s technical acumen with longer interviews and different interviewers. Quizzing someone on the merits of a DAG search using a queue in a 30 minute phone interview will not tell you much about the candidate.
In-person Technical Interviews with Actual Teammates
I was scheduled to meet 4 interviewers during my in-person interview with Capital One. 2 out of the 4 are actual team members of the potential role I was applying for. In my experience with other traditional tech finance companies, technical interviews are mostly conducted by a senior developer from a different group. This was sometimes due to the lack of technical experience of the hiring team (that’s why they we’re hiring in the first place 😁). Being interviewed by developers of the team was something I really appreciated. Not only was I impressed with their technical experience but I was also entertained with the time I was able to spend talking to them. Interviews are always a two way street. You are not just interviewing for them, they are also interviewing for you.
I’ve been told by other people that most employees in Capital One engineering had a smug startup-y arrogance in them. I have to say those people we’re wrong. Everyone I met that day from the people who greeted me at the door to the most Senior Manager Engineer that interviewed me, we’re very respectful and unassuming. Let’s just say I wanted to work in this environment as it was breath of fresh air not to have to speak to someone who assumed they knew more than I did (even if they we’re most likely right 🤣).
Make Sure to Bring Your Own Calculator (or Make One)
The night before my scheduled in-person interview, a package I was waiting for all morning arrived. I had ordered the M5Stack FACES development kit. This is just the world’s most adorable python REPL. It’s no secret that I hate the python language with a passion but playing around with this development kit made me forget for a little while about python’s annoying tab-indenting rules and other indiscretions.
For me, the M5Stack module is really just a ESP32 that has a 2 inch LCD screen. Full spec details can be found here. It can run micro-python or arduino. They even offer a flow-ui that is very similar to a makecode ui for development. I spent around 70 bucks for it because it had an adorable keyboard (and other interchangeable faces to choose from) in a really nicely designed stack-able housing. Is it worth 70 bucks? Probably not. You should be able to hack together something similar for less than half the price. But it’s just too adorable not to have 😂. I should write a blog post about this development kit once I’ve completed a substantial project with it. For now I’ve only tried flashing it with basic sample programs in both micro-python and arduino. I’ve also installed a NES emulator on it to try and play some retro games. It does work with a scaled down version of a Mario game but as soon as I flash a real NES game on it, that’s when you are reminded that this is an ESP32 device 😒.
What has this all got to do with the Capital One interview you ask? Well, I was lucky enough to have a couple of hours gap before my last interviewer of the day. So I decided to bring this development kit with me to the interview so I can play around with it while waiting. Surprisingly, I could not find any sample code for the calculator face so I decided to write one. I was able to put together a simple calculator program written in arduino. Still very buggy but it can do the basics. Will make sure to put that up in my public github when I am done.
HISHE
For those who don’t have middle school kids, that means “How It Should Have Ended” (look it up on YouTube).
I love the role, the team, the environment, the recruitment process. I would not hesitate to go thru the entire thing all over again or recommend really good developers that I know to Capital One. I am very grateful to the people I met and the experience I gained throughout this entire process with them. It has made me a better person.
Now, if I can only get rid of this song that’s stuck in my head…
Technical Insanities of a Mad Computer Scientist 