Jak postępować z testami technicznymi rozmowy kwalifikacyjnej, które są absurdalne (np. nieracjonalnie duże zadanie z krótkim terminem)?

Odchodząc od nich.

GS (Goldman Sachs) kiedyś chciał ode mnie małą próbkę kodu, która zeszła do symulatora książki zamówień wymiany. Nic szczególnego, poza pełnym zakresem testu i JAKOŚCIĄ KODU PRODUKCYJNEGO. Dla czegoś, co jest krytyczne, skończyło się na tygodniu pracy testując każdy przypadek krawędziowy, ponieważ ten typ kodu jest niezwykle krytyczny.

Wysłałem rekrutowi ofertę i powiedziałem mu, że jeśli nie zapłaci - nie ma gry.

Niektóre firmy mają głupie pomysły i stawiają śmieszne testy. Twój przykład jest podobny - nie ma żadnego dziwnego sposobu, aby zrobić to w 2 godziny poza tym, że jest już przygotowany. Śmiem twierdzić, że jest to oszustwo na granicy. Prawdopodobnie jest to tylko oznaka komicznej niekompetencji.

Pamiętaj, że to jest IT - a IT to rynek sprzedawców. Tony pracy - żadnych specjalistów. Zachowujcie się tak. Nie radzić sobie z idiotami. Odmawiam wszelkiej pracy kodującej bez wywiadów PRIOR, bo jest inna strona: Wszystkie te “ciekawe, trudne” projekty są i tak tak tak samo głupie. Najpierw chcę wiedzieć, czy chcę marnować swój czas, bo uwielbiam robić projekty, które mi się podobają, a rekruterzy zupełnie nie mają pojęcia, czym są te projekty w dzisiejszych czasach.

Pamiętaj, że kiedy firma przeprowadza z Tobą wywiad, Ty również przeprowadzasz z nimi wywiad.

Użyj testów nierozsądnych jako narzędzia przesiewowego.

Jeśli TEST daje Ci nierozsądne cele i ramy czasowe, zgadnij czego możesz się spodziewać w pracy.

Nie bierz tego do siebie, zły test nie jest użytecznym miernikiem Twoich umiejętności. Jeśli mówią, że twoja praca nie była wystarczająco dobra, a wiesz, że była, to oczywiście nie docenią cię również w pracy.

Ponownie, to nie ty, to oni.

Z perspektywy czasu 20/20. Oto co powinieneś powiedzieć następnym razem:

“Z reguły nie odrabiam żadnej pracy domowej, chyba że najpierw porozmawiam z klientem.”

“Jesteś klientem? Nie, więc połącz mnie z kierownikiem ds. zatrudnienia klienta. I nie, jeśli pracujesz dla HR (nie jesteś klientem, chyba że chcesz, żebym zbudował aplikację związaną z HR).”

“Ok, co ta osoba robi dla Twojej firmy? Czy będzie to osoba, do której będę się zgłaszał w przypadku zatrudnienia mnie przez Twoją firmę? Ok, tak. Chcę porozmawiać z tą osobą.”

Gdy w końcu rozmawiasz z tą osobą, wtedy mówisz coś w stylu:

“Ok, przeczytałeś moje CV? Czy uważasz, że możemy pominąć ten cały projekt take-home?”

Zakładając, że kierownik ds. rekrutacji nadal nie chce go pominąć, możesz powiedzieć:

“Problem w tym, że już wcześniej byłem spalony.

Po pierwsze, nie wiem, czy powinienem po prostu zbudować projekt od zera, czy po prostu ponownie wykorzystać część kodu, wokół którego leżałem? Raz zbudowałem projekt od zera w kilka godzin, ale zostałem skrytykowany za to, że nie mam gotowej do produkcji aplikacji.

A innym razem był mały niedopasowanie wersji, a ich informatycy nie wiedzieli jak poprawić plik konfiguracyjny, aby mój projekt działał”

Ale cokolwiek zrobisz, nie podawaj tego wyjaśnienia rekrutowi. Nie wyjaśniaj i nie uzasadniaj się przed rekruterem. Nie ma sensu tłumaczyć się przed strażnikiem. Im więcej informacji dajesz strażnikowi, tym bardziej prawdopodobne jest, że wykorzysta on te informacje przeciwko tobie, ponieważ z założenia strażnik bardzo rzadko ma prawo iść na ustępstwa, ale z drugiej strony, jego rola polega raczej na szukaniu powodów, aby odsłonić kandydatów.

