Test INF.04 — zestaw 7

Dlaczego tak

„Wymagane” to „required”, a „co najmniej 8 znaków” to „at least 8 characters (long)” – pierwsze zdanie oddaje oba warunki poprawnie gramatycznie. „Optional” i „at most” odwracają znaczenie, a „8 digits” zmienia wymaganie na 8 cyfr. Czwarte zdanie zawiera błędy: „is require” zamiast „is required”, „sign” zamiast „characters” oraz nienaturalny szyk „the field password”.

Dlaczego tak

Zwrot „I'd like to move on to…” sygnalizuje przejście do kolejnej części wystąpienia, a „Next” podkreśla kolejność. „To sum up” rozpoczyna podsumowanie na końcu prezentacji, a „Thank you for your attention” ją kończy. Przedstawienie się („Let me introduce myself”) należy do otwarcia wystąpienia, a nie do przejścia między jego częściami.

Dlaczego tak

Definicja mówi o ciągu instrukcji wykonywanym współbieżnie z innymi w ramach jednego procesu – po polsku to wątek. „Nić” i „gwint” to poprawne tłumaczenia słowa thread w słowniku dwujęzycznym, ale w innych dziedzinach – dlatego definicja z kontekstem pozwala wybrać właściwe znaczenie. Proces jest jednostką, w której wątki działają, a nie samym wątkiem.

Dlaczego tak

W programowaniu w parach „driver” to osoba przy klawiaturze, która pisze kod, a „navigator” przegląda go na bieżąco i myśli o kierunku rozwiązania. „Swap roles – you drive now” oznacza zamianę ról: teraz ty piszesz. Dosłowne rozumienie „drive” jako prowadzenia samochodu pomija kontekst pracy zespołowej, a ostatnia odpowiedź odwraca role.

Dlaczego tak

„The name … does not exist in the current context” oznacza, że kompilator nie widzi tej nazwy w bieżącym zasięgu – zmienna nie została zadeklarowana albo zadeklarowano ją w innym bloku, np. wewnątrz pętli lub innej metody. Wartość null powoduje błąd dopiero w czasie działania (NullReferenceException), a nie podczas kompilacji. Niewłaściwy typ i brak dostępu do składowej prywatnej kompilator opisuje innymi komunikatami.

Dlaczego tak

Skuteczne zapytanie składa się z angielskich terminów technicznych opisujących problem: technologii (React), elementu (state array), wykonanej operacji (push) i objawu (not re-rendering). Zapytanie po polsku pominie większość anglojęzycznej dokumentacji i odpowiedzi na forach. Ogólne „why my program is not working” nie zawiera żadnego słowa kluczowego, a kurs dla początkujących nie dotyczy konkretnego problemu.

Dlaczego tak

Kontekst wskazuje, że powstaje proces działający w tle, który co godzinę sprawdza serwer aktualizacji – skoro proces ma później działać, instalator musi go utworzyć i uruchomić. W informatyce „spawn a process” oznacza właśnie utworzenie nowego procesu. Znaczenia „zatrzyma”, „usunie” i „zablokuje” są sprzeczne z dalszą częścią zdania, bo zatrzymany lub usunięty proces niczego by nie sprawdzał.

Dlaczego tak

Strategia kompensacyjna polega na zastąpieniu nieznanego słowa prostym opisem jego funkcji i przykładami – „the program for opening websites, like Chrome or Firefox” jednoznacznie wskazuje przeglądarkę (browser). Opis „the thing… for the internet” jest zbyt ogólny i może oznaczać modem, router czy kabel. System operacyjny to inny program, a strona z wiadomościami to witryna, a nie przeglądarka.

Dlaczego tak

Normy zachowania na spotkaniu online są takie jak na spotkaniu w biurze: punktualność, uwaga poświęcona rozmówcy i niezakłócanie rozmowy – stąd wyciszanie mikrofonu i niewchodzenie w słowo. Spóźnienie bez uprzedzenia okazuje brak szacunku dla czasu klienta. Jedzenie przy włączonej kamerze rozprasza uczestników, a komentowanie klienta na czacie przy udostępnionym ekranie może dodatkowo ujawnić tę rozmowę.

Dlaczego tak

Powierzone dane dostępowe są informacją poufną: przechowuje się je w zaszyfrowanym menedżerze haseł, udostępnia tylko osobom, które ich potrzebują, a po zakończeniu prac zgłasza do zmiany. Plik README w repozytorium i kanał czatu trafiają do wielu osób, także byłych pracowników, i zostają w historii. Hasło wpisane w kod źródłowy jest widoczne dla każdego, kto ma dostęp do repozytorium.

Dlaczego tak

