Wartość certyfikatów z chmury

Post dość ogólny, nie ograniczam się do jednej technologii, ale patrząc w moich kryteriach, to obecnie w ogłoszeniach backendowych w c# coraz częściej jest wpisana znajomość chmury (najczęściej azure, to logiczne), np. na seniora właściwie ciężko chyba o porządne ogłoszenie bez chmury (jakiejkolwiek).

Mam trzy pytanka, miło jakbyście doradzili.

1. Na forum ostatnio przeczytałem post mniej więcej w tym stylu "nie aplikuję na ogłoszenia w .net bez azure, bo inaczej to oznacza że będzie praca w utrzymaniu jakiegoś legacy". Co o tym sądzicie? Według mnie ciekawa teoria i jestem w stanie się nawet zgodzić, bo jednak chmura to pewna umiejętność na przyszłość, chmur jest coraz więcej i coraz bardziej zyskują na popularności z każdym rokiem. Kiedyś przejście na chmurę było w firmie wydarzeniem, teraz po prostu projektując aplikację z góry szacuje się koszta i decyduje na chmurę (jak firmę stać xd).
2. Co sądzicie o przydatności/ważności certyfikatów z chmur w CV? Rzeczywiście jest to atutem? Mowa szczególnie o osobach, które za bardzo doświadczenia z tematem nie miały, chcą się podszkolić i szukać roboty gdzie w firmie chmurują Przykładowo podstawowy az-900 i potem az-204 z azure. Moim zdaniem szczególnie ten drugi to dobry wpis do CV, co uważacie?
3. Może śmieszna teoria, ale czy w firmach nastawionych na pracę z chmurami można liczyć na nieco pewniejsze/lepsze zarobki i lepszy rozwój? Wydaje mi się że skoro stać ich na chmury to też może się tam troszkę lepiej zarabiać. A co do rozwoju to pójście w chmurę to nowe rozwiązania, więc zakładam że w takich firmach odpadają przestarzałe projekty w jakimś .net framework 4.7 tylko zasuwasz faktycznie po najnowsze dostępne technologie i podnosisz umiejętności.

Ja mam jako Java Developer 7 lat doświadczenia.

AWSa Associate Developer
Azure Administraotr
Certified Kubernetes Administrator (CKA)

Na całość jakoś by zdać to jest rok nauki około po godzinach. I najlepsze że certyfikaty wygasają. Miałem je wpisane do CV to nawet odzewu nieraz nie miałem. Traktowali mnie normalnie na rozmowach. Nawet
Nikt o tym nie wspomniał.

Dodatkowo próbowałem się przebranżowić ostatnio na Devopsa to nawet nie miałem odzewu na CV. Pisałem o tym kiedyś.

Z perspektywy czasu nie warto i lepiej robić algorytmy i uczyć się typowo pod rozmowy (np klepać live-coding)

Całkiem możliwe, że to nawet ja pisałem. W świecie.NETa, jak już ktoś w tamtym wątku zauważył, sam C# od dawna nie wystarczy. Możesz albo być full-stackiem z frontem, albo dodatkowo robić coś z devopsa. Ja po ponad 10 latach bycia full-stackiem przeszedłem w działkę mocno devopsową i nie żałuję ani trochę. Już sobie nie wyobrażam powrotu do Angulara.
Czy się opłaca finansowo? Ciężko powiedzieć. Chyba devopsom trochę lepiej płacą i łatwiej mają o pracę, ale nie sądzę, by różnica była miażdżąca. Najwięcej i tak płacą architektom, różnym engineering managerom więc pod kątem kasy najlepiej i tak iść w skille miękkie.

To, co według mnie jest lepsze to ciekawsze i bardziej rozwojowe zadania. Do tego wydaje mi się, że na chwilę obecną jest to kierunek przyszłości. Centrowanie divów w Angularze to jednak najczęściej prostsze zadania, które z powodzeniem robią Hindusi albo Chat GPT metodą prób i błędów w Developer Tools w Chrome. Na chmurze taki tryb pracy nie przejdzie, bo coś spieprzysz albo narobisz kosztów na grube tysiące €. Dlatego słabi devowie unikają chmury jak ognia, więc pracujesz z dobrymi, ogarniętymi inżynierami. Hindusów prawie nie ma, a jak już są, to ci mądrzy.

