My experience with Triplebyte

This article reviews my personal experience with Triplebyte, which is widely advertising at Linkedin now. I am not working for them and I was not asked nor compensated in any way to write this. My motivation is to discuss their approach, which is very interesting, and to provide second opinion to what seem to be mostly negative reviews found online. Their approach is very suitable for some engineers but not for everyone, and hopefully this article would help others to decide whether it would work for them.

It started with a click on one of those banners asking you to take a quiz…


You are asked a single question – a very simple one – and then asked to create an account. Some basic data is asked for (name, email, phone number – see below(!), status etc). Then there’s the quiz.

I highly recommend every developer to take this quiz. The quiz is easy for any senior developer (at least the Generalist and Android parts, I didn’t take the iOS), and it lots of fun. Unlike Brainbench back in 2004 when I took it, Triplebyte quiz is straightforward, and does not try tricks like “do you know why printf(“what??!”) compiled with old C compiler prints “what|”?” (see here if you do not know why).

Make sure you read all the answers, the team working on this quiz had good sense of humor, and many wrong answers are genuinely funny to read. I laughed a lot while doing it.

The generalist quiz focuses on generic programming questions (databases, data structures, various languages – Rust, Python, Java, JS, C++). The language structures used are simple, and you can understand what the code is doing even if you don’t really know the language. Android quiz is based on Java (no Kotlin), and mostly has questions about the Android framework, lifecycle. There are 30 questions, and you have two minutes to answer each, but most questions shouldn’t take more than 5-10 seconds to answer.

Overall I would consider the quiz as easily passable for a senior developer. Unfortunately it does not give you the exact score at the end, it only tells you only how did you do. I got “exceptionally well”, and my buddy got “well” on Android.

After the quiz you are asked to provide some time slots to do the 1hr interview.


As most senior developers, I have had my fair share of various interviews covering five different countries. The Triplebyte interview I’d score as 8/10, and this is a very high score.

The interview happens over Google Hangout with screen sharing. This is problematic setup on Linux desktops if you don’t have a microphone (you can connect the USB microphone, but Chrome has issues using it, despite choosing it in settings). If you never used this setup, test it before to make sure it works. You will also need the working developer environment in language of your choice, so doing it on your phone/tablet/Chromebook is not recommend unless you’re proficient in coding there. You will also be clocked, so this is not the best time to try your new keyboard 🙂

Part 1: Coding

The first part of the interview is the coding exercise. Another review stated they were given several options to choose, but in my case I only got a single option, which was to implement a common board game in C++. As an additional challenge, there are some constrains being imposed (for example, you are asked to use an object, even though using the object would only bloat the code in this simple case). I was are also supposed to do it in several fixed steps. This made it more difficult to fit into the allocated 30 minute slot, but it was still doable. The interviewer seem to be mostly interested to see HOW I solve the problem, than to have the problem solved in time.

The coding exercise indeed has the usual “unnatural” appeal, as other reviews complained. However this is common in this situation: the interviewer cannot ask us to write anything complex since there is not enough time. So we end up writing something we’d never write for production. Still it is way ahead of typical “reverse the string/linked list” tasks which for some unknown reason are still popular. Maybe they are felt more “natural”, but unless you happen to be Ulrich Drepper (thank you a lot Ulrich for all your hard work on glibc!!!), you likely never had written a production function to reverse a linked list in your whole career.

Overall it was an interesting example and I managed to finish coding, although the last step did not work due to a small bug which I had no time left to fix.

Part 2: General questions

The second part is technical questioning. Here is where Triplebyte’s approach gets different from others. The interviewer has not seen my resume and knows nothing about me. This means they ask everyone on the same topics, starting from basic questions and going deeper into advanced details if you passed basics. The idea is that interviewer would know well one’s strengths and weaknesses, which would help them to better match you with specific positions later.

This approach has obvious advantage for a junior developer, who has no particular focus and might not know enough whether their knowledge of a specific topic is at basic or advanced level. However for a senior developer this approach loses this advantage – most senior developers I know develop their expertise in a particular area/language/technology stack, and if asked would state this right away. Even more, most senior developers already have pretty good idea of what they’d like to do, so this section felt a bit like some wasted effort. For example, one of my areas of expertise is security, and there were only couple security-related questions, at very basic level.

The questionnaire loosely covered databases (not my strength), HTTP protocol (aced it), some system low level stuff (aced it), and binary tree internals (screwed it). Puzzled of why those things still being asked. I can totally understand questions how various operations on binary trees stay against lists/arrays in complexity, but how exactly they are implemented in libstdc++ I have no idea.

Still the questionnaire was way better than typical “what is the purpose of a virtual destructor”. Which is a reasonable question, but when everyone starts asking it, it feels De Ja Vu. At least please ask instead “what would happen if you don’t make it virtual where you have to?” and “Can you think of two situations where this would not lead to any issues, even if you forgot making it virtual?”.

I was also surprised by lack of questions about software security in general, secure communication, authentication, Coverity, common exploits and other related things. Not even basics like “what kind of vulnerability could be exploited in insecure code if you type “%s” in the username field?” This was strange considering that the list of possible position included security engineers. But the allotted time is indeed too short to cover everything.

Part 3: Debugging