Więc zakładając, że rozmawiałeś z osobą podejmującą decyzje, menedżerem ds. rekrutacji, któremu będziesz podlegał i zakładając, że otrzymujesz od tej osoby dobre wibracje, mógłbyś powiedzieć:

“Ok, jestem gotów zrobić projekt take-home, ale wolałbym być tam, kiedy mój projekt jest instalowany i oceniany.

Czy myślisz, że moglibyśmy ustawić czas, w którym mógłbym przyjść z moim kodem i ustawić go razem na jednej z maszyn Twojego dewelopera? ”

How about this upcoming Wednesday? […] Będziesz tam? Czy jeden z programistów też tam będzie? “

But again, only do this if you’re getting good vibes from this person. Zaufaj swoim własnym przeczuciom. Jeśli z jakiegokolwiek powodu, czujesz, że używają tego projektu take-home jako leniwy sposób, aby wyświetlić wiele dziesiątków wnioskodawców. Albo jeśli z jakiegoś powodu, czujesz, że próbują wydobyć z ciebie jakąś wolną pracę, aby mogli ją wyprodukować, nie zgadzaj się na pracę domową.

To samo dzieje się, jeśli się pokażesz i nie chcą instalować/przeglądać twojego projektu, kiedy tam jesteś. Jeśli chcą, abyś odrobił ich pracę domową, muszą również zainwestować w Ciebie trochę czasu. Jest to okazanie wzajemnego szacunku.

I jeśli z jakiegoś powodu nie otrzymasz tego szacunku. Na przykład, jeśli zamienili inżyniera, miałeś spotkać się z pracownikiem działu kadr w ostatniej chwili. Bądź grzeczny, ale bądź stanowczy. Nie dawaj im swojego projektu "take-home”. Powiedz im, że chętnie przełożysz rozmowę i odejdziesz.

Nie lubię odwoływać się do innych odpowiedzi w moich odpowiedziach, ponieważ odpowiedzi powinny być zrozumiałe same przez się. Jednak najwyżej oceniona odpowiedź sprowadza się w zasadzie do tego, że “firma to banda idiotów”. Uciekaj od nich.“ To nie daje OP nic, co można by poprawić o sobie samym, ani nic zmienić w przyszłości. Widzę obszary, które OP mógłby poprawić, niezależnie od tego, czy firma zrobiła coś złego, czy nie, czego my jako respondenci tak naprawdę nie wiemy, ponieważ słyszeliśmy tylko jedną stronę historii.

Z tego co widzę, nie komunikowałeś się _zanim rozpocząłeś zadanie, w które mocno wierzyłeś, że nie da się tego zrobić w dwie godziny.

Oto sekwencja zdarzeń, jak ja to widzę:

1. Zostałeś poproszony o wykonanie zadania kodowania
2. Kiedy otrzymałeś wyzwanie, zamiast informować o swoich problemach, zacząłeś kodować
3. Spieszyłeś się z wykonaniem wyzwania, przycinając zakręty
4. Zgłosiłeś projekt niskiej jakości, który nie zadziałał bez większego zamieszania
5. Po otrzymaniu informacji zwrotnej, zacząłeś uzasadniać swoją pracę

Oto jak wyobrażam sobie firmę, która to widziała:

1. Kandydat zaakceptował wszystkie warunki wyzwania
2. Kandydat zgłosił projekt na czas
3. Projekt nie zadziałał
4. Nasz główny programista powiedział, że kod był bardzo kiepskiej jakości
5. Kandydat zaczął wymyślać wymówki za swoją pracę

Wyobraź sobie, że jesteś w sytuacji, w której twój menedżer/ kierownik zespołu prosi cię o wykonanie zadania w nieracjonalnie krótkim czasie. Jeśli nie od razu zgłosisz, że nie jesteś w stanie wykonać tyle pracy w tak krótkim czasie, to każda porażka jest Twoją winą za zaakceptowanie wstępnych warunków. Ty jesteś ekspertem, nie oni, a oni polegają na tobie w komunikacji z nimi.