Co do certyfikatów - rób póki co na początek z jednej wybranej chmury i w tym się specjalizuj. Inaczej to tak jakbyś chciał być naraz C#, Java i Python developerem. Dla Ciebie naturalnym kierunkiem jest Azure. Te podstawowe certyfikaty - oznaczone numerem 900 - nie wygasają i są tanie oraz proste do zdania. Te wyższe kosztują około 100$, ale poważne firmy dadzą Ci na to finansowanie (ja dostałem i jeszcze premię za zdanie, bo dla firmy to duży plus marketingowy do ofertowania oraz jakieś zniżki i programy współpracy z największymi hyperscalerami). Certyfikat Azure ważny jest rok, ale odnawiasz go za darmo, pytają głównie z nowości i można mieć wszelkie materiały, taki internetowy quiz. Czy jest potrzebny? Dobrze wygląda w CV, czasami pytają na rekrutacji, do mojego obecnego projektu warunek konieczny.

Co do firm używających chmury i zarobków - różnie bywa. Czasem dadzą więcej niż rynek, a czasem mniej, bo wiedzą, że projekt ciekawy, technologie przyszłościowe i jest mnóstwo ludzi takich jak ja, co zejdzie 10-15% z wypłaty żeby robić coś takiego. Sam nie uciekłem z firmy mimo słabej stawki bo dostałem szansę na devopsowy projekt i postanowiłem wykorzystać ją i przez rok nauczyć ile się da. Bo z devopsowaniem jest tak, że suche certy nic nie znaczą, musisz mieć to poparte realnym doświadczeniem. Jak tego nie masz, to ciężko będzie w ogóle o rozmowę w takim projekcie.

TL;DR: jak szukasz czegoś ciekawego, ambitnego i przyszłościowego to tak, opłaca się i polecam. Jak chcesz tanim kosztem robić dwa etaty to raczej nie, lepiej idź we frontend.

Raczej dużej różnicy nie robi (opinia subiektywna), rynek za bardzo wybredny.
Na rozmowach o tym prawie nie wspominają.
Podkreślając to na własną rękę - mocnego wrażenia ten fakt nie robi.
Podsumowując:
"doświadczenie z chmurą" > "certy"

Bez praktyki to certyfikaty można sobie powiesić na ścianie i mają małe znaczenie. Żeby jednak całkowicie ich nie deprecjonować powiem tak- jeśli ktoś ma wpisane certyfikaty w CV, to jedno jest pewne- coś mu się chciało robić, więc to jest jakiś plus. Druga sprawa- przygotowując się do egzaminu zawsze człowiek czegoś się nauczy. W bardzo dawnych czasach robiłem jakieś certyfikaty z SQL Server i pamiętam, że ekspertem po tym nie zostałem, ale mimo wszystko sporo nowych rzeczy się nauczyłem.

bulldozer95 napisał(a):

"doświadczenie z chmurą" > "certy"

Jeśli faktycznie tak jest, to bardzo dobrze się składa. Certyfikaty trzeba zdać i obiektywnie je masz albo nie masz, musisz jednak te parę miesięcy posiedzieć choć chwilę codziennie, no i jednak kosztują.
Za to o doświadczeniu można śmiało ściemniać ile wlezie. Tego typu podejście wręcz zachęca do "fake it till you make it".

kelog napisał(a):

bulldozer95 napisał(a):

"doświadczenie z chmurą" > "certy"

Jeśli faktycznie tak jest, to bardzo dobrze się składa. Certyfikaty trzeba zdać i obiektywnie je masz albo nie masz, musisz jednak te parę miesięcy posiedzieć choć chwilę codziennie, no i jednak kosztują.
Za to o doświadczeniu można śmiało ściemniać ile wlezie. Tego typu podejście wręcz zachęca do "fake it till you make it".

Plus ludzie ludzie wrzucą plik na S3 i już mają doświadczenie z chmurą xD Certy wymagają przynajmniej pobieżnego poznania całego ekosystemu, a nie tylko jednej usługi po łebkach. Szczególnie jeśli to nie sa jakieś entry level.

kelog napisał(a):

bulldozer95 napisał(a):

"doświadczenie z chmurą" > "certy"

Jeśli faktycznie tak jest, to bardzo dobrze się składa. Certyfikaty trzeba zdać i obiektywnie je masz albo nie masz, musisz jednak te parę miesięcy posiedzieć choć chwilę codziennie, no i jednak kosztują.
Za to o doświadczeniu można śmiało ściemniać ile wlezie. Tego typu podejście wręcz zachęca do "fake it till you make it".

To akurat jest g**no prawda,

