Codility w procesie rekrutacji

0

Czy ktoś z Was przechodził już proces rekrutacji z wykorzystaniem Codility albo może rozwiązywaliście przykładowe testy? Jakie macie wrażenia? Czy uważacie, że rekrutacja przeprowadzona w ten sposób rzeczywiście odsiewa programistów dobrych od złych?

Mnie osobiście Codility przypomina Top Coder, po części również SPOJ-a. Codility kładzie nacisk na umiejętność myślenia, znajomości i umiejętności optymalizowania algorytmów, czasem matematyki. Język w Codility jest tylko narzędziem, a test sprawdza tylko znajomość jego podstaw.

0

widzialem i musze przyznac ze zadania do najprostszych zdecydowanie nie naleza, ale czy warto, mam mieszane uczucia, zalezy chyba kogo sie szuka i jakim budzetem dysponuje

1

IMHO znacznie lepszy pomysł na rekrutację niż pytania ze znajomości X technologii. Testu takiego nie przechodziłem ale po nazwach tasków ze strony można wnioskować, że to standardowe zadania algorytmiczne.
Z drugiej strony takie zadania powinny sprawdzać czy ktoś potrafii myśleć, ale raczej bez wielkiego zagłębiania się w zaawansowane algorytmy. Na liście widać część zadań z geometrii obliczeniowej, dział ten jest mocno specjalizowany co raczej nie jest dobrym pomysłem (no chyba, że dana firma akurat to wykorzystuje).

0

Dla mnie bez sensu. I tak w robocie 80% zależy od technologii, i powiedzmy super-duper algorytmik rozwali codility bo ma w małym palcu OI, PA a potem posadzą go i napisać prostą wyszukiwarkę i cisza ...

0

A to jakiś przykład z życia czy tak sobie zgadujesz?

0
Hubert napisał(a)

Dla mnie bez sensu. I tak w robocie 80% zależy od technologii, i powiedzmy super-duper algorytmik rozwali codility bo ma w małym palcu OI, PA a potem posadzą go i napisać prostą wyszukiwarkę i cisza ...

Nie raz się spotkałem z opinią pochodzącą z większych firm (tzn. od rekruterów) takich jak Google, Facebook, że bardziej opłacalne jest zatrudnianie ludzi którzy potrafią myśleć (bo ewentualne braki mogą szybko nadrobić, nie mówię tutaj o wyższych stanowiskach), dlatego sporą częścią rekrutacji są zadania algorytmiczne, które nie są na poziomie wymyślania trudnych algorytmów, tylko krótkie, które sprawdzają czy potrafisz np. jakieś obiekty sprytnie uporządkować, policzyć, a następnie zakodować dość sprawnie pomysł.

Jeżeli ktoś się niezgadza, to proszę o sensowne argumenty i skoro tak, dlaczego takie firmy kładą na to nacisk?

1

Takie firmy jak Google czy Facebook (czy też każda duża korporacja) nie używają żadnych MySQLi, Oracla, Hibernate'a, itp itd gotowych rozwiązań tylko tworzą własne, więc znajomość popularnego oprogramowania jest dla nich praktycznie bezużyteczna. No chyba, że tylko po to, aby uczyć się na błędach innych.

1

Zazwyczaj jest tak, że jak ktoś rozumie algorytmy to nie będzie miał większych problemów z przyswojeniem dowolnej technologii. W drugą stronę to niestety nie działa.
Kolejna kwestia jest taka, że różnych technologii jest masa i firmom jest trudno znaleźć kogoś, kto zna akurat te technologie, które są obecnie używame w firmie. A co jeśli w nowym projekcie trzeba będzie użyć czegoś nowego? Zwolnić obecnych pracowników i poszukać nowych, którzy mają wiedzę? Czy może lepiej od początku zainwestować w kogoś kto jest w stanie szybko przyswoić nową wiedzę?

2
0x200x20 napisał(a)

Zazwyczaj jest tak, że jak ktoś rozumie algorytmy to nie będzie miał większych problemów z przyswojeniem dowolnej technologii.

Na uczelniach, instytutach badawczych, albo studiach na kierunku matematyka można znaleźć pełno takich osób.

W drugą stronę to niestety nie działa.

Czyli ktoś, kto zna technologię nie zrozumie algorytmów? Bo?
Nie da się być dobrym w jakiejś technologii, a zarazem ogólnie głupim. Samo zrozumienie dowolnej technologii również wymaga korzystania z mózgu.

