w nawiązaniu do wcześniejszego posta. Kilka podpowiedzi, czego nie robić, by nie powielać błędów, przez które znani mi kandydaci się wywalili.
AI: - bardzo dobrze znać podstawy (Pythona, AI, algorytmów). O to pyta się najczęściej, o klasyczne algo, klasyczne funkcje i typowe zastosowania - pokazywać tylko kod, co do którego jesteśmy pewni, że umiemy go wyjaśnić (i go rozumiemy) - opowiadać o technologiach, które się rzeczywiście zna, a nie tylko słyszało - chwalić się projektami, które realnie zostały stworzone - szczerze mówić jaką część portfolio robiło ai, a jaką człowiek - nie kłamać, mówić półprawd czy czegoś podobnego. To wyjdzie. Wielkie repo z samodzielną implementacją perceptronu? Spoko, ale miej pewność, że będziesz o nie zapytany, i że musisz wiedzieć, co tam się dzieje - nie przepisywać repo z poradników, szkoleń czy książek, mówiąc, że to nasze - nie pakować się samodzielnie na głęboką wodę np. gadaniem o llmach, transformerach czy innych bertach. Ponownie, w ponad 90% przypadków rekruter techniczny zacznie to drążyć, i może być kiepsko -nie kłamać nt. znajomości chmury, jeśli robiło się tyko szkolenie z niej -nie przekłamywać swojego rzeczywistego wykształcenia i doświadczenia -nie mówić, że się czyta papery naukowe, jeśli się tego nie robi
A co robić: opanować podstawy jak najlepiej się da (Python, AI, algo, plus infra), zrobić kilka dobrych projektów samodzielnie, zrobić kilka certów, ale tylko wartościowych, rozwijać się w różne strony, poznając nowe narzędzia, CZYTAĆ PAPERY, zastanowić się nad jakąś formalną edukacją, nie poddawać się, a będzie dobrze.
Analiza danych i BI: - bardzo dobrze znać podstawy (np. DAX i Excel, czy Python). O to pyta się najczęściej, o klasyczne algo, klasyczne funkcje i typowe zastosowania - pokazywać tylko kod lub projekty, co do którego jesteśmy pewni, że umiemy je wyjaśnić (i rozumiemy) - opowiadać o technologiach, które się rzeczywiście zna, a nie tylko słyszało - chwalić się projektami, które realnie zostały stworzone - szczerze mówić jaką część portfolio robiło ai, a jaką człowiek - nie kłamać, mówić półprawd czy czegoś podobnego. To wyjdzie. NIGDY, POD ŻADNYM POZOREM nie publikować cudzych daszbordów ze zmienionymi danymi, podpisując je własnym nazwiskiem. -nie kłamać, nt znajomości Pythona, jeśli się go nie zna (to jest dość częste, w BI Python jest raczej plusem niż must have, ale wciąż, ktoś na pewno zada pytanie, jeśli powiesz, że znasz) -nie pakować się samodzielnie na głęboką wodę np. gadaniem o AI w BI czy chmurze, czy czymś podobnym, w sposób sugerujący, że się na tym zna, bo rekruter może znać się znacznie lepiej
W skrócie co robić: opanować podstawy jak najlepiej się da (DAX, narzędzie do wizualizacji, czasem Python), zrobić kilka dobrych projektów samodzielnie, rozwijać się w różne strony, poznając nowe narzędzia, poznać którąś chmurę, najlepiej Azure, zrobić kilka wartościowych certów, być na bieżąco z tym co się dzieje w środowisku BI, nie poddawać się, a będzie dobrze.
@peoplearestrange: no np. statystyka opisowa, algorytmy do data mining, proste uczenie maszynowe, kwestie bazodanowe, olapy, kostki, etl, modelowanie itd. Plus algo do wydajności np w wyciąganiu danych z baz
@peoplearestrange no współczesne business intelligence pochodzi z dawnego data mining czy tam data extraction. Lata temu to było robione na relacyjnych bazach. Później się zmieniało. Algorytmy pod spodem zostały przykryte frontem narzędzi do wizualizacji czy etl. Jednak dalej tam są. Przykład algo do sql w bi
@JamesJoyce co do AI to się zgodzić nie mogę, no może na pozycję juniora. Oczywiście, kłamanie nikomu nie pomoże, ale forma rozmowy może wyglądać zupełnie inaczej. Ze swojego doświadczenia i kilku znajomych po zachodnich startupach, zawsze rekruter - TL, CEO, ktokolwiek wyżej niż HRy, średnio interesuje czy powiesz mu to co on już wie. Sprawdzają to co wniesiesz do zespołu poprzez dyskusję, dają nierozwiązywalne problemy i patrzą jak myślisz. Coś takiego
@JamesJoyce: O widzisz, akurat ostatnio mi chodziło po głowie biznesowe dłubanie w AI, wiesz może która chmura dominuje rynek w PL pod względem serwisów ML?
Czołem wszystkim,
w nawiązaniu do wcześniejszego posta. Kilka podpowiedzi, czego nie robić, by nie powielać błędów, przez które znani mi kandydaci się wywalili.
AI:
- bardzo dobrze znać podstawy (Pythona, AI, algorytmów). O to pyta się najczęściej, o klasyczne algo, klasyczne funkcje i typowe zastosowania
- pokazywać tylko kod, co do którego jesteśmy pewni, że umiemy go wyjaśnić (i go rozumiemy)
- opowiadać o technologiach, które się rzeczywiście zna, a nie tylko słyszało
- chwalić się projektami, które realnie zostały stworzone
- szczerze mówić jaką część portfolio robiło ai, a jaką człowiek
- nie kłamać, mówić półprawd czy czegoś podobnego. To wyjdzie. Wielkie repo z samodzielną implementacją perceptronu? Spoko, ale miej pewność, że będziesz o nie zapytany, i że musisz wiedzieć, co tam się dzieje
- nie przepisywać repo z poradników, szkoleń czy książek, mówiąc, że to nasze
- nie pakować się samodzielnie na głęboką wodę np. gadaniem o llmach, transformerach czy innych bertach. Ponownie, w ponad 90% przypadków rekruter techniczny zacznie to drążyć, i może być kiepsko
-nie kłamać nt. znajomości chmury, jeśli robiło się tyko szkolenie z niej
-nie przekłamywać swojego rzeczywistego wykształcenia i doświadczenia
-nie mówić, że się czyta papery naukowe, jeśli się tego nie robi
A co robić: opanować podstawy jak najlepiej się da (Python, AI, algo, plus infra), zrobić kilka dobrych projektów samodzielnie, zrobić kilka certów, ale tylko wartościowych, rozwijać się w różne strony, poznając nowe narzędzia, CZYTAĆ PAPERY, zastanowić się nad jakąś formalną edukacją, nie poddawać się, a będzie dobrze.
Analiza danych i BI:
- bardzo dobrze znać podstawy (np. DAX i Excel, czy Python). O to pyta się najczęściej, o klasyczne algo, klasyczne funkcje i typowe zastosowania
- pokazywać tylko kod lub projekty, co do którego jesteśmy pewni, że umiemy je wyjaśnić (i rozumiemy)
- opowiadać o technologiach, które się rzeczywiście zna, a nie tylko słyszało
- chwalić się projektami, które realnie zostały stworzone
- szczerze mówić jaką część portfolio robiło ai, a jaką człowiek
- nie kłamać, mówić półprawd czy czegoś podobnego. To wyjdzie. NIGDY, POD ŻADNYM POZOREM nie publikować cudzych daszbordów ze zmienionymi danymi, podpisując je własnym nazwiskiem.
-nie kłamać, nt znajomości Pythona, jeśli się go nie zna (to jest dość częste, w BI Python jest raczej plusem niż must have, ale wciąż, ktoś na pewno zada pytanie, jeśli powiesz, że znasz)
-nie pakować się samodzielnie na głęboką wodę np. gadaniem o AI w BI czy chmurze, czy czymś podobnym, w sposób sugerujący, że się na tym zna, bo rekruter może znać się znacznie lepiej
W skrócie co robić: opanować podstawy jak najlepiej się da (DAX, narzędzie do wizualizacji, czasem Python), zrobić kilka dobrych projektów samodzielnie, rozwijać się w różne strony, poznając nowe narzędzia, poznać którąś chmurę, najlepiej Azure, zrobić kilka wartościowych certów, być na bieżąco z tym co się dzieje w środowisku BI, nie poddawać się, a będzie dobrze.
Pozdro, może komuś się przyda.
https://www2.cs.sfu.ca/CourseCentral/454/johnwill/cmpt454_04queries.pdf
O widzisz, akurat ostatnio mi chodziło po głowie biznesowe dłubanie w AI, wiesz może która chmura dominuje rynek w PL pod względem serwisów ML?