The third part is debugging section. You are given the source code in a language of your choice which includes some tests which fail. Your job is to find out why they fail, and fix the code. You get a very generic description (which is the same for all programming languages) of what this code should be doing, but there is no other documentation (architecture, bug reports) of any kind. The code base is around 1000 lines with very few comments. You are supposed to read the test source code, understand what the test is trying to do and what it expects, and then fix the issue. All the bugs are logic bugs, no crashes/deadlocks/memory issues.

There are four issues, and you got 30 minutes. I only managed to fix one and describe – but not fix – two others.

This was the most confusing task in the whole interview. I have done my fair share of debugging. But this is the first time where you have to study the test code first to recreate the missing bug report. Then study the program logic to understand why this behavior is considered a bug – as there is no any kind of technical documentation describing the code internals. The only way I can think of this applying to real life situation is “everyone who worked on this project has quit, they left no documentation of any kind, not even bug reports – only tests which are failing. You are a new hire and expected to fix those issues today”. But while theoretically possible, this one would not be on top of my “dream position” list.

Part 4: Solution architecting

The last part is high level architecting. You are described a generic scenario (i.e. for example how would you implement Facebook?) and are supposed to describe the backend architecture. You specify which technologies, frameworks, languages and cloud providers you would use, how would you handle scalability once it grows up big, and so on.

In my case this was piece of cake, but I can easily see this to be difficult to someone who has no experience with large scale systems. This is a very specific area of engineering, and certainly not every senior engineer should have experience in it. Some of us prefer to work in totally different areas, and for those engineers this question would make no sense at all.

Interview Summary

As stated earlier, I rate Triplebyte interview quite high. It is mostly focused on practical aspects, and you are evaluated in mostly practical knowledge and skills. Especially the coding part is good, as you are asked to code in your usual working environment (and not on whiteboard, while you trying to remember whether the second argument to memset() is the filler or the buffer size). It is biased toward high scalability/web APIs, so those who working in totally different areas like machine learning might not do it well.

There is also much less of “passing the interview is a special skill you should learn”, which fortunately seem to be a declining trend. Before I sometime wondered whether the company is interested to hire senior developers, or they are interested to hire the people who are great at passing interviews?

Two reasons I did not give the 10/10 are the following. First is the unclear purpose of debugging section (described above). Second is that never during the whole process so far I been asked about what I am interested to do. Instead it seemed like Triplebyte evaluates you on things which you are capable to do. Again, this makes sense for the people who don’t know or don’t care what they’d be doing, but the majority of senior engineers I know usually knows pretty well what they’d like to work on. For those of us it feels like if we were interviewing for an C/C++ embedded engineer position, and been asked ten questions about Visual Basic in a row. Senior developers do not grow simultaneously in all computer science subjects – usually we become experts in couple of subjects, proficient in a few more, and have to google everything else.

After your interview

After the interview I received an email congratulating me with being accepted into Triplebyte. I assume not everyone is accepted, but I do not know what the next step in this case would be. I also received the “Cracking code interview” book from Amazon (thank you!), which was probably a hint 🙂

The congratulations email asks you to login to the portal and fill up more information about yourself. Then – finally – you are being asked what kind of position you’re looking for, and the area (currently offering NYC, SF, SFBA or Remote).

Then you are shown the list of the companies which are “matched” with you. I put “matched” in quotes because at this moment it seems like you’re being shown all the clients, as there were several companies which in my opinion were total mismatch. There were quite a few companies in this list, and you are supposed to mark one or more of them as favorite. Then you mark several open slots in the calendar, letting those companies talk to you. At this moment you only see the companies, and no specific positions. I did not favorite any companies there.

The big advantage of Triplebyte’s approach is that every company in this list agreed to accept Triplebyte’s own interview process as their own, meaning if I were accepted, I would skip the usual screening(s) and would go straight to the final on-premises interview. This would be a big time saver shall I decide to apply to several companies in this list at once.

Then after a couple days my profile went public, and I started receiving interview requests from the companies in this list. Was amused that Triplebyte sounded like this was exciting news – in this economy I guess every engineers who has his resume online is receiving at least 3-4 position inquiries a week, even while I mark it as  “not actively looking for a job” – and I’m sure the developers looking for a job receive way more than that. Since I was not interested, and did not want to waste anyone’s time, I had to email Triplebyte and ask them to hide my profile (this is something you cannot do through their web interface). This finished the story.


The only issue I had with Triplebyte is that they start texting your phone number with the copies of all notifications you see in email – and there seem to be no way to stop them except emailing Triplebyte. Please keep this in mind.

However I liked the experience, and this looks like an interesting recruiting model. At this moment it mostly seem to benefit the engineers who either don’t know what they’d like to do, or for whom its not important to find a specific position(s). However if they manage to increase their client pool significantly, it might become very valuable for a much larger audience.

This entry was posted in Uncategorized.

3 Responses to My experience with Triplebyte

  1. Oscar Zweig says:

    This was a great review of the interview process, thanks for taking the time to write about your experience. Not a fan of “Find the Bug questions” either but I can see how it could be a useful skill. When asked to implement the common board game did they give you an option for which programming language you wanted to use or were you required to use C++?

    My favorite part was definitely the test comment at the end lol

Leave a Reply

Your email address will not be published. Required fields are marked *