To, że dobrze czytasz po angielsku, nie znaczy, że równie swobodnie mówisz. W IT ta luka jest częsta. Czytasz dokumentację, ticket, komentarze do pull requesta, piszesz na Slacku bez większego bólu. Potem przychodzi daily albo rozmowa techniczna i zdania robią się krótsze, niż byś chciał. To nie jest nic dziwnego. Programiści mają dużo kontaktu z językiem pisanym i znacznie mniej z mówieniem na żywo. Dlatego nie ćwicz angielskiego ogólnie. Ćwicz konkretne sceny z własnej pracy.
Michał, który pisał lepiej niż mówił
Michał ma 34 lata. Jest backendowcem w firmie, która wypuszcza produkt na rynek amerykański. Angielski czyta od piętnastu lat: RFC, dokumentacja AWS, wątki na Stack Overflow. Na code review pisze komentarze, które koledzy z zespołu chwalą za precyzję.
W lutym firma przeszła na daily po angielsku, bo dołączyło dwóch inżynierów z Bostonu. Michał zaczął pisać sobie swoje trzy zdania na kartce przed każdym standupem. Czytał je z ekranu. Trwało to czterdzieści sekund i brzmiało poprawnie.
Problem pojawił się poza kartką. Któregoś dnia tech lead zapytał: Wait, why did you pick the queue instead of a cron job? Michał wiedział dokładnie, dlaczego. Miał na to trzy argumenty, przemyślane tydzień wcześniej. Powiedział Because it's better for the load i zamilkł. Decyzję cofnięto na następnym spotkaniu.
Wieczorem napisał na Slacku dwuakapitowe wyjaśnienie. Świetne, konkretne, z liczbami. Tyle że decyzja zapadła szesnaście godzin wcześniej, na głos.
Michał nie miał problemu ze słownictwem. Znał throughput, backpressure i idempotent. Nie miał wyćwiczonego przejścia od myśli do zdania w czasie rzeczywistym. To dokładnie ta luka między rozumieniem a mówieniem, o której Swain i Lapkin (1995) pisały, że domyka ją tylko produkcja własnych wypowiedzi, nie kolejna godzina czytania.
Dlaczego IT ma tę lukę
W branży technologicznej duża część angielskiego jest bierna albo półczynna. Czytasz dokumentację, przeglądasz kod, piszesz krótkie komentarze, śledzisz wątki w ticketach. To buduje rozumienie, ale nie daje automatyzmu w mówieniu.
Kiedy na spotkaniu masz w trzy sekundy opisać błąd, decyzję architektoniczną albo ryzyko, pracują inne mięśnie. Swain i Lapkin (1995) nazwały to hipotezą wypowiedzi: dopiero próba wyrażenia własnej myśli pokazuje, czego brakuje. Nation (2013) dokłada drugi element, czyli różnicę między słownictwem biernym a czynnym. Możesz rozpoznawać dwadzieścia tysięcy słów i używać czynnie ułamka z nich, jeśli nigdy nie wypowiadałeś ich na głos pod presją.
Daily standup: trzy zdania i koniec
Nie próbuj powiedzieć wszystkiego. Schemat jest zawsze ten sam: co skończyłem, nad czym pracuję, co mnie blokuje.
- Yesterday I finished the API integration. (Wczoraj skończyłem integrację API)
- Today I'm working on error handling. (Dziś pracuję nad obsługą błędów)
- I'm blocked by missing access to the staging environment. (Blokuje mnie brak dostępu do środowiska stagingowego)
- I may need help with the deployment script. (Może będę potrzebował pomocy ze skryptem deploymentu)
- If all goes well, this should be ready by tomorrow. (Jeśli nic się nie wysypie, powinno być gotowe jutro)
Na daily liczy się jasność, nie szerokie słownictwo. Te zdania są krótkie i dlatego działają.
Code review i obrona własnej decyzji
Na piśmie większość programistów czuje się pewniej. Problem zaczyna się, gdy trzeba omówić decyzję na callu albo w parze. To scena Michała.
- I chose this approach because it's easier to test. (Wybrałem to podejście, bo łatwiej to testować)
- The main trade-off here is memory usage. (Główny kompromis dotyczy tu zużycia pamięci)
- This solves the issue, but it adds some complexity. (To rozwiązuje problem, ale dokłada trochę złożoności)
- I'm not fully convinced this is the best option. (Nie jestem do końca przekonany, że to najlepsza opcja)
- We could simplify this by dropping the cache layer. (Moglibyśmy to uprościć, rezygnując z warstwy cache)
- Fair point. Let me think about that. (Słuszna uwaga. Muszę to przemyśleć)
Dobra wypowiedź techniczna nie polega na efektownych słowach. Polega na tym, że umiesz nazwać cztery rzeczy: problem, rozwiązanie, koszt rozwiązania i następny krok. Jeśli robisz to prostym angielskim, brzmisz lepiej niż ktoś, kto sypie trudnymi terminami bez struktury.
Gdy ktoś podważa Twoją decyzję, zacznij od zapowiedzi liczby argumentów: There were three reasons for that. Kupujesz sekundę, a rozmówca wie, że mówisz dalej, i nie wejdzie Ci w słowo.
Interview techniczne
Na rozmowie technicznej masz dwa źródła stresu naraz: treść i język. Dlatego opis projektu warto mieć w gotowym kształcie czterech zdań.
- The project was a platform for internal reporting. (Projekt był platformą do raportowania wewnętrznego)
- My role was mainly backend development. (Odpowiadałem głównie za backend)
- I worked on the API layer and improved the data processing time. (Pracowałem nad warstwą API i skróciłem czas przetwarzania danych)
- The biggest challenge was handling large files efficiently. (Największym wyzwaniem była wydajna obsługa dużych plików)
Opis decyzji zajmuje dwa zdania:
- We went with this solution because it was easier to maintain. (Wybraliśmy to rozwiązanie, bo łatwiej je utrzymać)
- It wasn't the fastest option, but it reduced complexity for the team. (Nie było najszybsze, ale zmniejszyło złożoność dla zespołu)
Tyle wystarczy, żeby rekruter zrozumiał Twój tok myślenia. Więcej o strukturze odpowiedzi i o tym, jak nie zaciąć się na pierwszym pytaniu, znajdziesz w tekście o angielskim na rozmowę o pracę.
Refinement, planning i inne spotkania, na których trzeba się wtrącić
Daily jest łatwe, bo masz swoją kolejkę i wiesz, kiedy mówisz. Trudniejsze są spotkania, na których nikt Cię nie prosi o głos, a Ty widzisz, że zespół idzie w złą stronę. Tu potrzebujesz zdań na wejście w środek rozmowy.
- Can I add something here? (Mogę coś dodać?)
- Sorry, just one thing before we move on. (Przepraszam, jeszcze jedna rzecz, zanim pójdziemy dalej)
- I see it a bit differently. (Ja widzę to trochę inaczej)
- That estimate feels low to me. The migration alone took us two weeks last time. (Ta estymata wydaje mi się zaniżona. Sama migracja zajęła nam ostatnio dwa tygodnie)
- Do we have a plan for what happens if this fails in production? (Mamy plan na wypadek, gdyby to padło na produkcji?)
- Could we park this and come back to it after the demo? (Możemy to odłożyć i wrócić do tego po demie?)
Zdanie Can I add something here? jest najważniejsze z całej listy, bo rozwiązuje problem, którego nie da się rozwiązać słownictwem. Daje Ci gotowy sposób na zabranie głosu, kiedy dwie osoby mówią naraz i nie ma naturalnej pauzy. To, co powiesz później, jest wtedy drugorzędne.
Cztery tygodnie treningu
Tydzień pierwszy i drugi to budowanie schematu. Dni pierwszy i drugi: zapisz trzy ostatnie taski, które skończyłeś, i dla każdego przygotuj trzy zdania. Co było problemem, co zrobiłeś, jaki był efekt. Dni trzeci i czwarty: nagraj telefonem trzydziestosekundowy update do każdego taska i odsłuchaj. Zaznacz miejsca, w których brakuje Ci słowa. Dni od piątego do siódmego: pracuj nad długością zdań. Jeśli jedno zdanie trwa dłużej niż piętnaście sekund, podziel je na dwa.
Tydzień trzeci i czwarty to automatyzacja. Codziennie na koniec dnia nagraj minutowy update o tym, co robiłeś, i zapisz nagranie. W środę odsłuchaj trzy nagrania z tygodnia i zaznacz dwa lub trzy powtarzające się błędy. W piątek powtórz na głos te sceny, które wypadły najgorzej.
Carpenter i współpracownicy (2012) pokazali, dlaczego taki rozkład działa lepiej niż jeden intensywny weekend. Long (1996) dodaje, że część treningu warto zrobić z żywym rozmówcą, bo dopiero cudze dopytanie zmusza Cię do przeformułowania zdania w locie. Nagranie tego nie zrobi.
Po czterech tygodniach nie zaczniesz mówić bez żadnego wahania. Zaczniesz mieć gotowy początek zdania w każdej z tych scen, a to jest ta część, która na daily kosztuje najwięcej.
Czego nie robić
Nie ucz się list przymiotników w rodzaju scalable, robust, efficient. Laufer (2005) przypomina, że słowo poznane biernie nie przechodzi samo do słownictwa czynnego. Bez wielokrotnego użycia w Twoim kontekście zostanie w bierności.
Nie czytaj z kartki na daily. Michał tak robił przez miesiąc i to go nie przygotowało na pierwsze pytanie z boku.
Nie tłumacz w głowie z polskiego. Buduj krótkie zdania od razu po angielsku, o czym więcej w tekście o mówieniu całymi zwrotami zamiast pojedynczymi słowami.
Nie odkładaj mówienia do momentu, aż poczujesz się gotowy. MacIntyre i współpracownicy (2003) pokazali, że gotowość do mówienia zależy od kontekstu i poczucia bezpieczeństwa, a te budują się przez używanie języka, nie przez czekanie. Jeśli to Twój główny hamulec, zacznij od tekstu o prokrastynacji przed mówieniem.
Gdy przyjdzie pokazać wynik pracy szerszej grupie, przyda się szkielet z tekstu o prezentacjach po angielsku online.
Źródła i badania
- Kankaanranta & Louhiala-Salminen (2010): "English? Oh, it's just work!" A Study of BELF Users' Perceptions
- Laufer (2005): Focus on Form in Second Language Vocabulary Learning
- Nation (2013): Learning Vocabulary in Another Language
- Carpenter et al. (2012): Using Spacing to Enhance Diverse Forms of Learning
- Swain & Lapkin (1995): Problems in Output and the Cognitive Processes They Generate
- Long (1996): The role of the linguistic environment in second language acquisition
- Spada & Tomita (2010): Interactions Between Type of Instruction and Type of Language Feature: A Meta-Analysis
- MacIntyre et al. (2003): Willingness to communicate in a second language: the effects of context, norms, and vitality