AWS Certified Developer Associate zdałem nie logując się w ogóle ani nic nie klikając. Bazowałem na samym kursie na Udemy + robienie pytań na egzamin w stylu quizów jak na prawo jazdy.

Więc wciąż potwierdza się to że "doświadczenie > certy"

Certyfikaty bardzo pomają się jakoś wyróżnić z tłumu. Np. jak mamy 50 CV na stanowisko mida, to jak ktoś ma certa Azure Solutions Architect albo DevOps Engineer Expert, to automatycznie trafia na górę listy.

Do tego niektóre firmy mogą chcieć to wykorzystać przy negocjowaniu stawki, coś w stylu "u nas senior musi mieć certyfikat ekspercki, Ty nie masz, więc nie damy Ci stawki seniorskiej". W czasach eldorado nie do pomyślenia. Pomijam tutaj sytuacje typu, że klient wymaga, aby ludzie mieli certy.

Z drugiej strony, w Azure robienie certów i tak ogranicza się do kucia dumpów z jakiegoś exam topics, więc z tym, że certy o czymś świadczą, to bym nie przesadzał.

problem z certem jest taki, ze jak go zdasz, a potem 'nie klikasz' i nie uzywasz wiedzy z certa to za pol roku, jakbys go w ogole nie robil.
Ale w cv jest przydatne.
Czasami tez w robocie, jak pokazesz ze w danym polroczu ogarnales jakis cert to moga byc zadowoleni.

Czyli robic certy, ale sie nie podniecac.

Widziałem sporo ogłoszeń na linkedin z wymaganym certem aws architect professional, więc niektóre firmy w ten sposób odsiewają kandydatów.

Po co robić certyfikat z chmury? Ja widzę dwa powody.

1. Wyróżnienie się wśród kantydatów.
2. Dużo firm a szczególnie tych z obszaru konsultingu chętniej zatrudnia ludzi z certyfikatami, ponieważ jest im wtedy łatwiej sprzedać człowieka do klienta. Klienci biznesowi zamawiający produkt czy usługę lubią certyfikaty.

Najważniejsze to wiedzieć, że zdanie certyfikatu nie uczy chmury i po zdaniu certyfikatu dalej g**no wiemy.

W takiej Javie obecnie są dwie drogi:

• 1. Wymiatanie z Javy, springa, hibernete, SQL itd + front JavaScript, typescript, react, angular itd.

• 1. Wymiatanie z Javy, springa, hibernete, SQL itd. plus doświadczenie z chmura oraz dobra znajomość kubernetes/terraform oraz jenkins/groovy.

     co do samej rekrutacji - na seniora przychodzi już 200-300 CV. Odsiejesz ludzi co mają mniej niż 5 lat stażu zostanie 150 CV ludzi co mają 5-10 lat expa. Odsiej zbyt duże wymaganie finansowe zostanie 100 CV. Odsiej ludzi bez mgr inz zostanie 50 CV

     50 kandydatów to i tak sporo, nie każdy zostanie zaproszony więc cert CV daje wam możliwość pójścia na rozmowę o pracę. Zaproszą was ale to tyle, z wiedzy o AWS będą was badać godzinami by wykryć czy go umiecie

     Ale samo to że wrzucacie jakiś plik na S3 czy poprawicie literówkę w yamlu pracy wam nie da. Zaorają was szczegółowymi pytaniami.

     Ja po 2 latach pracy z AWS (mirkroserwisy w EKS, lambdy, kolejki, S3) zostałem wielokrotnie zaorany i wyśmiany na rozmowie. Nie potrafiłem wybronić znajomości AWS bo jedyne co robiłem to łączyłem się z API AWS SDK i kleiłem YAMLe do orchestracji. Dopiero zrobienie certów mi uświadomiło że ja tego awsa nie znam :D

MrówkaBiegowa napisał(a):

1. Na forum ostatnio przeczytałem post mniej więcej w tym stylu "nie aplikuję na ogłoszenia w .net bez azure, bo inaczej to oznacza że będzie praca w utrzymaniu jakiegoś legacy". Co o tym sądzicie?

No tak, a jak w ogłoszeniu jest Azure, to szanse na to, że to będzie utrzymanie legacy wynosi jedynie 90%, więc być może warto.

1. Co sądzicie o przydatności/ważności certyfikatów z chmur w CV? Rzeczywiście jest to atutem? Mowa szczególnie o osobach, które za bardzo doświadczenia z tematem nie miały, chcą się podszkolić i szukać roboty gdzie w firmie chmurują Przykładowo podstawowy az-900 i potem az-204 z azure. Moim zdaniem szczególnie ten drugi to dobry wpis do CV, co uważacie?

