Ficha 02 · Speaking, meetings, interviews

Hi team!

**Yesterday**, I completed the product listing page. I implemented
the responsive grid layout, added the filter sidebar with category
and price filters, and integrated the API for fetching products.
I also wrote integration tests covering the main user flows.

**Today**, I'll start working on the product detail page. I'll
focus on the overall structure and the gallery component first,
then move on to the "add to cart" functionality.

**Blockers**: I need the design mockups for the product detail
page. Maria, could you confirm when those will be available?
I'd appreciate having them by tomorrow morning to avoid losing
momentum.

Thanks!

Alternativa mais curta (típica em standups reais):

Yesterday: finished the product listing page (grid, filters, API integration, tests).

Today: starting the product detail page — structure and gallery component.

Blocked: need design mockups for the detail page. Maria, can you send them today?

Características de bom standup: - Específico (não "trabalhei no frontend"). - Conciso (1-2 min de fala). - Action-oriented (não conta histórias). - Identifica bloqueios explicitamente. - Pede ajuda directamente se necessário.

Erros comuns: - ❌ "Worked on the project" (vago). - ❌ "Will continue" (sem dizer o quê). - ❌ Esconder bloqueios (cria atraso silencioso). - ❌ Discutir detalhes técnicos (para after standup). - ❌ Standup com 10 minutos (deve ser ~2 min por pessoa).

a) "Concordo contigo."

Natural English options: - "I agree." (simple) - "I agree with you on this." (specific) - "Absolutely." (strong agreement) - "Same here." (informal) - "Couldn't agree more." (strong)

b) "Posso discordar nesse ponto?"

Natural English options: - "May I push back on that?" - "I see it differently." - "I'd like to challenge that point." - "I'm not sure I agree. Can I share another perspective?" - "I respectfully disagree." (formal)

❌ NOT: "Can I disagree?" (sounds odd, too literal).

c) "Podes explicar melhor?"

Natural English options: - "Could you elaborate?" - "Could you give more detail?" - "I'm not sure I follow. Can you explain that?" - "Can you walk me through that?" - "What do you mean exactly?"

d) "Em resumo, decidimos X."

Natural English options: - "So, to summarize, we decided X." - "To recap, our decision is X." - "In summary, X is our decision." - "The takeaway is: we're going with X."

e) "Vamos avançar com essa proposta."

Natural English options: - "Let's go with that proposal." - "Let's move forward with this." - "Let's run with it." - "That sounds good. Let's proceed." - "Let's make it happen." (energetic)

Princípio geral: - Inglês profissional prefere expressões idiomáticas sobre traduções literais. - Practice listening to native speakers para incorporar naturalmente.

30-Minute Project Kickoff Meeting Script

Opening (3 min):

"Good morning everyone, and thank you for joining today.

I'd like to officially kick off Project Phoenix — our initiative to redesign the customer onboarding flow.

Quick agenda for today: 1. Project overview (5 min) 2. Team introductions (5 min) 3. Roles and responsibilities (5 min) 4. Timeline and milestones (5 min) 5. Communication plan (3 min) 6. Questions and next steps (4 min)

Let's get started. Maria, can you share your screen with the project overview?"

Main discussion (22 min):

During each section:

"Maria has just walked us through the project goals.

Before we move on, are there any questions about the scope or objectives?" (Pause for responses)

"Great, let's talk about team introductions. I'd like each of you to share your name, role, and one thing you're excited about for this project. Maria, let's start with you and go around."

(Round-robin)

"Thank you all. Moving on to roles and responsibilities..."

Active facilitation phrases: - "What does everyone think?" - "John, you've been quiet — what's your perspective?" - "We're spending too much time on this. Let's table it for now and come back to it next week." - "Let me make sure I understand correctly..." - "Action item: Pedro will own this. Pedro, deadline?"

Closing (5 min):

"We're coming up on our time. Let me quickly recap what we covered and the next steps.

Decisions made today: 1. Pedro is the Tech Lead for backend work. 2. Maria is the Product Owner. 3. We'll use Scrum with 2-week sprints starting next Monday. 4. Demo to stakeholders every 2 weeks on Fridays.

Action items: - Pedro: set up the project repository by Wednesday. - Maria: finalize the product backlog by Friday. - I'll send the calendar invites for daily standups today.

Next meeting: kick-off of Sprint 1 next Monday at 10 AM.

Any final questions before we wrap up?

(Pause for questions)

Thank you all for your time and energy. Looking forward to building something great together. Have a productive week!"

Características de boa facilitação:

1. Agenda clara logo no início.
2. Time management (não exceder).
3. Round-robin para garantir participação.
4. Active listening + reformulação.
5. Decisões e action items explícitos.
6. Owners e deadlines definidos.
7. Recap no fim.
8. Next steps claros.
9. Energia positiva apropriada.

Vocabulário de facilitação:

Para começar: - "Let's get started." - "Let me kick things off by..." - "Before we dive in..."

Para mover: - "Let's move on to the next item." - "Let's table that for now and come back to it." - "We're running out of time on this topic."

Para incluir: - "I haven't heard from you, [name]. What are your thoughts?" - "Anyone else want to weigh in?" - "Let's hear from someone who hasn't spoken yet."

Para focar: - "Let's stay focused on..." - "That's interesting but a bit off-topic. Let's note it as a follow-up."

Para fechar: - "To wrap up..." - "In closing..." - "Final thoughts before we adjourn?"

Politely Disagreeing and Proposing Alternative

Bad version (don't do):

❌ "No, that won't work. We should do Y instead." ❌ "I disagree. Y is much better." ❌ "Actually, that's wrong. Let me explain..."

(Sounds confrontational, dismissive, condescending.)

Good version (do):

✅ Step 1 — Acknowledge:

"Thanks for sharing that, [Name]. I can see the reasoning behind X, especially the [specific positive aspect]."

✅ Step 2 — Introduce concerns/alternative:

"I'd like to share a different perspective. I'm wondering if approach Y might work better here, because [reason 1] and [reason 2]."

✅ Step 3 — Open dialogue:

"What do you think? Are there factors I'm missing that make X clearly better?"

Full example:

"Thanks for proposing that, Pedro. I can see how using PostgreSQL would give us strong consistency and a familiar SQL interface, which is valuable.

I'd like to share an alternative perspective: I'm wondering if MongoDB might fit better for this use case, because:

1. Our data structure is actually quite document-oriented (nested objects, varying schemas).
2. We'll need horizontal scaling soon as we grow, which is more natural in MongoDB.
3. Our existing API contracts already use JSON-shaped data.

That said, you've worked more on this than I have. Are there requirements or constraints I'm missing that make PostgreSQL clearly the right choice?

Maybe we could spend 30 minutes comparing the two against our specific requirements?"

Phrases úteis:

For acknowledging: - "I can see your point." - "That makes sense." - "I appreciate the analysis." - "That's a valid consideration."

For introducing disagreement: - "I'd like to push back on that." - "I see it differently." - "Have we considered...?" - "I'm wondering if there's another angle." - "I'd like to explore an alternative." - "Could I propose a different approach?"

For providing reasons: - "The reason I'm hesitant is..." - "My concern is..." - "What about [issue]?" - "Have we factored in [aspect]?"

For opening dialogue: - "What am I missing?" - "What's your reaction to this?" - "Help me understand why X is better."

Princípios:

1. Acknowledge first — shows respect.
2. Use "I" statements — not accusatory.
3. Give specific reasons — not just "I prefer".
4. Invite dialogue — collaborative, not combative.
5. Stay open — you might be wrong.

Em culturas com alta hierarquia (alguns países asiáticos): - Disagreement direct pode ser visto como faltar respeito. - Alternative: ask questions instead of stating disagreement. - "Could you help me understand why X is preferred over Y in this case?" - Permite outro explicar (e talvez ele próprio veja problemas).

Após disagreement: - Se a tua proposta é aceite: agradecer, executar. - Se a do outro é aceite: comprometeres-te totalmente. - Disagree and commit: depois de decisão, executar como se fosse tua. - Não sabotar nem dizer "eu avisei" se correr mal.

STAR Method Answer Example

Question: "Tell me about a time you had a conflict with a colleague."

Answer:

"Sure, I'd be happy to share an example.

[Situation]: In my previous role, I was working on a project with another developer, Mark. We needed to decide on the testing framework for our new microservice. I strongly preferred Jest, while Mark wanted to use Mocha. We had been debating this for several days, and it was starting to delay our sprint.

[Task]: As the senior developer on the project, I needed to find a resolution that both of us could support, while also being the best decision for the project. I wanted to avoid damaging our working relationship.

[Action]: First, I scheduled a one-on-one with Mark, separate from the team. I genuinely listened to his reasons for preferring Mocha — he had years of experience with it and felt confident he could be more productive. I shared my reasons too: Jest had better integration with our existing tooling and more active community support.

Instead of trying to convince each other in the meeting, I suggested we create an objective comparison: we defined 5 criteria (developer experience, performance, ecosystem, learning curve, and CI integration). We rated each framework against these criteria independently and then compared notes.

The result was actually surprising: when we used objective criteria, both of us agreed that Jest was a slightly better fit, but only marginally. We also identified that Mock libraries used with Mocha were superior. So we proposed a hybrid: use Jest for unit and integration tests, but adopt Mocha-style mocking patterns.

[Result]: We not only resolved the conflict but ended up with a better solution than either of us had originally proposed. The project finished on time, with 95% test coverage. More importantly, Mark and I came out of the experience with much better mutual respect — we're still close colleagues today, even though I've moved companies. The team also adopted our 'objective criteria' approach for future technical decisions.

One key learning for me was that conflicts often have better solutions hidden inside them, if we can move from a 'me vs. you' mindset to a 'us vs. the problem' mindset."

Why this answer is strong:

1. Situation: clear context (project, people, problem).
2. Task: clear what was needed.
3. Action: specific actions taken (not vague "I worked on it").
4. Result: measurable outcome (95% coverage, on time) + relationship preserved + lasting impact (team adopted approach).
5. Reflection: shows self-awareness and learning.
6. Authentic: feels real, not rehearsed.
7. Concise but detailed (~2 minutes spoken).

Common pitfalls to avoid:

❌ Vague: "I had a conflict with a colleague. I solved it. We're fine now." (No depth.)

❌ Blame: "My colleague was being unreasonable, so I had to fix it." (Shows you can't see other perspectives.)

❌ No resolution: "We argued, and eventually they left the company." (Doesn't show problem-solving.)

❌ No reflection: just listing facts without showing learning.

❌ Too long: > 3 minutes loses interviewer's attention.

❌ Negative tone: speaking badly about colleague.

Tip: practice 3-5 stories from your experience that can answer different behavioral questions: - Team conflict. - Difficult project. - Mistake you made and learned from. - Time you went above and beyond. - Leadership example.

Each story can be adapted to multiple questions.

Verbalizing Thought Process in Technical Interview

Why think aloud: - Interviewer evaluates how you think, not just final answer. - Shows problem-solving approach. - Allows interviewer to hint or guide. - Avoids long silences (uncomfortable).

Structure:

1. Clarify (1-2 min):

"Let me make sure I understand the problem correctly.

[Repeat the problem in your own words.]

Before I dive in, I have a few clarifying questions:

• What's the size of the input? Are we talking about hundreds, thousands, millions?
• Can the input contain duplicates?
• Should I handle edge cases like empty input or null values?
• Are there any performance constraints?
• Can I assume the input is sorted/unsorted?"

Why: shows you don't just dive in; you understand problem first.

2. Discuss approach (3-5 min):

"Let me think about this for a moment.

[Brief silence, 10-15 seconds is okay.]

Okay, I see a few possible approaches:

1. Brute force: I could iterate through all pairs, which would be O(n²) time. Simple but slow for large inputs.

2. Sort then iterate: if we sort first, we can use two pointers, giving O(n log n) for sorting and O(n) for the pass. Total O(n log n).

3. Hash map: we could store seen values in a hash, giving us O(n) time but O(n) space.

Given that performance is important and we have memory available, I'd go with approach 3 — the hash map.

What do you think? Should I proceed with that?"

Why: shows you consider trade-offs, not just code first thing that comes to mind.

3. Write code (10-15 min):

While coding, narrate:

"Okay, I'm going to start by defining the function signature.

[Write code.]

I'll use a dictionary to track values I've seen.

[Write code.]

Now I'll iterate through the array. For each element, I check if (target - element) is in the dictionary.

[Write code.]

If it is, I found the pair and return the indices. Otherwise, I add the current element with its index to the dictionary.

[Write code.]

Let me trace through with the example input [2, 7, 11, 15] and target 9:

• i=0, num=2: dict is empty. Add {2: 0}.
• i=1, num=7: (9-7)=2 is in dict! Return [0, 1].

Output is [0, 1], which matches expected. Looks correct."

Why: shows you test as you go, catch bugs early.

4. Discuss complexity (2-3 min):

"Let me analyze the complexity.

Time: O(n) — we go through the array once. Each lookup in the hash is O(1) average.

Space: O(n) — in the worst case, we store all elements in the dictionary.

That's a good improvement over the O(n²) brute force, trading time for some space."

5. Discuss edge cases (2 min):

"Let me think about edge cases:

1. Empty array: my code returns no pair. Should we throw an error? Let me check the requirements...

2. No pair found: my code returns implicit None. Should we return an empty list instead?

3. Duplicates: if input is [3, 3] and target is 6, my code returns [0, 1] correctly.

4. Negative numbers: yes, my approach works with any integers."

6. Discuss improvements (1-2 min):

"If I had more time, I could:

• Add comprehensive error handling.
• Add type hints.
• Write unit tests covering edge cases.
• Consider if there's a way to avoid the extra space if memory is constrained.

But for the core algorithm, I'm confident this solution is correct and efficient."

Useful phrases throughout:

• "Let me think about this for a moment..."
• "My initial reaction is..."
• "I'm not sure if this is the best approach, but..."
• "Let me try a small example to verify..."
• "Actually, I see a problem with my approach..."
• "Let me reconsider..."
• "Does this make sense?"
• "What do you think?"

When stuck:

• "I'm not immediately seeing the optimal solution. Let me try the brute force first and then optimize."
• "Can I get a hint? I'm thinking [approach] but feel I'm missing something."
• "Let me work through a small example to find the pattern."

Important: it's OK to be stuck. Interviewers want to see how you respond to challenges, not just success.

Don't say:

• ❌ "This is easy" (sounds arrogant if you then struggle).
• ❌ "I don't know" (without trying).
• ❌ Long silence (let interviewer in).
• ❌ "I memorized this from LeetCode" (even if true).

Do say:

• ✅ "Interesting problem, let me think..."
• ✅ "I've seen similar problems before but let me work through this specific one."
• ✅ "I'm enjoying this challenge."

After getting solution:

• ✅ Discuss trade-offs.
• ✅ Suggest improvements.
• ✅ Ask if there are other approaches the interviewer would like to discuss.

Conference Talk Introduction — "Why Microservices Failed for Our Startup"

First 90 seconds:

"Hi everyone! [Pause, smile.] Thanks for being here today.

Quick show of hands: who here has worked with microservices? [Pause for hands.]

And of those... who has had a great experience? [Pause.] Mixed? [Pause.] And who's lying through their teeth right now? [Laugh.]

My name is João Silva, and I'm the CTO of TechCo. Today I'm going to share a story that I'm not proud of, but that I think will save many of you from making the same mistake.

This is the story of how, two years ago, we made the textbook decision to adopt microservices. We were excited. We had read the blog posts from Netflix, Spotify, Uber. We were going to build the next great scalable architecture.

Twelve months later, our team velocity had dropped by 40%. Our infrastructure costs tripled. We had ten engineers debugging cascading failures every week. And worst of all, our customers were noticing the increased downtime.

Today, I'm going to walk you through:

1. Why we chose microservices — the seductive logic.
2. What actually went wrong — the brutal reality.
3. How we (mostly) recovered — the painful pivot to a modular monolith.
4. The lessons we learned — so you don't have to.

But before we dive in, I want to make one thing clear:

Microservices aren't bad. For the right team, at the right scale, they're transformative. The mistake we made was adopting them for the wrong reasons, at the wrong time, with the wrong team.

So if you're considering microservices, this talk is for you. If you're already there and struggling, this talk is also for you. And if you're a happy microservices user — well, hopefully you'll find some validation, or some warnings for your colleagues.

Let's start with: why did we even go down this path?

[Click to next slide.]"

Why this intro works:

1. Energy and engagement:
2. Smiles, pauses for audience.
3. Interactive (show of hands).

4. Humor early (lying joke).

5. Personal story:

6. "I'm not proud of this..." — humility.
7. First person ("our team", "we").

8. Vulnerable (admitting failure).

9. Concrete numbers:

10. "40% velocity drop"
11. "Infrastructure tripled"
12. "Ten engineers debugging weekly"

13. Numbers make abstract real.

14. Clear roadmap:

15. 4 sections previewed.

16. Audience knows what to expect.

17. Nuanced positioning:

18. "Microservices aren't bad" — avoids strawman.
19. "Right team, right scale" — measured.

20. Avoids alienating happy microservices users.

21. Inclusive:

22. "This talk is for you" — repeated for different audiences.

23. Welcomes all listeners.

24. Curiosity hook:

25. "Why did we even go down this path?"
26. Leaves audience wanting the answer.

Vocabulary used:

• Conversational: "lying through their teeth", "the textbook decision".
• Specific: numbers, metrics.
• Story-telling: "two years ago", "twelve months later".
• Inclusive: "we", "us".

Pacing:

• 90 seconds for intro is good (don't drag).
• Sets up tension (what went wrong?).
• Earns trust (vulnerability).
• Hooks audience for the next 30 minutes.

What to avoid:

❌ Long bio of yourself ("I have a PhD in Computer Science from MIT and 20 years of experience...").

❌ Overly formal ("Today's presentation will examine...").

❌ Apologizing for being there ("Sorry, I'm not a great speaker...").

❌ Vague openings ("Microservices are very important...").

❌ Reading from slides word-by-word.

Pro tips:

• Practice opening until it's natural (memorized but not robotic).
• Stand confidently (even if nervous).
• Make eye contact with different audience members.
• Smile (relaxes you and audience).
• Pause for emphasis.
• Vary tone to avoid monotony.

My Personal English Improvement Plan — 6 Months

Goal: Reach B2 level certified (FCE) in 6 months.

Current level: B1 (based on self-assessment).

Why this matters: - Career opportunities (remote IT jobs require B2+). - Access to technical resources (courses, books, conferences). - Personal growth.

Monthly goals:

Month 1 — Foundation: - Switch phone, laptop, Spotify to English. - Daily: 15 min Duolingo. - Daily: 1 English YouTube video (with English subtitles). - Read 1 English tech article (Hacker News or Dev.to). - Result expected: comfortable with daily English exposure.

Month 2 — Listening: - Continue daily routine from Month 1. - Add: 1 podcast episode (Syntax.fm or similar) per week. - Watch one English series (with English subtitles) — 1 episode per week. - Result expected: better ear for English rhythm and accent.

Month 3 — Speaking: - Start italki classes: 2 × 30 min per week with native tutor. - Practice speaking aloud (read articles, recite news). - Record self speaking on a topic (5 min) and review. - Join Toastmasters chapter in Lisbon (monthly meetings). - Result expected: more confident speaking.

Month 4 — Writing: - Continue all previous habits. - Write 1 blog post per week (in English) on technical topics. - Switch all professional communication to English where possible. - Daily journal (5 min) in English. - Result expected: improved writing fluency.

Month 5 — Integration: - Continue all habits. - Lead 1 technical meeting in English (with my team). - Submit a talk proposal to a meetup in English. - Read 1 technical book in English (start with simpler one like "Clean Code"). - Result expected: comfortable using English in professional contexts.

Month 6 — Certification: - Continue all habits. - Take FCE preparation course (intensive 4 weeks). - Do 5 mock exams. - Schedule and take the FCE exam. - Result expected: B2 certification (FCE).

Daily routine (throughout all months):

Weekly schedule:

Metrics to track:

• Weekly: hours of English exposure.
• Monthly: number of words I can read/write fluently in test.
• Quarterly: mock test scores.
• End of program: official FCE result.

Budget:

• Duolingo: free.
• italki classes: ~15 €/hour × 2/week × 26 weeks = ~780 €.
• FCE exam: ~210 €.
• FCE prep course: ~400 €.
• Books and materials: ~100 €.
• Total: ~1500 €.

Investment ROI:

• Better salary opportunities (1500 € is < 1 month of salary increase potential).
• Personal satisfaction.
• Lifelong skill.

Accountability:

• Tell my partner / friends about the plan (social commitment).
• Find study buddy (another developer learning English).
• Track progress visible (whiteboard, app).
• Reward milestones (when I complete a month, treat myself).

Plan B for setbacks:

If I fall behind: - Reduce ambitious goals temporarily. - Don't quit — just maintain minimum daily contact. - Restart full plan when life allows.

Long-term vision (beyond 6 months):

• Aim for C1 (CAE) in 18 months.
• Apply for international remote jobs.
• Consider speaking at international conferences.
• Read non-fiction books in English regularly.
• Visit English-speaking country for immersion.

My personal commitment:

"I will dedicate at least 1 hour every day to learning English, for the next 6 months. I will not give up. I will track my progress weekly. I will celebrate small wins. I will get back on track when I fall off. I will pass the FCE."

Signed: [your name] Date: [today's date]

Key principles of this plan:

1. Specific (not vague "I'll improve").
2. Measurable (hours, exams, words).
3. Achievable (1.5h/day is sustainable).
4. Relevant (career-aligned).
5. Time-bound (6 months, monthly milestones).
6. Multi-skill (listening, reading, writing, speaking).
7. Daily habits (sustainable progress).
8. Accountability (external commitment).
9. Realistic (acknowledges setbacks).
10. Long-term vision (beyond just this goal).

Most common failure modes to avoid:

❌ Inconsistent: skip days "just this once" → habit dies.

❌ Too ambitious: 4h/day → burn out in 2 weeks.

❌ Only one skill: only listening, never speaking → unbalanced.

❌ Passive only: just watching, never producing → no real progress.

❌ No accountability: only self → easier to give up.

❌ No metrics: don't know if improving.

❌ No fun: only grinding → quit eventually.

Make it enjoyable: choose series you actually like, podcasts on topics you care about, etc. Sustainable > intense.