There are plenty of resources on Reddit about TripleByte. Most of them are unimpressed and seem to think that they are straight up malicious. Here is my opinion on the TripleByte process.
The biggest surprise to me is you are only allowed to take one track. Once you have take then quiz, you are unable to go back and take the quiz for another track.
Keep this in mind if you are considering trying TripleByte. Pick the track you are strongest in.
Sitting in class one day, I got bored with the lecture. Instead of learning about digital circuits as a CS major, I decided to take a stab at the TripleByte quiz for DevOps Engineers.
I am not a DevOps professional. I am a backend developer with a vague understanding of some GitLab pipelines.
The quiz was pretty basic covering four topics:
- Academic CS
- Back-end Web
- Programmatic Problem Solving
- System Architecture
There was nothing in there that I would consider to be DevOps specific, but that could be because DevOps has no formal definition.
Also included were questions about theory like "What does caching accomplish?".
There were 40 multiple choice question. I do not believe the questions vary between quiz takers.
With my strong test taking abilities, I was able to score in the 80th to 100th percentile and score myself a "FastTrack" position. From what I can tell, this just gives me priority choice in interview times.
After your quiz, you are immediately given results that show how you ranked in the four tested areas.
As you can see, I got 5s for everything except Academic CS where I got a 4.
TripleByte also gives you a nice report about your strengths and weaknesses and how to improve in your weaker areas.
This is where I find most people complain about TripleByte. The interview is a 2 hour ordeal, but they do tell you exactly what to expect.
They post an interview guide where they layout the four sections and what will be expected from you.
This interview is then recorded and reviewed by a panel. When you are done, they will email you the results and update your profile on their page with very detailed feedback on your interview.
I have already be told that they will not be working with me to find a job, but they have not yet given me my feedback yet. I have friends who have gotten the feedback though and are very pleased with what they saw.
Knowing I was in over my head, I reached out to Ian Coldwater on Twitter about DevOps hoping their followers would give me some helpful tips. Shoutout to
The scripting portion was rough for me. I know all the theory and what is possible, I just don't know the syntax off the top of my head.
I probably fell flat on my face because I had to look up very basic things like how a map works in Python or syntax for an awk script.
There were 5 parts to the programming section all working off of the same log file. They mention upfront that you are not expected to complete the entire thing (you only have 30 minutes). My friend I mentioned before is working with TripleByte and failed to even complete the first task.
A lot of grievances come from how the short-answer discussion is conducted. They cover a range of topics and slowly ask more and more in-depth questions. Their goal is plainly stated and clear. It is to see the breathe and depth of your knowledge.
They will keep asking questions about a specific topic until they find one that you can not answer. This is in order to determine where your knowledge stops.
Other interviewees have expressed greatly disliking this portion and felt that the interviewer is merely asking questions until you can not answer them to prove that you don't actually know the topic. This is plainly not the case.
This was another problem for me. As a college student, I really don't have any projects that I can talk too much about. I have an impressive code base, but I didn't work on the infrastructure or design of the projects. I just coded them for the companies I did my internships with.
This likely would've been fine for their generalist track, but now what they were looking for the DevOps track.
Make sure you pick a project that you had the most control over the design and architecture of. This includes how the different components interacted with each other and where you chose to host it.
Also be ready to explain why you made the choices you made along the way. They care about that for the DevOps interview way more than the technical challenges you overcame in the code.
This was pretty easy. They give you a mock project and ask you how you would break it up and deploy it.
Be ready to make decisions based off of performance and cost.
I felt pretty good about the interview all things considered and was pretty bummed to see that they didn't want to work with me. It was a good experience interview wise for relatively low stakes, so I suggest you give it a shot!
The resources they offer you regardless if they work with you or not made it well worth my time and could be worth your time. Especially if you aren't use to technical interviews (this was my first interview).