Tajemnica zawodowa obejmuje informacje o kliencie, jego planach i rozwiązaniach technicznych, a umowa NDA wprost zabrania ich ujawniania. Ogólna informacja o technologii i rodzaju pracy nie ujawnia niczego, co chroni umowa. Nazwa klienta, funkcje przed premierą, opis zabezpieczeń i zrzuty ekranu to właśnie informacje poufne – pokazanie ekranów jest ujawnieniem, nawet jeśli nic się przy tym nie mówi.

Dlaczego tak

Etyka zawodowa wymaga uczciwości wobec pracodawcy i klientów: przyznania się do błędu, oceny jego skutków (np. ilu klientów dotyczył) i jego naprawienia. Ciche poprawienie usuwa przyczynę, ale ukrywa skutki – klienci, którzy dostali złe rabaty, nie zostaną poinformowani ani rozliczeni. Czekanie na odkrycie błędu przez innych i przerzucanie winy na testera to zachowania nieetyczne.

Dlaczego tak

Korzystanie z cudzego kodu zgodnie z licencją, np. MIT czy GPL, wraz z zachowaniem informacji o autorach, szanuje prawa twórców i jest wymagane przez prawo autorskie. Kopiowanie płatnego kodu bez licencji narusza prawa autorskie, a zawyżanie kompetencji w CV wprowadza pracodawcę w błąd. Ukryte zbieranie lokalizacji narusza prywatność użytkowników i zasady RODO.

Dlaczego tak

Daily stand-up trwa kilkanaście minut i służy synchronizacji zespołu: każdy mówi, co zrobił, co zamierza zrobić i jakie przeszkody napotyka, aby inni mogli pomóc. Przegląd kodu to osobna czynność wykonywana np. w pull requestach, bo na spotkaniu zajęłaby zbyt dużo czasu. Ocena kolegów nie jest celem tego spotkania, a planowanie długoterminowe odbywa się na planowaniu sprintu lub wydania.

Dlaczego tak

Oczekiwany czas w metodzie PERT oblicza się ze wzoru (O + 4·M + P) / 6, czyli (2 + 4 · 4 + 12) / 6 = 30 / 6 = 5 dni. Wartość najbardziej prawdopodobna ma wagę 4, ale wariant pesymistyczny przesuwa wynik w górę. Zwykła średnia trzech wartości, (2 + 4 + 12) / 3, daje 6 dni, a przyjęcie samego wariantu najbardziej prawdopodobnego pomija ryzyko opóźnień.

Dlaczego tak

Macierz Eisenhowera dzieli zadania według pilności i ważności, a zadania pilne i ważne wykonuje się od razu. Błąd blokujący płatności na produkcji spełnia oba warunki, bo każda minuta oznacza utracone zamówienia. Refaktoryzacja jest ważna, ale nie pilna, więc się ją planuje, newsletter nie jest ważny, a przeglądanie nowości nie jest ani pilne, ani ważne dla bieżącej pracy.

Dlaczego tak

Przy równomiernym tempie zespół powinien wykonywać 40 / 10 = 4 punkty dziennie, więc po 6 dniach powinno zostać 40 − 6 · 4 = 16 punktów. Pozostało 28, czyli o 12 więcej niż na linii idealnej wykresu spalania (burndown) – zespół jest opóźniony. Wartość 28 to cała pozostała praca, a nie opóźnienie, a wyprzedzenie planu oznaczałoby mniej niż 16 pozostałych punktów.

Dlaczego tak

Przy nieprzewidzianym, pilnym zadaniu plan zmienia się jawnie: zespół wykonuje to, co najważniejsze, a o rezygnacji z części zakresu decyduje razem z osobą odpowiedzialną za priorytety. Ukryte nadgodziny maskują problem i prowadzą do przemęczenia. Odkładanie krytycznego błędu naraża klienta na straty, a pomijanie testów przenosi ryzyko na kolejne wydanie.

Dlaczego tak

Rzetelna samoocena opiera się na mierzalnych kryteriach jakości: spełnieniu wymagań, liczbie wykrytych błędów i dotrzymaniu terminu. Porównywanie się z gorszymi nie mówi nic o jakości własnej pracy. Liczba wierszy kodu jest złą miarą – krótszy kod często jest lepszy – a uprzejmość klienta nie zależy od jakości wykonanego zadania.

Dlaczego tak

Zdjęcie jest utworem chronionym prawem autorskim od chwili powstania, a jego publiczna dostępność w internecie nie oznacza zgody na wykorzystanie. Autor może żądać zaprzestania naruszeń, usunięcia skutków i odszkodowania, a w poważnych przypadkach grozi odpowiedzialność karna. Prezes UODO zajmuje się ochroną danych osobowych, a nie prawem autorskim, a wskazanie wyszukiwarki nie zastępuje licencji.