Nie mogę podkreślić, jak ważne jest, aby obie strony miały wspólne zrozumienie sytuacji. Miałeś niemożliwą do pokonania lukę w zrozumieniu, ponieważ straciłeś okazję, by się nią zająć. Następnym razem, gdy będziesz miał problem, poinformuj o nim natychmiast, albo druga strona pomyśli, że wszystko jest w porządku! Nie przekazanie ważnych informacji jest kłamstwem przez pominięcie, a każda forma kłamstwa jest nieprofesjonalna. To, jak zareagują na informacje, jest ich obowiązkiem, a nie Twoim.

Polecam przeczytać The Clean Coder: A Code of Conduct for Professional Programmers autorstwa Roberta C. Martina (Wujek Bob), w szczególności:

• Rozdział 2: Mówienie Nie
• Rozdział 3: Mówienie Tak
• Rozdział 10: Szacowanie
• Rozdział 11: Ciśnienie

Jeśli firma odrzuca Twój wniosek, ponieważ poprosiłeś o informacje zwrotne i wyjaśnienia przed rozpoczęciem zadania, nie przefiltrowali Cię, you przefiltrowali them jako firma, dla której nie chcesz pracować.

Spotkałem się z kilkoma mądrymi i głupimi testami (SQL/BI) i aktywnie wychodziłem z jednego, który był głupi, tłumacząc, że to, czego chcieli, było złym podejściem.

Widziałem również testy, które były w rzeczywistości próbami wolnego projektu, z “próbną pracą”, która była zasadniczo nowym rozwiązaniem. Znowu odmówiłem ich ukończenia.

Zdarza się, kreślę je na podstawie doświadczenia i idę dalej. Zawsze umawiam się na wywiady po godzinach, więc nie ma żadnej prawdziwej straty z mojej strony.

Cóż, powiedz im dokładnie to, co byś powiedział swojemu szefowi w obliczu tego zadania.

Albo nie wiedzą, co robią, wtedy dowiesz się wiele o firmie, albo chcą zobaczyć, że nie marnujesz czasu (pieniędzy firmy) robiąc rzeczy źle, zamiast rozmawiać z osobą bez wiedzy technicznej, aby to ocenić.

Są dwa wyniki, przechodzisz z latającymi kolorami za robienie tego co właściwe, albo uniknąłeś kuli i nie musisz wracać za dwa miesiące mówiąc nam jak twój szef domaga się rzeczy niemożliwych ;)

Oto moje podejście:

1. Przekaż swojemu kontaktowi w firmie, że nie sądzisz, że jest to możliwe w tym czasie i co zamierzasz zrobić.

2. Jeśli masz czas, aby poczekać na odpowiedź, poczekaj; jeśli nie, zrób to, co zamierzałeś, i szczegółowo udokumentuj swoje wybory

3. Idealnie byłoby naszkicować, gdzie zabrałbyś resztę.

Zauważ, że _wielu ankieterów faktycznie kalibruje i testuje, że zadanie trwa 2 godziny. Jeśli naprawdę chcesz pracę, wziąć go do pewnego poziomu kompletności w danym czasie.

Jak odkryłeś, jakość zazwyczaj tryby dopasowania w czasie, chyba że mają ścisłe mechanizmy, aby zapewnić wszystkich kandydatów pasują w czasie.

To cuchnie fałszywym testem na mapę Twojej osobowości, zwłaszcza tego, jak radzisz sobie z absurdalnymi i stresującymi wydarzeniami. Czy to Ty jesteś tym, który

1. denerwujesz się i odchodzisz, czy
2. to Ty milcząco próbujesz to rozwiązać, czy też
3. to Ty próbujesz kłócić się i wyjaśniać z kierownictwem, co jest nierozsądne, czy
4. tak bardzo się stresujesz, że nie wiesz co robić, czy
5. to Ty udajesz, że próbujesz to rozwiązać, ale dajesz równie absurdalne wymyślone wyniki, bo na to właśnie zasługuje każdy, kto wymyśliłby takie zadanie?

Według mojego eksperta nikt nigdy nie przypisałby tego do dwóch godzin pracy, gdyby była wykonana prawidłowo. Postawiłbym przynajmniej kilka dni, żeby architektura była odpowiednia itd.

Przepraszam, ale nie o to chodzi.

Pomyśl o tym z perspektywy zespołu. Chcą, aby ktoś, kto zna się na ASP.NET, MVC, REST, rozmawiał z bazą danych, a także z umiarkowanie zaawansowaną funkcją jednego autokompletnego textboksa.