Czy może lepiej od początku zainwestować w kogoś kto jest w stanie szybko przyswoić nową wiedzę?

Żeby mieć umiejętności szybkiej nauki nowych technologii wcale nie trzeba być jakimś wybitnym algorytmikiem. ;P

0

Zazwyczaj.

somekind napisał(a)

W drugą stronę to niestety nie działa.

Czyli ktoś, kto zna technologię nie zrozumie algorytmów? Bo?

Rozróżniasz kwantyfikatory? Inną sprawą jest to czy to jest prawda.

0

Na uczelniach, instytutach badawczych, albo studiach na kierunku matematyka można znaleźć pełno takich osób.

A no można. Np. google często zatrudnia ludzi po matematykach i innych fizykach.

Czyli ktoś, kto zna technologię nie zrozumie algorytmów? Bo?

Źle interpretujesz to co powiedziałem.
Zdanie "Jeśli ktoś rozumie algorytmy to nie będzie miał problemów z przyswojeniem technologii." jest prawdziwe w wielu przypadkach.
Natomiast zdanie: "Jeśli ktoś zna technologię to nie będzie miał problemów z przyswojeniem algorytmów." jest w wielu wypadkach nieprawdziwe.
To są implikacje a nie równoważności :P

1

Matematyk czy fizyk wcale nie musi umieć algorytmów. Mam wrażenie, że obecnie na matematykę to idą chyba ci co nie dają sobie rady z algorytmami. Chociaż z drugiej strony używają tam Mathematicy, Matlaba czy podobnych. Największą różnicą między matematyką, a informatyką to to, że funkcja matematyczna zwraca zawsze to samo dla takich samych parametrów oraz to, że w matematyce nie ma zmiennych, są tylko stałe.

Znajomość niezwykle wysublimowanej technologii PHP nie oznacza, że ktoś jest w stanie napisać jakikolwiek algorytm. Dla przykładu mój znajomy, ledwo po liceum (bo jakiekolwiek studia to dla niego za wysoki poziom) zajmuje się komercyjnie tworzeniem stron w PHP (np firmowych) oraz pozycjonowaniem, nie wie co to są indeksy w bazie, nie potrafi wymyślić algorytmu, który usuwa z ciągu pozycje, które są takie same jak poprzednik (tzn np aby z ciągu 1, 1, 2, 2, 1, 1, 4, 5, 5 zrobić 1, 2, 1, 4, 5). Mając <20 lat zarabiał kilka tysi miesięcznie. Pojęcie struktura danych to dla niego chyba cokolwiek co jest opatrzone słówkiem struct (czy podobnym) - węzeł drzewa binarnego to pewnie dla niego struktura z dwoma wskaźnikami i tyle mu to mówi.

W Google sprzężenie wewnętrznych technologii jest niezwykle silne. GFS, Bigtable, MapReduce, itp są tworzone pod specyficzne workloady występujące w Google, a z drugiej strony workloady są tworzone pod GFS, Bigtable, MapReduce. A więc zespoły które piszą aplikacje klienckie muszą wiedzieć (na poziomie algorytmów, a nie niskopoziomowych szczegółów implementacji) jak działają aplikacje usług i vice versa. Na co Google ktoś, kto nie wie jak jego mechanizmy działają pod maską? Chyba tylko po to, aby klepać CSSy.

0

Widzę, że wątek schodzi na tory czy znajomosc algorytmow jest programiscie potrzebna.
Moim zdaniem to zależy od firmy w jakiej pracujecie i od projektu. Wiekszość firm nie potrzebuje znajomości algorytmów(np. firmy dostarczające oprogramowanie dla biznesu). Ważniejsza staje się tutaj znajomość danej biblioteki/frameworka/technologii i zrozumienie domeny biznesowej. Nawet nie ma tutaj okazji wykazania się znajomością algorytmów.
Znany prelegent, architekt w KRD wspomniał kiedyś, że dopiero po 10 latach pracy miał okazję pobawienia się algorytmami w projekcie.
Ja mam za sobą 5 lat doświadczenia jako developer JAVA/DWH i niestety nie przydała mi się jescze wiedza ze znajomości algorytmów, która nabyłem podczas studiów. Większość problemów jest banalna do rozwiązania.

A jeśli pracuję się w Google (nie w każdym projekcie), czy np. dekoduje się strumień MPG4 w urządzeniach typu Embedded, znajomość optymalnych algorytmów jest tu wręcz wymogiem na porządku dziennym. Takich ofert pracy(gdzie wykorzystywana jest znajomość algorytmów) jest niestety na rynku pracy nie wiele.

