What mid-level means to interviewers

The question that changes at the whiteboard

As a junior, you got asked "what is N+1, and how do you fix it?" As mid-level ("pleno" in Brazil), you get the same question with an extra clause bolted on. "You've got an index page that loads a course and each of its lessons. When do you reach for includes, when would you accept the extra queries anyway, and how would you find out in production if you guessed wrong?" The first question tests whether you've seen the concept. The second tests whether you can reason about a system you don't fully control, and whether you know how to check your own answer once the code is live. That second shape is the whole subject of this course.

From "do you know X" to "when would you use X, and what breaks"

A junior interview mostly checks whether your mental model matches the framework. Does a validation run before or after the database call? Does a redirect issue a new request? Does includes avoid N+1? A mid-level interview assumes you already know those mechanics; the junior-level "Junior Rails interview questions" covered them, and this course doesn't repeat them. It spends its time on what happens once the mechanics stop being the hard part. The hard part at mid-level is choosing between two correct answers. Retry a failed job or let it die. Cache an expensive query or accept the read cost. Wrap five operations in one transaction or in three smaller ones. Add an index or rewrite the query. Every one of those choices carries a real trade-off, and an interviewer wants to hear you name it out loud before landing on an answer.

What this course assumes you already have

The junior-level "Junior Rails interview questions" already covered the request cycle, ActiveRecord validations, and REST routes and controllers. It also covered SQL and N+1 (including includes, preload and strict_loading) and the basics of RSpec versus Minitest. If any of that feels shaky, that course is the right place to go before this one. This course names those topics by their exact terms and moves straight past them, on the assumption you already own them cold.

The five areas a mid-level interview probes

Across current interview loops for a mid-level Rails role, the same five areas come back again and again. Background jobs, and everything that goes wrong once work moves off the request cycle. Caching, and the specific bugs caching introduces. Transactions and locks, once more than one process touches the same row. Security, once you're the person expected to catch a vulnerability before it ships. And testing strategy, once "does it pass" stops being the only question and "what should even be tested here" becomes part of the job. This course spends one lesson on each of the first three and one each on security and testing strategy. It closes with a full mock interview that moves between all of them the way a real one does.

Trade-offs over correctness

Watch for the shape of a mid-level question. It rarely has one right answer, and the interviewer is usually less interested in which side you land on than in whether you can defend it. "Should this be a background job?" has a real answer, and it depends on three things. Is the work slow? Can it fail independently of the request? Does the user need to see the result immediately? A strong candidate says all three out loud before picking a side, rather than reciting "always background it" as a rule.

A concrete example: the same bug, two depths of answer

Take a single bug report: "users report duplicate lesson completions." A junior answer names the fix: add a uniqueness validation on lesson_id scoped to user_id. A mid-level answer keeps going. That validation runs a SELECT before the INSERT, so two requests a few milliseconds apart can both pass the check before either one inserts. The validation alone doesn't close the gap under real concurrency. The mid-level answer adds a unique index at the database level behind the validation. It also names the exception the second concurrent insert raises once that index exists: ActiveRecord::RecordNotUnique. Lesson 4 walks through that example using this app's own code. It is a clean illustration of the gap between "I know the term" and "I know where the term stops protecting you."

The Brazil layer: pleno expectations and English interviews

"Pleno" carries slightly different weight depending on the company. A Brazilian company usually maps it directly to years of experience and scope of ownership. A global remote company sizing you against "mid-level" or "intermediate" may expect the same depth in English, live, with no chance to rehearse the phrasing. Practicing these answers out loud in English, beyond reading them, is worth the extra step if a global remote role is on your list.

How to use the next six lessons

Each of the following lessons has the same shape. First, what the interviewer is probing underneath the question. Then three to five concrete questions, with what a strong answer contains. Then the classic mistakes that give away a shallow answer. Last, a real code example from a running Rails codebase rather than a toy snippet. A mid-level interviewer can tell an answer rehearsed from a blog post from one grounded in code you've reasoned about.

Where this course goes

Lesson 2 covers background jobs: retries, idempotency, and the trade-off between Solid Queue and Sidekiq. It also covers the race between a database transaction and a job that gets enqueued before it commits. Lesson 3 covers caching and performance: low-level caching, fragment and Russian-doll caching, and the discipline of measuring before optimizing. Lesson 4 covers transactions, locks, and data integrity: what rolls a transaction back, pessimistic versus optimistic locking, and why a unique index still matters behind a uniqueness validation. Lessons 5, 6 and 7 close the course: "Security questions every mid gets," "Testing strategy questions," and "Mid-level mock: putting it all together," which moves between all five areas the way a real interview does.