U mnie w robocie cisną na robienie certyfikatów, więc można mieć pewność, że to bez sensu.

Aczkolwiek ja bym może nawet zrobił jakiś certyfikat, aby uporządkować własną wiedzę z tego, co na co dzień używam. Chodzi mi o uczciwe podejście do tego, a nie szukanie jakichś zestawów pytań z netu, bo to jest tylko strata czasu.

1. Może śmieszna teoria, ale czy w firmach nastawionych na pracę z chmurami można liczyć na nieco pewniejsze/lepsze zarobki i lepszy rozwój? Wydaje mi się że skoro stać ich na chmury to też może się tam troszkę lepiej zarabiać. A co do rozwoju to pójście w chmurę to nowe rozwiązania, więc zakładam że w takich firmach odpadają przestarzałe projekty w jakimś .net framework 4.7 tylko zasuwasz faktycznie po najnowsze dostępne technologie i podnosisz umiejętności.

Że stawki lepsze, to nie wiem, chyba takie jak wszędzie. Ale chyba też wszędzie używa się chmury - gdzieś jeszcze ta nowość sprzed 15 lat nie dotarła?

Tyle, że technologie to najmniej istotna część rozwoju. Umiejętność pisania i dbania o kod oraz organizacji procesów jest ważniejsza niż lepienie ze sobą technologii.

Biznesowe języki to chleb powszedni i na nich za daleko nie zajedziesz. Bycie developerem z certami cloudowymi nie zaszkodzi. Natomiast nie ma się co czarować, że klepacz aplikacji biznesowych znajdzie zajęcie w platform engineering.

River Boat napisał(a):

Natomiast nie ma się co czarować, że klepacz aplikacji biznesowych znajdzie zajęcie w platform engineering.

Nie trzeba od razu celować w platform engineering i nie o to op pyta. Obecnie duża część pracy programisty to też ogarnianie chmury w stopniu pozwalającym na deploy aplikacji i jej zarządzanie, czyli to co nazywa się DevOps i tu certyfikaty z chmury się przydają, bo pozwalają się wyróżnić w tłumie.

Pracowałem z devopsami, platform engineerami i mit o jakiejś super wiedzy, ekstra doświadczeniu czy elitarności jest mocno przesadzony. Nie raz widziałem devopsa który miał problem z obsługą gita, siedział cały sprinty nad toolem do czyszczenia cache czy wyrzucił pole z bazy danych które odpowiadało za coś istotnego.

Fetysz papierów wynika z natury działalności consultingu który jest dominującym modelem biznesowym w naszym kraju. Niektórzy vendorzy wymagają wręcz aby partner silver, gold czy platinium utrzymał tytuł to musi mieć pierdyliard ężynierów z papierami.

Cloud is just someone else's computer.

Nie wiem czym się tu ludzie zachwycają. Ostatnio musiałem wyklikać lambdę w AWS, nigdy wcześniej tego nie robiłem. Pogadałem z chatGPT, jako że firma używa TF to zrobiłem copy&paste z istniejącej lambdy, puściłem tf plan & apply i poszło. Wrzuciłem swój bundle w TS jako zip i też działa. Na rekrutacji nikt nawet nie pytał czy takie rzeczy potrafię, bo założenie było takie że z dostępem do Google i chatGPT każdy sobie jakoś poradzi.

Oczywiście miałem prościej bo ktoś już wykonał brudną robotę to jest zadbał o security, firewall'e itp. - ale powiedzmy sobie szczerze 90% programistów to raczej brown field a nie green field. A nawet jak się robi green field w chmurze to często wykupuje się gotowy "seed" rozwiązania od zewnętrznego dostawcy żęby nie musieć wszystkiego samemu konfigurować przy starcie od zera.

crestfallen napisał(a):

Cloud is just someone else's computer.

No Ameryki to tutaj nie odkryłeś, tylko co to ma do rzeczy?

Cloud to kolejna warstwa abstrakcji nad tym komputerem którą trzeba poznać żeby się płynnie poruszać.
Tak samo jak na onpremie za taką warstwę abstrakcji (ale na niższym poziomie) można uznać wirtualizatory.

I to że umiesz obsługiwać komputer nie znaczy że umiesz obsłużyć na poziomie enterprise takiego VMWare

