This test should take roughly 60 minutes. Sometimes it goes over to discuss feedback. It will be conducted on stackblitz.com via google meets. You should familiarize yourself with stackblitz (specifically the vite/react/typescript boilerplate, how to use it, how to check the console and terminal, basically learn how to use it as an IDE) and enable your screenshare permissions in your preferred browser. The last thing you want is to be caught off guard, lose time, become flustered and lose your concentration with this sort of basic preparation.
You will be allowed to use any documentation you want.
Using LLMs is not allowed.
THIS IS NOT A LEETCODE TEST. We will not ask you to do dumb stuff like invert a binary tree or make you figure out the time complexity of some random algorithm.
This is not a dumb brainteaser test. We won't ask questions like "if you made a stack of tacos that reached the moon how much would the combined amount of lettuce in all the tacos weigh?" You're interviewing for a software engineering position not a biz analyst, PM, consultant, CEO, televangelist, neo-pagan divination prophet, or data scientist role.
This is not a rote memorization/trivia test. We will not ask you questions that can answered with a simple search. This isn't jeopardy.
This is not a typescript test, though the test makes use of typescript files, so don't worry about typescript errors.
Overall this test is meant to highly mimic the type of work you will be doing day to day at TableCheck. The test includes a number of modified problems of actual bugs/features we have had to solve and implement here. Therefore, this test attempts to serve as an indicator of your liklihood of success here.
We will be judging you on a number of criteria, very similar to how we define our engineering first principles and software engineer core competencies
(1) Reading comprehension and communication skills. Can you read a ticket with perhaps ambiguous requirements and clarify what the problem is? Can you have an articulate technical conversation with other engineers? You shouldn't flail around and speak in ambiguities (like, "the thing does some weird stuff") when asked to describe the core technical cause of a bug/problem. Clear communication is absolutely necessary.
(2) Programming/engineering fundamentals. I'm not concerned if you don't have the React fiber algorithm memorized, you can learn that if you want. But you should have your js fundamentals mastered. What exactly counts as "fundamentals" is not within the scope of this interview either. As an engineer, you are largely responsible for taking the initiative to learn. Your manager is only there to give you the tools/resources to do so, hold you accountable for learning, and nudging you towards the path that will guide you towards a fruitful career.
(3) Problem solving/engineering skills and attention to detail. Can you think like an engineer? Can you take a big problem and break it down into smaller problems? Is your thought process rational and methodical, or do you flail around randomly smashing your keyboard and adding random console logs in hopes that something will work?
(4) Debugging, attention to detail, perseverance. When bugs arise, the best engineers read the entire error message without hestitation and are not afraid of digging into things they do not know. You shouldn't freeze and lay down to die if you see an error you do not understand. As Kirk Lazarus once said, "survive". It is not your coworkers responsibility to read an error message for you, that is up to your attention to detail. But your coworkers can help point in the right direction or prevent you from wasting hours going down the wrong debug path.
(5) Delivery, quality. Can you actually finish the problems in the alloted time? Did you waste too much time refactoring or on premature optimization instead of just trying to get the thing working? Conversely, how clean is your code?
- Stay calm. If your inabiltiy to stay calm affects your focus, things won't go well. Interviewing is ultimately a numbers game. I have failed many interviews in the past, and I'm still alive. Just relax, it will be ok. This online coding interview is not meant to bully you or make you feel stupid. That sort of behavior is not tolerated at TableCheck anyway. This test is simply an attempt to assess how you'd perform on the day to day job.
- Focus on quality over speed. Again, relax. If you try to rush through the implementation without understanding the problem, there's a good chance you'll misread the ticket and end up implementing something completely wrong and irrelevant to the actual problem. Understand the problem fully before coding a single line. In real life if you are not skeptical of your own cognitive blind spots you'll end up wasting hours or days on some problem that could have been avoided if you just re-read the ticket again, or asked for clarification. I've done this, every engineer has. Slow down, and do a meta-reflection on your own understanding of the problem. Do you really get it?.
- Don't give up. "I don't know" isn't an option. Understand the problem, break it down into smaller problems, and figure out a solution.