Could I get these things done? Tak, w końcu. W końcu usłyszałem te wszystkie rzeczy, więc mogę je wymienić w moim CV. Ekspert taki jak ty będzie w stanie połączyć system pracy w ramach limitu czasowego, ponieważ cały czas masz do czynienia z tym stosem, ale musiałbym spędzić godziny na przekopywaniu się przez podręczniki.

CV to kawałek papieru, na którym wypisywanie punktów kulkowych jest banalne. Zły wynajem jest gorszy niż brak wynajęcia. Zakładam, że nie miałeś osobistej rekomendacji od kogoś z zespołu, więc kierownik ds. rekrutacji szuka dowodu kompetencji. To prawda, prawdziwy system gotowy do produkcji trwałby znacznie dłużej, ale test nie poprosił o gotowość do produkcji, ponieważ zapytał, co byś zrobił z większą ilością czasu. Sukces w teście pokazuje, że jesteś biegły we wszystkich warstwach i co ważniejsze że wiesz, jak nadać priorytet. Spraw, żeby to zadziałało i then żeby było ładnie!

Dwugodzinny test nie jest czasem dla astronautyki architektury.

Co więcej, prawie na pewno nie jesteś pierwszym kandydatem, który zobaczy ten test. Zespół używał i być może wielokrotnie zmieniał swój filtr, a przynajmniej jeden programista przeszedł przez ten test. Podkręcenie nosa - co stało się bardzo modne w ostatnich latach - w słusznym oburzeniu lub “edukowaniu” ich, dlaczego jest to zły test, ich zdaniem, umieści Cię w kategorii bozo. Pomyślą, że inny zwlekacz czy primadonna, z którym nie mamy do czynienia._

Jak sobie z tym poradzić? Spójrz na to z perspektywy twojego potencjalnego klienta. Zamiast odrzucać jako absurd, daj spokój. Na dwugodzinny test zanotuj krótko swoje założenia, przygotuj słoneczny dzień na prostą pracę demonstracyjną, a w pozostałym czasie udokumentuj, jak sprawić, by system był naprawdę solidny.

Ponieważ inne odpowiedzi przynajmniej wskazywały, motywacja stojąca za testem _ może być uzasadniona, szczególnie jeśli test:

1. jest dobrze dostosowany do aktualnych wymagań pracy;
2. Minimalizuje mniej istotne elementy;
3. Najwyraźniej nie jest próbą uzyskania “darmowej pracy”; i być może
4. Zawiera przynajmniej kilka wskazówek, czego recenzenci “szukają”.

W poprzedniej pracy zaprojektowałem i przeprowadziłem prawdopodobnie “absurdalny” test programowania. Była to zawsze praca dla programistów wyższego szczebla, którzy zajmowali się tworzeniem pełnowymiarowych serwerów ASP.NET/SQL, a zadanie polegało na stworzeniu bardzo podstawowej aplikacji internetowej zawierającej jedną stronę i dwie lub trzy proste procedury. Kandydat wykonał test na miejscu przy użyciu standardowych narzędzi:

1. Visual Studio (wersja do wyboru przez kandydata w ciągu ostatnich dwóch lub trzech wersji);
2. SQL Server Management Studio; oraz
3. Przeglądarka internetowa, nie tylko do testowania, ale również do przeglądania dokumentacji, zasobów, itp, którą konkretnie przekazałem kandydatowi do wykonania.

Dostarczyłem kandydatowi podstawowe rozwiązanie “shellowe” (w każdej z dozwolonych wersji Visual Studio), a bazę danych i tabele stworzyłem z wyprzedzeniem.

Podałem kandydatowi jednostronicowy opis i powiedziałem mu, że wrócę za dziesięć minut, aby odpowiedzieć na każde pytanie, po czym będzie miał godzinę na wykonanie zadania.

Kiedy wróciłem po dziesięciu minutach, po udzieleniu odpowiedzi na wszelkie pytania, powiedziałem kandydatce, że jeśli nie będzie pewna, czy jest w stanie ukończyć każdą część zadania w ciągu godziny, może rozważyć skupienie się na części zadania, które może wykonać i rozpocząć bieg w wyznaczonym czasie. Wspomniałem również, że jeśli będzie miała dalsze pytania w ciągu godziny, znajdzie mnie w dwóch boksach dalej i zapyta.