Nie wiem czym się tu ludzie zachwycają. Ostatnio musiałem wyklikać lambdę w AWS, nigdy wcześniej tego nie robiłem. Pogadałem z chatGPT, jako że firma używa TF to zrobiłem copy&paste z istniejącej lambdy, puściłem tf plan & apply i poszło. Wrzuciłem swój bundle w TS jako zip i też działa. Na rekrutacji nikt nawet nie pytał czy takie rzeczy potrafię, bo założenie było takie że z dostępem do Google i chatGPT każdy sobie jakoś poradzi.

Nikt nie pytał bo to banał którego nauczy się każdy deweloper po przeczytaniu dokumentacji i sprawdzeniu sampla. Szczególnie że miałeś już przykład w postaci innej lambdy która ktoś wcześniej zrobił.

Oczywiście miałem prościej bo ktoś już wykonał brudną robotę to jest zadbał o security, firewall'e itp. - ale powiedzmy sobie szczerze 90% programistów to raczej brown field a nie green field. A nawet jak się robi green field w chmurze to często wykupuje się gotowy "seed" rozwiązania od zewnętrznego dostawcy żęby nie musieć wszystkiego samemu konfigurować przy starcie od zera.

No tak, i właśnie ktoś kto przygotowuje taką platformę musi mieć rozległą wiedzę z chmury i tutaj często na rekrutacjach certyfikaty są mile widziane.
To czy w danej organizacji jest jakieś Cloud Center of Excellence czy coś w tym stylu to już zależy. W niektórych jest i wtedy rzeczywiście zespoły deweloperskie raczej po prostu wpasowują się w to co już jest zaprojektowane i przygotowane.
W innych nie ma i w ramach prac nad projektem ktoś będzie musiał się wcielić w rolę takiego inżyniera platformowego.

Analogicznym przykładem jest kwestia deploymentu usługi na klaster k8s. Jak ktoś inny cały klaster z konfiguracjami sieciowymi, service meshami, politykami bezpieczeństwa i architekturą wewnątrz klastra przygotował to wrzucenie tam kolejnej apki przez dewelopera to żaden wyczyn. Jak takiej platformy nie ma to deweloper się zesra a nie przygotuje ją w rozsądnym czasie w zadowalającej postaci.

I teraz czy takich rzeczy wymagać od deweloperów? Według mnie nie, ale różnie bywa i nie raz widzę ogłoszenia na człowieka orkiestrę.

Są różne firmy i różne podejścia do tematów clouda czy infry.

Lat temu parę pracowałem w amerykańskiej firmie w której to cloudem zajmowały się rączki z dalekiego wschodu. Jak na gildii architektonznej zapadła decyzja o utworzeniu kolejnego mikroserwisu to top management blokował tę decyzję bo wiedział, że azjatyckie mózgi prędzej przepalą swoje obwody zanim powstanie repo, ci/cd, helmcharty, configi.

Widziałem też jakie masakry robili admini np. od cisco przerobieni na devopsów.

W takich momentach przydaje się posiadanie certów bo można próbować coś zdziałać.

A propos tej rozległej wiedzy która się szybko deaktualizuje i wymaga o dziwo... kupna kolejnego certyfikatu!
Razem z umową na chmurę mamy umowę na support i doradztwo prosto od Amazona, jeżeli czegoś nie potrafimy zrobić lub zastanawiamy się jakich rozwiązań użyć to umawiamy spotkanie i następnego dnia Radish lub inny mu podobny ekspert jest już na zoomie.

Po prostu Ci którzy zapłacili za certyfikaty uważają je za jakieś super achievmenty (znany bias z psychologii). Tymczasem zapytaj kogoś czy wiedza przeczytana a nieużywana się zachowuje? Zrobisz cert a za 6 miesięcy nic nie będziesz pamietał bo twoja aktywność ograniczy się do stworzenia backeta S3 od czasu do czasu...

crestfallen napisał(a):

Cloud is just someone else's computer.

Tak, ale nie zmienia to faktu, że infrastruktura chmurowa która jest abstrakcją na czyjeś serwery jest złożona.

Ostatnio musiałem wyklikać lambdę w AWS, nigdy wcześniej tego nie robiłem. Pogadałem z chatGPT, jako że firma używa TF to zrobiłem copy&paste z istniejącej lambdy, puściłem tf plan & apply i poszło.

Ostatnio, razem z chatem gpt w Databricksach napisałem skrypt w Pythonie (bo nie jestem programistą Pythona, a tym bardziej nie siedzę w Databricksach) który przenosi dane z miejsca A do B robiąc po drodze transformacje, a potrzebowałem prostego joba. Wrzuciłem notebook na produkcje i o dziwo działa. Nie wiem po co ludzie latami się uczą tych Databricksów i Pythona skoro można zrobić copy paste z chata gpt i też będzie działać.