Dlatego gdybym to ja miał rekrutować za pomocą codility to zapodałbym jakiś prosty algorytmicznie program(żeby kandydat nie musiał się zastanawiać czy dany problem jest typu "stars and bars") i oceniał bym raczej jego rzemiosło pod kątem "Clean Code"-a, findbug-a, checkstyle-a.

0
0x200x20 napisał(a)

A no można. Np. google często zatrudnia ludzi po matematykach i innych fizykach.

Oni są zapewne kumaci. Mi chodziło o algorytmików, którzy nie poznają nowych technologii (jak np. wykładowcy), albo o matematyków, którzy zupełnie nie są w stanie zrozumieć koncepcji programowania w jakimkolwiek języku.
Jest przepaść między formalnym zapisem algorytmu, a jego implementacją, a niektórzy mają przeszkodę, wynikającą jak sądzę ze sposobu myślenia, aby tę przepaść przeskoczyć. Podobnie jak potrzeba innego sposobu myślenia do programowania proceduralnego, obiektowego czy funkcjonalnego. Nie każdy, kto rozumie jedno z nich jest w stanie nauczyć się pozostałych.

Źle interpretujesz to co powiedziałem.

Odnosiłem się do tego, że "w drugą stronę to niestety nie działa", a to dość radykalnie zabrzmiało.

Żeby nauczyć się nowej technologii trzeba mieć po prostu zdolność do nauki, w takiej sytuacji nie przyda się znajomość algorytmów. A żeby rozwiązywać problemy w pracy, trzeba być po prostu pomysłowym (no chyba, że to problemy stricte algorytmiczne). Znajomość KMP raczej średnio się przyda w sytuacji, w której trzeba zaimplementować strategię. ;P

0
Wibowit napisał(a)

Takie firmy jak Google czy Facebook (czy też każda duża korporacja) nie używają żadnych MySQLi, Oracla, Hibernate'a, itp itd gotowych rozwiązań tylko tworzą własne, więc znajomość popularnego oprogramowania jest dla nich praktycznie bezużyteczna. No chyba, że tylko po to, aby uczyć się na błędach innych.

Byłeś i widziałeś, tak? Pewnie, że google nie trzyma tego na czym operuje wyszukiwarka w jakiejś taniej bazie. Ale poza produktem ostatecznym mają chyba też kilka produktów wewnątrz firmy, choćby jakieś frameworki do testowania tego wszystkiego. Myślisz, że do każdej pierdoły piszą sobie swoje bazy, silniki, tylko dlatego, że mogą? Nawet kasa google trochę by na tym ucierpiała.

Pracuję w czymś co można z pewnością nazwać dużą korporacją. Mamy tu i mysqle i oracle i inne pierdoły.

0

Wibowit opisując tego kodera PHP zwrócił uwagę na istotny problem. W wielu firmach IT wykorzystuje się gotowe narzędzia i biblioteki, a nie je tworzy, pisze się aplikacje na gotowy sprzęt, wykorzystuje się popularne RDBMS-y stąd jakakolwiek wiedza algorytmiczna w ogóle nie jest potrzebna. Rekrutacja w przypadku takiej firmy jak opisana powyżej za pomocą Codility uważam za jakąś kompletną pomyłkę. Mimo to niektóre polskie firmy, które wcale nie są drugim Google stosują testy Codility, co spowodowane jest chyba modą, a nie rzeczywistymi potrzebami. Ja już zacząłem ćwiczyć tego typu zadania, ponieważ zwiększy to moje perspektywy zmiany pracy.

@somekind - Podzielam Twoje zdanie na temat tego, że można poznawać nowe technologie bez znajomości algorytmów. Można również znać tylko algorytmikę bez znajomości frameworków i narzędzi. Jednak w takim wypadku po co w ogóle stosuje się te testy? Dlaczego Codility zdobywa taką popularność?

0

Ja tam jestem zdania, że programista wysokopoziomowy powinien wiedzieć jak działają rzeczy leżące poniżej poziomu abstrakcji, którego aktualnie używa. Jak nie znasz algorytmów to znaczy, że nia masz pojęcia jak działa RDBMS a to znaczy, że nie będziesz w stanie zdebugować i zoptymalizować działania bazy danych.
Być może ludzie, którzy to stosują uważają podobnie :P