Dlaczego tak

Nieprzechodzące testy sygnalizują, że zmiana może zepsuć działającą aplikację, więc odpowiedzialny programista nie wdraża jej, dopóki nie wyjaśni przyczyny, i uprzedza zespół o opóźnieniu. Wyłączenie testów usuwa ostrzeżenie, ale nie problem. Wdrożenie w piątek wieczorem z błędami pozostawia użytkowników z awarią na cały weekend, a przerzucanie winy nie rozwiązuje sprawy.

Dlaczego tak

Analiza post-mortem prowadzona bez szukania winnych (blameless) skupia się na tym, co się stało, dlaczego proces na to pozwolił i co zmienić, np. dodać test lub alarm. Szukanie winnego sprawia, że ludzie ukrywają błędy, a zespół nie poznaje rzeczywistych przyczyn. Pominięcie analizy i ograniczenie jej do jednej linii kodu nie zapobiegnie podobnym awariom w przyszłości.

Dlaczego tak

Zasłonięte otwory wentylacyjne utrudniają odprowadzanie ciepła, więc temperatura procesora i baterii rośnie, a procesor obniża taktowanie (throttling), aby się nie uszkodzić. Długotrwała praca w wysokiej temperaturze skraca żywotność podzespołów, zwłaszcza baterii. Zasłonięcie wentylacji nie obniża temperatury, a kanapa nie wytwarza pola magnetycznego, które mogłoby uszkodzić dysk SSD.

Dlaczego tak

Automatyzacja obsługi w sklepach to zmiana technologiczna, która jednych stanowisk wymaga mniej, a tworzy zapotrzebowanie na inne kompetencje – serwis, programowanie, nadzór nad systemami. Zmiana logo dotyczy wizerunku marki, a skrócenie godzin otwarcia i przeprowadzka biura to zmiany organizacyjne. Żadna z tych trzech zmian nie wynika z nowej technologii ani nie zmienia struktury zatrudnienia.

Dlaczego tak

Ciągła integracja i wdrażanie skracają drogę od zmiany w kodzie do produkcji: wydania są małe, łatwiej je sprawdzić i wycofać, a poprawka może trafić do klientów tego samego dnia. Automatyczne testy wykrywają wiele błędów, ale nie wszystkie, więc błędy nadal się zdarzają. Potok uruchamia testy, ale ich nie pisze i nie poprawia kodu, a informacja zwrotna przychodzi szybciej, a nie wolniej.

Dlaczego tak

W nieprzewidzianej sytuacji szuka się rozwiązania tymczasowego, które pozwala dalej realizować zadanie, i równolegle usuwa przyczynę – inna forma płatności utrzymuje sprzedaż, a dostosowanie kodu przywróci płatności online. Wyłączenie sklepu bez komunikatu odstrasza klientów. Ukrywanie błędów wprowadza klientów w błąd, a bierność z powodu winy operatora nie rozwiązuje problemu sklepu.

Dlaczego tak

Źródłem stresu jest powtarzalna, długa procedura, w której łatwo o pomyłkę o poważnych skutkach. Rozpoznanie tego źródła wskazuje rozwiązanie: skrypt wykonujący kroki automatycznie albo przynajmniej lista kontrolna, która zdejmuje ciężar pamiętania wszystkiego. Pozostałe odpowiedzi błędnie rozpoznają źródło napięcia, a rezygnacja z dokumentowania jeszcze zwiększyłaby ryzyko pomyłki.

Dlaczego tak

W ostrym, krótkotrwałym stresie najlepiej działają szybkie techniki fizjologiczne – spokojne, głębokie oddychanie przeponą spowalnia tętno i zmniejsza napięcie w ciągu kilku minut. Napoje energetyczne z kofeiną nasilają objawy pobudzenia, a planowanie kariery to działanie długofalowe, które nie pomoże przed wystąpieniem. Unikanie zadania bez uprzedzenia zespołu przenosi problem na innych.

Dlaczego tak

Do najczęstszych przyczyn stresu w pracy należą niejasne oczekiwania, presja czasu i brak wpływu na przebieg pracy – zmiana wymagań tuż przed terminem łączy wszystkie trzy. Jasny zakres zadań, realistyczne terminy, przerwy i wsparcie mentora to czynniki, które stres ograniczają. Dlatego dobre zarządzanie projektem jest jednocześnie profilaktyką stresu.

Dlaczego tak

Zachowanie asertywne polega na jasnym wyrażeniu swojego stanowiska i granic przy jednoczesnym szacunku dla rozmówcy – programista informuje o ograniczeniu i proponuje rozwiązanie. Zgoda kosztem nocnej pracy jest postawą uległą, która zwiększa stres. Odpowiedź z wyrzutami jest agresywna, a przerzucanie zadania na innych bez wyjaśnienia to unikanie problemu.