jak się robi green field w chmurze to często wykupuje się gotowy "seed" rozwiązania od zewnętrznego dostawcy żęby nie musieć wszystkiego samemu konfigurować przy starcie od zera.

Co to jest seed rozwiązania? I nie, nic się nie kupuje. Przynajmniej porządne firmy nic nie kupują, tylko wynajmują firmy konsultingowe żeby im ogarnęły landing zone'y i konfigurację kont dedykowaną pod ich firmę bo wiedzą ze rozwiązania które są w marketplace'ach nie są w stanie spełnić ich specyficznych wymagań.

Podsumowując, to że uruchomiłeś lambdę która jest jedną z najprostszych do postawienia usług w chmurze, nie znaczy że chmura jest łatwa.

Razem z umową na chmurę mamy umowę na support i doradztwo prosto od Amazona, jeżeli czegoś nie potrafimy zrobić lub zastanawiamy się jakich rozwiązań użyć to umawiamy spotkanie i następnego dnia Radish lub inny mu podobny ekspert jest już na zoomie.

Rozmawiałeś kiedyś z supportem AWS-a czy Azure na temat propozycji architektury dla twojego rozwiązania? Od tego każdy dostawca ma dedykowanych TAMow- (Technical Account Manager) którzy są do dyspozycji klienta i ich rolą jest prawdziwy konsulting. Support to ci może pomóc rozwiązać problem gdy nie umiesz skonfigurować sobie routing tables albo namieszałeś coś w security groupach. Do tego się jedynie nadają.

Widać, że chmurę to ty widziałeś jak świnia niebo, ale dyskutujesz ostro jakbyś już z 10 lat w niej siedział. Nabierz doświadczenia to pogadamy.

Hatters gonna hate, ale taka jest prawda że wielu rzeczy uczy się w pracy i to jest normalna sytuacja.
To że ktoś przeczytał książkę i zaliczył test ABCDE nie znaczy wcale że umie chmurę. Tak jest panowie i panie, zdanie testu nie znaczy że umie ktoś w chmurę.

Ale z czym ty teraz dyskutujesz?

Czy ktoś tutaj w ostatnich postach sugeruje że wszystkiego trzeba się uczyć poza godzinami pracy, albo że certyfikaty gwarantują jakiś poziom wiedzy?

Jak działałem w firmie którą można podciągąć pod fang to oni wówczas posiadali swoje data center, a w azure i aws używal networkingu oraz compute services na których np. fukcjonował customowy klaster kubernetes ze sporą ilością rozszerzeń.

W branżach regulowanych była potrzebna współoraca między bankiem, regulatorem, vendorem clodowym i consultingiem który spinał całość aby dało się postawić core banking oraz usługi wokół niego w cloudzie.

Jeszcze ciekawiej robi się jak enterprajs działa na rynkach azjatyckich jak Chiny i trzeba zmierzyć się z ich lokalnymi vendorami, complience i innymi dziwnostkami.

Certy warto mieć. Nie jeden ma przez nie pracę w consultingu choć z wiedzą i doświadczeniem różnie bywa niemniej real na infra, networking, cloud są dość skąplikowanymi tematami i każdy przypadek jest dość unikalny pod każdym względem.

crestfallen napisał(a):

Nie wiem czym się tu ludzie zachwycają. Ostatnio musiałem wyklikać lambdę w AWS, nigdy wcześniej tego nie robiłem. Pogadałem z chatGPT, jako że firma używa TF to zrobiłem copy&paste z istniejącej lambdy, puściłem tf plan & apply i poszło. Wrzuciłem swój bundle w TS jako zip i też działa. Na rekrutacji nikt nawet nie pytał czy takie rzeczy potrafię, bo założenie było takie że z dostępem do Google i chatGPT każdy sobie jakoś poradzi.

I do tego ChatGPT można podać rodzaj biznesu, lokalizację klientów, wymagania funkcjonalne i pozafunkcjonalne systemu, a on powie, których usług użyć, w jakiej ilości, i w jakich lokalizacjach?

crestfallen napisał(a):

Po prostu Ci którzy zapłacili za certyfikaty uważają je za jakieś super achievmenty (znany bias z psychologii).

Tu właściwie masz rację, ale chyba tylko dlatego, że nie wiesz, iż za certyfikaty zazwyczaj płacą pracodawcy.