0

@0x200x20 - ale po co programista baz danych ma cokolwiek debuggować? Gdyby nawet debuggował działanie funkcji i procedur za pomocą debuggerów dostarczonych albo z bazą danych (jak w MSSQL) albo osobno (jak w przypadku MySQL) to może co najwyżej zdebuggować czy dana procedura/funkcja zwraca poprawne dane z biznesowego punktu widzenia. Programiści baz danych rzadko korzystają z debuggerów, a to dlatego, że kod procedur SQL-owych zazwyczaj jest podzielony na mniejsze kawałki (zapytania), które można wykonać osobno, szybciej niż korzystając z debuggera. Programiści baz danych częściej korzystają z profilera i/lub execution plan niż z debuggera, ponieważ to profiler i execution plan umożliwiają znalezienie tzw. wąskich gardeł.

Programista baz danych żeby zoptymalizować działanie bazy nie musi dokładnie wiedzieć co to jest B-tree i jaki jest optymalny algorytm wyszukiwania w nim danych, a to dlatego, że baza danych już taką strukturę danych i taki algorytm ma zaimplementowany. Dobrze jest znać podstawowe informacje na temat B-tree i odróżniać indeks oparty na b-tree od tego opartego na tabeli hash ale szczegóły implementacji nie są dla programisty istotne, ponieważ tym zajmuje się RDBMS i programista bazy nie ma na to wpływu. Programista baz danych musi jedynie znać SQL i wiedzieć co to jest relacja, postać normalna, klucz, indeks, execution plan, procedura itp. i wiedzieć jak poprawnie użyć tych możliwości, które dostarcza mu RDBMS, znajomość algorytmiki absolutnie nie jest konieczna.

Żaden egzamin certyfikujący Microsoft z zakresu programowania baz danych nie wymaga od zdającego znajomości algorytmiki.

0

Zgadzam się pod warunkiem, że w firmie jest osobny dział zajmujący się administracją bazą danych. Wtedy faktycznie programista klepie tylko głupi kod bazodanowy, a na barki admina spada optymalizacji zapytań, konfiguracji, sprawdzanie czy kod wyproduowany przez programistę nie zabije BD, czyli wszelkie zadania które wymagają znajomości internalsów bazodanowych.
Ale wiele firm (w szczególności startupów i mniejszych firm) nie ma osobnego działu DBA i to programista jest odpowiedzialny za wszystko co wymieniłem (i czego nie wymieniłem).

0

Czy faktycznie żeby wiedzieć, że mam w tabeli założyć indeks (bo to zwiększa wydajność) faktycznie muszę wiedzieć, jak on właściwie działa? Interesuje mnie efekt - szybsze wykonanie zapytania.
Czy żeby posłodzić herbatę trzeba wiedzieć jak cząsteczka sacharozy działa na kubki smakowe?

1

Czy faktycznie żeby wiedzieć, że mam w tabeli założyć indeks (bo to zwiększa wydajność) faktycznie muszę wiedzieć, jak on właściwie działa? Interesuje mnie efekt - szybsze wykonanie zapytania.

Jeszcze trzeba wiedzieć na jakich danych warto ten indeks założyć, co to przyspieszy, a co spowolni, jaki typ indeksu, kiedy ten indeks założyć (przed wstawianiem danych, czy po jak już ma się większośc danych w BD), czy można transakcyjnie cofnąć założenie indeksu danego typu, jakie będzie przyspieszenie, a może warto założyć indeks na więcej niż jednej kolumnie, co się stanie jak indeks się zdefragmentuje i kiedy robić defragmentacje? To jest dopiero wierzchołek góry lodowej.
Można szukać odpowiedzi w gotowych poradnikach, tylko co wtedy jeżeli poradnik opisuje zupełnie inny data model? Wiedząc jak działają indeksy w szczegółach sam jesteś w stanie odpowiedzieć na te pytania.
Oczywiście jak jest mało danych optymalizacja nie ma większego znaczenia, sytuacja zmienia się drastycznie gdy ilość danych rośnie.

0

@0x200x20 - moim zdaniem nie masz racji. To programista baz danych powinien się zajmować optymalizowaniem zapytań. Do tego jak napisałem nie jest potrzebna znajomość algorytmiki tylko znajomość obsługi profilera i czytania execution plan.