Dlaczego tak

W mediacji bezstronna trzecia osoba ułatwia rozmowę, ale nie narzuca rozstrzygnięcia – porozumienie wypracowują strony konfliktu. W arbitrażu trzecia osoba wysłuchuje stron i sama podejmuje wiążącą decyzję, co jest częstą pomyłką. Negocjacje bezpośrednie odbywają się bez pośrednika, a unikanie polega na odkładaniu konfliktu bez jego rozwiązania.

Dlaczego tak

Długotrwałe przeciążenie pracą prowadzi do wypalenia zawodowego, którego objawami są wyczerpanie, zaburzenia snu, spadek koncentracji i zniechęcenie do pracy wcześniej dającej satysfakcję. Eustres jest krótkotrwały i mobilizuje, a nie obniża jakości pracy. Więcej błędów wynika tu ze zmęczenia, a nie z braku wiedzy, którą programista wcześniej wykorzystywał.

Dlaczego tak

„Barometr zawodów” to coroczna prognoza zapotrzebowania na zawody w powiatach i województwach, przygotowywana przez urzędy pracy na podstawie danych z rynku – jest to źródło systematyczne i niezależne. Komentarze na forum to pojedyncze, niesprawdzalne opinie. Reklama kursu i nagranie influencera są nastawione na sprzedaż lub promocję, więc nie są obiektywnym źródłem.

Dlaczego tak

Kompetencje społeczne (miękkie) dotyczą współpracy z ludźmi: komunikowania się, pracy w zespole, rozwiązywania konfliktów. Znajomość języków programowania, SQL i systemu Git to kompetencje zawodowe (twarde), które można sprawdzić testem technicznym. Język obcy jest umiejętnością ogólną, a łączenie Gita z pracą w zespole miesza oba rodzaje kompetencji.

Dlaczego tak

W analizie SWOT mocne i słabe strony to czynniki wewnętrzne, zależne od samej osoby, np. jej umiejętności, a szanse i zagrożenia to czynniki zewnętrzne. Rosnące zapotrzebowanie na rynku pracy jest czynnikiem zewnętrznym i korzystnym, więc jest szansą. Jego znajomość C# byłaby mocną stroną, ale sama sytuacja na rynku nie jest cechą tej osoby.

Dlaczego tak

Słowo „dobrze” nie daje się sprawdzić – nie wiadomo, czy cel osiągnięto, dlatego brakuje mu mierzalności; poprawiony cel mógłby brzmieć „do końca grudnia ukończę kurs i napiszę aplikację w Django”. Termin jest podany („do końca grudnia”), więc kryterium czasu jest spełnione. Podstaw Pythona można się nauczyć w kilka miesięcy, a jest to język powszechnie używany w pracy programisty.

Dlaczego tak

Plan drogi zawodowej powinien prowadzić do wybranego stanowiska: ISTQB Foundation potwierdza znajomość podstaw testowania, Playwright i Selenium to narzędzia do automatyzacji testów aplikacji webowych, a projekt w portfolio pokazuje praktyczne umiejętności. Grafika 3D, administracja sieciami i arkusz kalkulacyjny to wartościowe kompetencje, ale dla innych ścieżek zawodowych.

Dlaczego tak

Hackathon wymaga zarówno umiejętności technicznych, jak i współpracy: podziału zadań, komunikacji pod presją czasu, prezentacji wyniku przed jury. Rozwiązywanie zadań algorytmicznych, czytanie dokumentacji i oglądanie kursów rozwijają głównie kompetencje zawodowe, bo wykonuje się je samodzielnie. Są wartościowe, ale nie ćwiczą współpracy z innymi ludźmi.

Dlaczego tak

Gdy sygnały werbalne i niewerbalne są sprzeczne, mowa ciała często lepiej oddaje rzeczywiste nastawienie rozmówcy – zmarszczone brwi i skrzyżowane ręce mogą oznaczać wątpliwości. Dopytanie otwartym pytaniem pozwala poznać zastrzeżenia, zanim zespół zacznie programować. Przyjęcie zgody dosłownie grozi kosztownymi zmianami później, a powtarzanie prezentacji głośniej nie wyjaśnia, co się klientowi nie podoba.

Dlaczego tak

Odzwierciedlenie uczuć polega na nazwaniu emocji rozmówcy i jej przyczyny, dzięki czemu klient czuje się wysłuchany, a rozmowa może przejść do rzeczowego wyjaśniania problemu. Zaprzeczenie i porównywanie z innymi klientami podważa jego doświadczenie i nasila konflikt. Rada o restarcie może być potrzebna później, ale podana od razu pomija to, co klient powiedział.