Started with a call with a recruiter, who was very pleasant. Followed up with another technical screen that was a simple non-Leetcode-style question. Then moved onto the take-home/final interview which was to design a solution to a technical problem and then implement the solution in multiple phases throughout the "virtual onsite." The process itself was straightforward and I appreciate not having to do contrived Leetcode-style exercises to complete the interview process, but the take-home question is poorly designed. They frame the technical problem with language that suggests that the purpose of the exercise is to explore your problem solving and technical solutioning experience, but in reality it felt much more like they wanted a very specific solution and for you to have arrived at that same solution with no input on their end. The problem does give you ample room to demonstrate your decision-making process, but ultimately it feels like they just want to see you arrive at the same conclusions that they would internally, which gives off-putting vibes to me.

There was an online coding assessment with an engineering manager, followed by a take-home assessment, and then virtual onsite interviews that stretched across 2 days (if you aren't evaluated poorly after the first day). The online coding assessment consisted of one question that I would categorize as something between leetcode easy and medium. It involved a custom sort function. The take-home assessment involved writing a document that's similar to but not the same as a design doc for migrating an existing code base to multi-tenant architecture. Beware, during the initial call the recruiter will mention that they pay for the take-home assessment and that Tremendous "isn't like other companies". However, Tremendous didn't actually follow through with this after I inquired about it. I said that I wasn't 100% sure if it was actually mentioned that it was a paid take-home assignment (because I was interviewing with many companies at the time and all of the recruiter calls were blurring together). The response I received was vague and didn't explicitly confirm whether Tremendous pays or not or even whether I was indeed told this initially, which I think reveals a lot about the company culture. The response lacked integrity. It seems more transparent to say something like: "Sorry, we did say that, but have changed our policy in the last couple of weeks since you had the recruiter call". The CEO has a blog post about writing, communication, and multi-tenant architecture that will help with the assignment. However, his post was a bit too opinionated for my liking, even regarding the technical topic. There were too many absolutes that undermined the main points, which makes the post lean towards "bad writing" unintentionally. For example, under the heading "Identify whether candidates are driven by reason or ego", the CEO wrote, "They can create multiple databases. This is an insane approach." He also wrote, "We want the person who’s interested in getting the right answer, rather than proving that their first impulse is right". My first impulse while reading was "surely, there must be valid reasons for multiple databases". Comically and perhaps divinely, I interviewed with a startup around the same time who presented a very good case for why they chose multiple databases (e.g. working with only unicorn clients, unicorn-specific requests, financial and accounting data, AI use cases and security, other business reasons, etc.) Engineering involves managing tradeoffs and it seems like Tremendous does not practice this. Day 1 of the virtual onsite consisted of 2 rounds. One was with the CTO and the other was with a senior engineer. The CTO focused on past work experience and database knowledge. Beware, the CTO will nod his head and reply in the affirmative when you respond to his questions. However, a candidate should not infer that this means that the interview is going well or that you're answering the questions effectively. During this round, I kept asking myself "am I explaining enough?" because I wasn't sure. I felt like I would give a simple response and the CTO would nod and agree, so several times during the interview I wasn't sure if I should go into more detail. I don't believe the CTO was actually nodding and agreeing. I think he was just taking in what I said and assessing it against a baseline (e.g. "The candidate said this, therefore he must know X% about Y topic. Let me adjust."). The second interview consisted of implementing the multi-tenant architecture in the same code base you reviewed for the take-home assignment. I believe you're given 90 minutes, but for some reason, this didn't feel like enough time even though the night before I had listed _every single change and file name_ in my original version of the design doc. I still just barely finished in the given time limit. In a rush, I forgot to add foreign keys to the tenant_id columns. I also copied "has_one" instead of "belongs_to" in two files by accident. When asked how to write something in a more "Rails-like way", I was a bit confused because I was using the built-in Rails ActiveRecord query helpers. But the interviewer was just asking why I didn't use associations (even though he saw that I used associations in the same file in a different method). This interview seemed to go well. I didn't make it to the second day of the virtual onsite because the CTO emailed that it would be a waste of time for Tremendous because I lacked depth of Rails knowledge and database experience. I believe the CTO accomplished the opposite of what was intended by the cancellation. I have about 8 years of full-time Rails experience, but have not worked in Rails since 2019. The interview documentation says that things like this will be taken into account. (I brought it up. No interviewer even asked.) They also say things like they'll "Ground engineering exercises within the scope of the job." This does not correlate with the CTO's feedback nor my experience