Administrator bazy danych zajmuje się takimi tematami jak: instalacja i konfiguracja, polityka backupów, bezpieczeństwo, monitorowanie problemów oraz monitorowanie wydajności bazy danych. Admin na etapie monitorowania wydajności może stwierdzić, że dany procedura, job czy raport "zabija" bazę danych czy spowalnia pracę użytkowników i może w tym celu przesunąć ten obiekt w czasie lub spróbować go zoptymalizować lub po prostu odesłać do autora celem zoptymalizowania kodu. Do realizacji tych zadań również nie musi znać algorytmiki co nie oznacza, że wielu programistów i adminów jej nie zna. Jednak ta znajomość nie wynika z potrzeby ale z chęci zrozumienia jak to działa. Tak jak już pisałem zarówno admin jak i programista nie mają wpływu na to jak baza danych przechowuje/wyszukuje dane i nie jest mu potrzebna szczegółowa wiedza na temat implementacji tego czy innego algorytmu, wystarczy wiedza na temat możliwości, które oferuje baza danych i jakie ma cechy.

Tak jak sam napisałeś wystarczy wiedzieć, jak indeks działa, nie trzeba wiedzieć jak jest zbudowany. Informacje na temat działania indeksów zazwyczaj szuka się w dokumentacji do RDBMS, nie trzeba zgłębiać arkan algorytmiki, szczególnie, że dokładne informacje na temat implementacji są często chronione, ponieważ są w jakiś autorski sposób zoptymalizowane.

0

W zasadzie wszystkiego tego można się albo domyśleć, albo doczytać, albo dowiedzieć eksperymentując, albo wiedzieć już z doświadczenia.

0

Sytuacja jest jasna: to zależy.

Nie mają racji ci, co twierdzą, że w miarę solidna znajomość algorytmiki to mus i że bez tego nie można znaleźć dobrej (obiektywnie, tudzież uśredniając opinie) pracy. Nie mają racji też ci, co twierdzą, że algorytmika nigdzie nie jest potrzebna.

Podobnie jest z technologiami. Nieraz znajomość konkretnej technologii to sprawa drugorzędna, a nieraz -- praktycznie pierwszorzędna.

W dużych korporacjach, gdzie pisze się oprogramowanie biznesowe, większość teamu nie ma styczności z wymyślaniem algorytmów, więc nie muszą mieć solidnej, podstawowej wiedzy. To się po prostu nie przydaje i tyle. Nieprawdą jest, że w dużych korporacjach nie korzysta się z gotowych rozwiązań -- jak najbardziej się korzysta. U mnie (~80 tys. pracowników) używa się gotowych bibliotek i frameworków całkiem często. Korporacje mają kasę. Mogą sobie pozwolić na drogie, komercyjne systemy zarządzania treścią, czy całe, złożone usługi-akceleratory witryn www. Mogą sobie pozwolić na wykupienie specjalnych pakietów wsparcia technicznego do używanych systemów. Z drugiej strony -- owszem, tworzy się też sporo swoich, "szytych na miarę" narzędzi.

Mamy więc i to i to.

Co do wymagania znajomości technologii, to i tutaj odpowiedź brzmi "to zależy". Niekiedy po prostu nie sposób znaleźć ludzi znających technologię X, bo jest to wewnętrzny system, stworzony i utrzymywany przez zatrudniającą korporację. Jeśli jakaś mała firma szuka np. studentów jako klepaczy PHP, to też wybiorą raczej co bystrzejszych ludzi, a niekoniecznie tych, co pisali już w tym frameworku, którego używa firma.

Z drugiej jednak strony, jeśli zatrudnia się koderów HTML/CSS, to znajomość technologii jest niemal wszystkim. Raczej nie zdarzy się, że ktoś by znał inny, analogiczny do HTML-a język znaczników i inny język arkuszy stylów niż CSS. A nawet jeśli, to "cięcie layoutów" to proces mocno celujący w technologię i umiejętność jej właściwego użycia. Algorytmika tu niewiele pomoże, podobnie jak np. znajomość metodyk programowania/prowadzenia projektów. Te rzeczy schodzą na dalszy plan, a liczy się technologia.

