wartek01 napisał(a):
nie potrafiła wypisać odwróconego String na wyjście standardowe
...
ja osobiście takie rzeczy mogę tolerować u stażysty
Serio? Czy jest jakis poziom niekompetencji przy ktorym stazyste odrzucasz?
Stazysci z ktorymi ja mialem do czynienia, zatrudnieni po znosnym przejsciu przez codility, byli calkiem kumaci i przydatni w projektach.
@LukeJL: co do gonitwy myśli.
Firma prawnicza, ostatni etap, czwarta godzina rekrutacji, zadanie. Podszedłem do niego źle, na pierwszy ogień zaproponowałem rekurencje, ale kolo powiedział jeden przykład gdzie to nie pykło. Przyznałem mu rację, podszedłem z innej strony i rozwiązanie było ok.
Jako feedback - no źle zaczął, potrzebował podpowiedzi, do widzenia.
Firma w której nie można się mylić i pogadać, przegadać rozwiązania - tak to odebrałem.
Inny przykład - firma skandynawska, problem do rozkminy i zakodzenia, wymagali tam autofac. Mało tego używałem, nie miałem pamięci mięśniowej jak w autofac rozwiązuje się problem httpclient. Zarejestrowałem po prostu jako transient, przy czym opowiedziałem, że zwyczajnie nie wiem jak to się ładnie w autofac robi, powiedziałem co bym zrobił i czego bym poszukał. Wyjaśnienie zostało przyjęte i dostałem ofertę.
Grneralnie większość live coding session poszło mi dobrze, zazwyczaj jak jest taka forma rekrutacji to, to przechodzę. Ale jak wszędzie potrzeba obycia, pamiętam jak lata temu dostałem pierwszy raz codility. To było z 12 lat temu. Kurde - o co chodzi jak to ugryźć, dostałem po dupie, bo spieprzyłem, ale po tym miałem faze na hackerrank i codility właśnie, dzięki czemu nie było mi to straszne.
Przechodzenie rozmów to umiejętność sama w sobie. Pewnie są ludzie którzy mają większą niż ja odporność na niespodzianki podczas rekrutacji, niestety ja potrzebuję trochę poćwiczyć aby potem nie dać d**y po całości, żeby trema nie zjadła.
Z tym że nie masz pewności kto i jak ocenia.
W nawiązaniu do pierwszej historii, myślałem że zostanie pozytywnie zauważone, że po zwróceniu mi uwagi znalazłem rozwiązanie, a tu został podkreślony mój błąd. Ok, każdy patrzy po swojemu, a patrząc się na to samo nie musimy wcale tego samego widzieć.
Dziwny temat moim zdaniem.
Nigdy nie miałem problemów z rekrutacją w jakiejkolwiek firmie, tylko znam solidnie fundamenty takie jak:
Dzięki ww. wiedzy + bazy danych oraz praktyczne doświadczenie z programowania, to jest naprawdę kawał solidnej wiedzy żeby ktoś był Was w stanie zagiąć, bo 99% programistów pracujących przy systemach enterprise (pomijam HFT i embedded, bo to jest inna liga) nie ma o tym zielonego pojęcia w praktyce
Problem jest taki, że większości ludzi tutaj nie chce się uczyć i jęczą i płaczą jak to jest źle podczas rekrutacji, ale ego i zarozumiałość wy** w kosmos.
Polecam tak:
wartek01 napisał(a):
30-45 minut, nie mam zielonego pojęcia skąd wziąłeś "kilka" minut)
Okej, ale to nic nie zmienia.
I tak, programista musi panować nad swoim czasem.
Zrobienie czegoś albo nie zrobienie w 30-45 minut nie przesądza o tym, jak zarządza czasem w codziennej pracy.
W realnej pracy nawet jakby jakiegoś dnia złapał 2 godziny zamuły, to pozostaje mu 6 godzin, żeby tę zamułę nadrobić.
Myślę, że problem w tym, że ludzie mogą być po prostu słabi technicznie (Człowiek miał 3 lata expa. Nawet gdy jasno powiedziałem, żeby zrobił pętlę od length-1 do zera - nie potrafił.) i taka osoba ani nie zrobi dobrze live codingu, ani zadań w pracy.
Co do gonitwy myśli - to jest bardzo duży problem u potencjalnego pracownika, z takimi osobami nie da się pracować bo potrafią kilkukrotnie zmienić koncepcję, ale nie sprawdzić żadnej z nich.
To mają panować nad czasem, czy sprawdzać koncepcje?
Sprawdzanie wszystkich koncepcji niekoniecznie musi być dobre, bo sprawdzanie koncepcji zajmuje czas.
Chociaż moim zdaniem lepiej by było, gdyby programiści częściej sprawdzali alternatywne koncepcje robienia czegoś (i robili więcej PoC). Bo wiele projektów wydaje się być zakopanych w jakimś podejściu legacy (nie mówię już o kodzie legacy, ale o samym podejściu legacy, architekturze, rozwiązaniach technicznych, które są słabe, ale które zostały w projekcie dlatego, że ktoś tak kiedyś wymyślił, a nikt nie sprawdził alternatywnego rozwiązania, a później już nie dało się zmienić)
A co sądzicie o pisaniu zadanek w prostej konsoli zamiast w IDE? Ja wczoraj próbowałem napisać coś w uproszczonym oprogramowaniu w apce webowej i... było ciężko, delikatnie mówiąc ;)
LukeJL napisał(a):
Okej, ale to nic nie zmienia.
To wszystko zmienia, a już na pewno psuje narrację.
Zrobienie czegoś albo nie zrobienie w 30-45 minut nie przesądza o tym, jak zarządza czasem w codziennej pracy.
W realnej pracy nawet jakby jakiegoś dnia złapał 2 godziny zamuły, to pozostaje mu 6 godzin, żeby tę zamułę nadrobić.
W realnej pracy nie masz ośmiu godzin na wykonanie piętnastominutowego zadania.
Myślę, że problem w tym, że ludzie mogą być po prostu słabi technicznie (
Człowiek miał 3 lata expa. Nawet gdy jasno powiedziałem, żeby zrobił pętlę od length-1 do zera - nie potrafił.) i taka osoba ani nie zrobi dobrze live codingu, ani zadań w pracy.
Tak. Live-coding takie osoby filtruje bardzo skutecznie. I to jest jedno z zadań rekrutacji.
To mają panować nad czasem, czy sprawdzać koncepcje?
Sprawdzanie wszystkich koncepcji niekoniecznie musi być dobre, bo sprawdzanie koncepcji zajmuje czas.
I cząstka, i fala. Powiem ci jak to wygląda w praktyce.
Człowiek dostaje zadanie. Do zadania są dorzucone testy, które muszą przejść. Prawidłowe podejście jest takie, że na początku siadasz, rozkminiasz problem, tworzysz koncepcję rozwiązania, implementujesz, puszczasz testy, jeśli nie działa to odpowiednio swój kod zmieniasz lub - gdy widzisz, że to podejście całkowicie nie podchodzi - to po prostu orasz kod i robisz od nowa.
Osoba z gonitwą myśli zatrzyma się na samym początku - będzie wymyślać koncepcje (zazwyczaj to takie błędne koło, tj. zaczyna od A, potem dochodzi do B, potem do C, a na końcu z powrotem do A) bez wyklepania kawałka kodu, który miałby szansę przejść chociaż część testów.
Przypominam, że:
Przykładem nieprawidłowego według mnie live-codingu jest ten podany przez @___ref___ - nigdy nie wymagam znajomości jakichś algorytmów typu bubble sort. Natomiast bardzo trudno jest przejść takowe zadanie bez znajomości podstawowych struktur danych.
wartek01 napisał(a):
Przykładem nieprawidłowego według mnie live-codingu jest ten podany przez @___ref___ - nigdy nie wymagam znajomości jakichś algorytmów typu bubble sort. Natomiast bardzo trudno jest przejść takowe zadanie bez znajomości podstawowych struktur danych.
O ile sam jestem przeciwnikiem algosow na rozmowie rekrutacyjnej tak nie wiem co jest zlego w zadaniu bubble sorta, ewentualnie moglbym sie zgodzic zeby zamienic to na zastosowanie dowolnego sorta. Jezeli ktos nie potrafi posortowac listy intow bez wykorzystania wbudowanych metod to cos ewidentnie jest nie tak. I to nie dlatego, ze to trzeba wykuc. Bubble sorta jest w stanie napisac srednio rozgarniety licealista, ktory w zyciu o nim nie slyszal, a my tutaj mowimy o ludziach ktorzy pracuja profesjonalnie i jeszcze chca za to dostawac niemale pieniadze.
Tak z czystej ciekawosci moge wiedziec jakie zadania na live codingu sa wedlug Ciebie adekwatne do sytuacji?
Co do korzystania ze StackOverflow i generalnie Google to imo są to po prostu kolejne umiejętności które trzeba posiadać żeby dobrze pracować. Narzędzie jak narzędzie. IMO jak już musi być ten live coding to nie widzę sensu żeby zakazywać korzystania z dokumentacji/google/so
@Seken @wartek01 - z mojej strony, żeby nie było, ja się nie skarżę, tylko opisuje - chcieli kogoś kto umie bubble sorta, ja pokazałem, że nie umiem - total eclipse of the heart, no i nie pykło :) - czy to znaczy, że jestem złym devem, czy jest to coś coś mnie dyskwalifikuje? - być może, ale generalnie piszę to wszystko z pozycji osoby, która uważa, ze live coding jest jedną z lepszych sposób weryfikacji potencjalnego pracownika i generalnie mi live coding siada, bo tylko 2x zdarzyło się, że po czymś takim nie dostałem oferty, w tym ten jeden nieszczęsny bubble sort z którym będę musiał żyć aż do samiuśkiej śmierci
Ale bubble sort i tak jest słaby.
Tutaj można zobaczyć tabelkę z porównaniem różnych algorytmów sortujących. Są bardziej wydajne algorytmy niż bubble sort.
https://en.wikipedia.org/wiki/Sorting_algorithm#Comparison_of_algorithms