Ponieważ napisałem test, mogę go wykonać od początku do końca w około czterdziestu pięciu minutach. Absolutnie nie spodziewałam się, że kandydaci ukończą cały test w ciągu jednej godziny. Absurdalny" limit czasowy istniał z trzech powodów:

1. Chcieliśmy sprawdzić, czy kandydat ma nawet połowicznie uzasadnione wymagania dotyczące pracy. Pamiętajcie, to było na stanowisko wyższego szczebla. (Przez ponad połowę czasu, odpowiedź brzmiała “nie”)
2. Kandydat powinien być w stanie przeanalizować podstawowe wymagania i podzielić je na wykonalne, dyskretne zadania.
3. Wydłużenie testu o jedną godzinę zajęłoby kandydatce więcej czasu, nie dając nam wiele, jeśli w ogóle, dodatkowych informacji.

Na zakończenie godziny poprosiłem kandydatkę, aby pokazała mi, co ma, czy ma jakąś część działającego rozwiązania do zademonstrowania, itp. Ogólnie rzecz biorąc, poświęciliśmy około pięciu minut na omówienie pracy w tym momencie, po czym kandydatka odbyła rozmowę indywidualną z kierownikiem. Podczas tej rozmowy, zespół ds. rozwoju przyjrzałby się wszystkim, co kandydatka złożyła. My really czekaliśmy na ten obowiązek, ponieważ nigdy nie był nudny.

Jeśli kandydat miał uruchomione rozwiązanie, które obsługuje jego zamierzoną część ogólnego zadania, kandydat prawie na pewno przeszedł tę fazę rozmowy. Nawet jeśli rozwiązanie nie zostało jeszcze uruchomione, gdybyśmy mogli dostrzec znaczący postęp i dowody na kompetencje kandydata, zazwyczaj nadal rozważalibyśmy kandydata. Zawsze sprawdzaliśmy historię przeglądarki kandydata, aby dowiedzieć się, do jakich zasobów miał on dostęp.

Powody, dla których faktycznym kandydatom nie powiodło się:

1. Dosłownie nic nie produkując po pełnej godzinie. Z przykrością muszę stwierdzić, że ta sytuacja zdarzyła się wielokrotnie.
2. Plagiatowanie kodu z obecnej pracy kandydata i próba (i nieudana) jego modyfikacji w celu spełnienia wymagań testu. Kiedy to podejrzewaliśmy, historia przeglądarki by go oddała.
3. Brak możliwości utworzenia łańcucha połączeń w celu połączenia aplikacji z bazą danych. To może wydawać się trochę niesprawiedliwe, ale pamiętajmy, że szukaliśmy kandydatów wyższego szczebla, w tym doświadczenia w tworzeniu SQL Servera. Na pewno nie spodziewaliśmy się, że kandydat będzie pamiętał jak zbudować łańcuch połączeń, ale spodziewaliśmy się, że będzie w stanie szybko go sprawdzić. ConnectionStringBuilder również byłby w porządku, ale nikt nigdy go nie używał. Pierwszy przykład z https://www.connectionstrings.com/sql-server/ sprawdziłby się idealnie.

Była jeszcze jedna część rozmowy kwalifikacyjnej z kierownikiem i zespołem rozwojowym razem i zadawalibyśmy pytania o rozwiązanie kandydata, jak podszedłby do reszty projektu, etc.

Podsumowując, radzę rozważyć motywację pracodawcy do przeprowadzenia “absurdalnego” testu przed zwolnieniem go z pracy.

Ta odpowiedź nie stwierdza, czy tego typu testy są dobre, czy też nie (lub czy się na nie zgadzam), ale skupia się na konkretnym pytaniu._

Jak mogę zdecydować, czy powinienem przeprowadzić testy techniczne, które uważam za absurdalne (e. g. nierozsądnie duże zadanie z krótkim limitem czasowym) w przyszłości?

Tak jak zrobiłbyś w realnym świecie:

• Podaj, ile czasu zajęłoby wykonanie zadania.
• Ułóż swój plan co zrobić w danym czasie (tzn, rób mniej, albo rób to gorzej, albo jedno i drugie).