Ja czasami też szukam programistów JavaScriptu. Ale takich prawdziwych, nie script-kiddies. Tutaj trzeba zwykle i posiadać ogólne umiejętności programowania (IO, niekiedy jakieś algorytmy), i bardzo dobrze znać ten język. A jeśli nie ten, to przeważnie kilka innych: coś obiektowego, coś z dziedziczeniem prototypowym, coś z funkcyjnością, z asynchronicznością. Niestety, znajomość Javy czy C++ tutaj nie wystarcza, bo w JS programuje się zupełnie inaczej. Jeśli ktoś chce pisać w JS tak jak w Javie czy C++, to zawsze będzie się na JavaScript wkurzał, bo JavaScript nigdy nie będzie tak dobrą Javą jak Java. Z drugiej strony, trafiają się programiści, którzy język znają w miarę, ale z inżynierii oprogramowania są nogami i ciężko byłoby im stworzyć i utrzymywać większy projekt.

W wypadku algorytmiki również "to zależy". Czasami potrzeba zatrudniać algorytmicznych wymiataczy. A czasami jest to kwestia trzeciorzędna w stosunku do znajomości IO, czy nawet technologii. Zależy to bardziej od konkretnych projektów niż od wybranych języków. Można w JS tworzyć rzeczy algorytmiczne (obróbkę grafiki, czy nawet... implementację kodeku), a można zwykłe RIA -- duże aplikacje o prostych algorytmach, ale wymagające pod względem inżynierii oprogramowania.

I to nieprawda, że to pierwsze czy to drugie jest obiektywnie ciekawsze/fajniejsze. Jeden woli siedzieć w algorytmach, drugi woli tworzyć raczej proste algorytmicznie (ew. z ciężką algorytmiką zaimplementowanąprzez "kogoś innego"), ale skomplikowane aplikacje, użyteczne dla korzystających z nich ludzi.

Ja do teamu raczej nie potrzebuję algorytmików i Codility wydaje mi się nieadekwatnym narzędziem na większość stanowisk. Rekrutując, spory nacisk kładziemy na znajomość technologii, IO, komunikatywność. Część kodu kandydata bywa sprawdzana przez testy automatyczne, ale to tylko coś pomocniczego. Kod przechodzi przez normalne code review, sprawdzany jest przez 2 programistów. Podczas rozmowy kwalifikacyjnej również nie ma oceny zero-jedynkowej. Czasami robi się z tego mini-sesja extreme programming, gdzie poprawia się wraz z kandydatem jakiś bug w jego kodzie.

0

Dogłębne testy na algorytmy to słaby pomysł - chyba że się konkretnie szuka kogoś do zoptymalizowania jakiegoś oprogramowania.
Znajomość ogólna większości algorytmów - to jest oczywiście ważne. Ale wiedza czym się różni drzewo czerwono-czarne od AVL już niekoniecznie.

W programowaniu jest przecież wiele innych rzeczy, równie ważnych:

  • znajomość technologii używanych w firmie
  • otwartość na nowe technologie
  • wiedza na temat inżynierii programowania (np. po to żeby wiedzieć dlaczego "How to write unmaintable code" jest tylko gorzkim żartem)
  • wiedza dot. OOP, wzorców projektowych, architektury oprogramowania, przetwarzania rozproszonego i wielowątkowego
  • znajomość metod numerycznych (to w gruncie rzeczy też algorytmy)
  • znajomość matematyki
  • umiejętność testowania oprogramowania
  • umiejętność dokumentowania swojego oprogramowania
1

W zasadzie te testy są i tak znacznie lepsze od pytań w stylu: "Jak obsłużysz automat z napojami będąc zanurzonym w truskawkowym kisielu". Taki test IQ dla programistów.

0

Jak zwykle temat zamienił się w pośmiewisko ekspertów, a wibowit ze swoim "nie używają Oracla" zapisał się złotymi zgłoskami w historii tego forum ;)

0
Haha napisał(a)

Jak zwykle temat zamienił się w pośmiewisko ekspertów, a wibowit ze swoim "nie używają Oracla" zapisał się złotymi zgłoskami w historii tego forum ;)

A masz jakieś dane, że Google używa RDBMS Oracla (bo chyba o bazę danych chodziło)?

0

I już pojawiają się problemy czytania ze zrozumieniem, więc cytat z wibowita:

"Takie firmy jak Google czy Facebook (czy też każda duża korporacja) ".

0

Bardziej z pamięcią niż czytaniem, nie jestem takim fanatykiem żeby czytać po 5 razy te same posty.
Z każdą korporacją to przesada, ale taka jest tendencja. Pracowałem w większej korpo, daleko było jej do googla czy facebooka, ale np. miała własny system bazy danych, modyfikowaną Javę na ich potrzeby itd.

1 użytkowników online, w tym zalogowanych: 0, gości: 1