What a technical screen tests

A technical screen isn't a trivia contest. Nobody is trying to catch you not knowing the ninth argument to String#gsub. A 30-to-45-minute call with an engineer, or a recruiter and an engineer, exists to answer one narrow question: can this person hold a normal conversation about code without falling apart? That bar is much lower than "knows everything about Ruby on Rails." It's also a different bar from the one most beginners prepare for.

The shape of a typical screen

For an internship or a first junior role, the call usually has three parts. First come five to ten minutes on your background: what you built, what you're learning, why you're applying. Next come fifteen to twenty-five minutes of technical questions. Some are conceptual ("what's the difference between id and class in CSS?"), some ask you to read code ("what does this method return?"), and occasionally there's a tiny live-coding exercise in a shared editor. Last, five minutes for your questions to them. None of it is a surprise if you know the shape in advance, which is why this course exists.

More and more, that shared editor is a browser tool that opens from a link with no local setup. You type, and the interviewer watches in real time. That format rewards candidates who can talk while they type, a skill separate from knowing the syntax.

What is being measured

Four things, roughly in this order of weight for an entry-level screen:

1. Fundamentals, not trivia. Can you explain the box model, or what a Ruby block is, in your own words? Interviewers care less about memorized definitions than about whether the concept has clicked.
2. Communication under mild pressure. Do you narrate your thinking, or go silent and type in the dark? An interviewer who can't see your reasoning can't give you partial credit.
3. How you handle not knowing something. It gets its own lesson, because it's the biggest difference between candidates who pass entry-level screens and candidates who don't, more than raw knowledge.
4. Basic collaboration signals. Do you ask a clarifying question before diving in? Do you take a hint gracefully? These read as "will this person be easy to pair with," which matters a lot for a first hire who will need mentoring.

Notice what's missing: algorithm-heavy puzzles, system design and performance tuning. Those come later in a career. If an entry-level screen throws a hard algorithm at you with no warm-up, that says something about the company's process, not about your preparation.

Why the bar is set this low

Companies hiring interns and first-year juniors know you don't have production experience; that's the premise of the role. They want to know three things. Will you be trainable? Will you be honest about blockers? Do you have the fundamentals to absorb code review instead of repeating the same mistake five times? A candidate who says "I'm not sure, let me think out loud" and reasons toward a sensible answer reads as more hireable than one who freezes. They also read as more hireable than one who bluffs and gets it wrong.

Typical 30-45 min entry-level technical screen
-----------------------------------------------
[ 5-10 min ]  Background & projects
[ 15-25 min]  Technical questions (concepts + code reading)
              + maybe one small live-coding exercise
[ 5 min    ]  Your questions for them

Remote by default

Most entry-level Rails screens now happen over a video call with a shared browser editor, wherever the company and the candidate are. If you interview from Brazil for a remote role, expect the same format as anyone else. The call is usually in English if the company hires internationally. Estágio (internship) processes at Brazilian companies, though, are often entirely in Portuguese, sometimes with an HR-only call before the technical one. Either way, the content doesn't change: fundamentals, communication and how you handle the unknown.

How to prepare without over-studying

A common beginner mistake is treating an intern screen like a big-tech interview and grinding hundreds of algorithm problems built for a different hiring bar. That effort is real, but it's aimed at the wrong target. Nobody at this level will ask you to implement a balanced binary tree. Spend the same hours like this:

• Have one project you can describe in specific, technical detail for five minutes: its data model, one bug you fixed, one decision you'd make differently now. "I built a to-do app" invites vague follow-ups; a specific project invites specific ones you can answer well.
• Learn the topics of the next three lessons (HTML and CSS, Ruby, Git) well enough to explain each out loud. Recognizing it on a multiple-choice quiz isn't enough. Recognizing and explaining are different skills, and a screen tests the second.
• Do one full practice run out loud, even alone. Say your answers instead of thinking them. The gap between "I know this" and "I can say this clearly under a little pressure" is what a real screen exposes, and ten minutes of practice closes much of it.

Where this course goes

This lesson set the frame: a technical screen tests fundamentals, communication and composure, not encyclopedic knowledge. The next six lessons build on it:

• Lesson 2: HTML and CSS questions at intern level.
• Lesson 3: Ruby questions you will get.
• Lesson 4: Git and workflow questions.
• Lesson 5: Answering when you don't know.
• Lesson 6: Questions to ask the interviewer.
• Lesson 7: a full mock screen that puts it all together.

By the end, the format won't be a mystery. It'll feel like a conversation you've already had once.