• Rób tyle, ile możesz, do najniższego poziomu jakości, jaki możesz mieć w żołądku. Skoncentruj się na znalezieniu działającego rozwiązania przed jego ukończeniem.

• Udokumentuj wyraźnie, gdzie ciągniesz się na skróty, jakie są tego konsekwencje i wynikające z tego TODO.

Wszystko to bardzo pomoże mi, jako pracodawcy lub klientowi, ocenić, czy chcę z tobą pracować.

W zależności od struktury zarządzania pracodawcy/klienta, zatrudniający cię facet (tzn. twój bezpośredni szef/klient) może być w sytuacji, w której nie będzie miał wpływu na to, jaką pracę dostajesz. Zarządzanie matrycą istnieje… w tym przypadku wolałbym mieć kogoś, kto potrafi poradzić sobie z takimi sytuacjami z gracją nad bohaterem, który dostarcza największy kod wszechczasów, ale nie jest w stanie komunikować się o ograniczeniach czasowych/jakościowych.

Dokładna miara tego, czy iść po więcej jakości, czy po więcej treści, zależy od tego. Na przykład, w twoim przypadku, prawdopodobnie najbardziej zainteresuje cię to, że możesz dostarczyć wysokiej jakości pracę. Możesz więc wyciąć kilka funkcji (poprzez użycie jakiegoś placementu itp.), ale utrzymać wysoką jakość swojego kodu. Podobnie, gdyby praca była, powiedzmy, związana z bezpieczeństwem, zrobiłbyś to samo. Ale jeśli jest to całkowicie bezkrytyczny dowód na to, że coś jest pomysłem, to można by pójść bardziej w drugą stronę. Udokumentuj to wszystko (zwięźle), i jesteś na dobrej drodze.

PS: Lubię unikać “szalonych lub złych” osądów. To znaczy, nie powinieneś się przejmować tym, czy klient jest po prostu szalony, czy po to, żeby cię dopaść (to znaczy, żebyś wykonywał pracę za darmo), oceniając wyłącznie na podstawie wielkości zadania. Liczy się realna ilość, która ma dla ciebie znaczenie, to twój czas, a która została ustalona. Tak długo, jak jesteś w stanie zainwestować te dwie godziny w potencjalnego nowego klienta, nie powinno mieć znaczenia, czy zadanie jest łatwe do wykonania, czy praca pod dużą presją, czy tylko dwie godziny małych rozmów w ich biurze.

Nie ma absolutnie nic złego w 2-godzinnym szalonym teście technicznym. All inni kandydaci musieliby zrobić ten sam test, więc twoje prawdopodobieństwo, że dostaniesz tę pracę, nie różni się od łatwego, początkującego programowania. Nie było stronniczości; poproszono cię o to po prostu dlatego, że zgłosiłeś się na to stanowisko.

Jesteś sprzedawcą na rynku pracy, a twoim obowiązkiem jest jak najlepsze dopasowanie się do nabywców. Masz niewielką siłę przetargową poza pójściem na inne stanowisko. Z pewnością nie jest nierozsądny test programistyczny, który musieliby wykonać kandydaci all, bez względu na to, czy rzeczywiście możesz z nim konkurować, czy nie. Jeśli masz wysokie kwalifikacje do tej pracy, ale nie jesteś w stanie ukończyć testu, inni kandydaci również nie byliby w stanie go ukończyć. Więc jaki jest problem?

Starasz się jak możesz. Gniewasz się, że nie zaproponowano ci pracy na tym stanowisku? Firma musi kogoś zatrudnić, aby ktoś inny mógł wykonać lepszą pracę. Celem niemożliwego testu programistycznego jest znalezienie najlepszego wykonującego pracę kandydata. To, czy najlepszy kandydat wykona to ćwiczenie jest nieistotne.

jak mogę zdecydować, czy powinienem przystąpić do testów technicznych, które uważam za absurdalne

Powinieneś czuć się komfortowo przy każdym teście technicznym, jeśli uważasz, że masz umiejętności do tej pracy i wszyscy inni kandydaci musieliby to zrobić. Nigdy nie rób testu obłąkanego, jeśli uważasz, że jest to próba wolnego programowania lub/i dana ci z powodu stronniczości (np. rasizmu).

PS: Nigdy nie wspomniałem, że OP nie jest “dobrze”. @TessellatingHeckler