eGospodarka.pl
eGospodarka.pl poleca

PracaGrupypl.praca.dyskusjeMotorola Kraków - rozmowa
Ilość wypowiedzi w tym wątku: 49

  • 1. Data: 2005-12-17 13:43:28
    Temat: Motorola Kraków - rozmowa
    Od: Łukasz Góralczyk <l...@g...com>

    Witam,

    Może komuś pomoże/przyda się. Całkiem niedawno (2, 3 tyg. temu),
    pierwszy etap na stanowisko Software Engineer w dziale rozwojowym UMTS.
    Czas: 1,5 godziny (można było ciut dłużej pisać). Cały test po angielsku
    (pytania), odpowiedzi można było pisać po Polsku. 1 pytanie z UML, 4 z
    Java, ok. 3 z Perla, reszta z C/C++.

    UML:
    1. Narysować: drzwi, użytkownik, który po wprowadzeniu
    hasła może otworzyć drzwi, oraz po wprowadzeniu hasła
    może je zamknąć. Administrator, który może zmieniać hasła.

    Perl:
    1. Dziedziczenie w Perlu (czy można i jak).
    2. Co to jest i do czego służy zmienna $_.
    3. Podane 2 tablice, jak najlepiej jest znaleźć różnice
    tych zbiorów (wylistować elementy pierwszego zbioru, których
    nie ma w drugim).

    Java:
    1. Czy jest możliwe wielokrotne (wielopokoleniowe) dziedziczenie
    w Java, jeśli nie, to czym można to zastąpić.
    2. Które odpowiedzi są fałszywe (tutaj kilka opcji)
    średnio trudne (niuanse języka).
    3. Które odpowiedzi są prawdziwe (tutaj kilka opcji),
    średnio trudne (niuanse języka).
    4. Kawałek programu z instrukcją switch(), wskazać błąd i
    ew. jak go poprawić - brakowało instrukcji breake na
    końcu każdego case.
    5. Kawałek programu z tablicą. Jedna funkcja próbuje
    wyciągnąć element z poza tablicy, w kodzie jest
    instrukcja "catch" - czyli przechwycenie wyjątku. Pytanie:
    co program wypisze?

    C/C++:
    Generalnie pytania miały postać: podany program, co
    jest źle, co wypisze na ekranie. Tylko w kliku pytaniach
    można było zaznaczyć a, b, c, itd.
    1. x = 1000 + 0666 + 0444 = ? (ile wynosi x).
    2. Standardowe pytania z #define kwadrad(x) x*x, potem
    printf( "(%d+%d)^2 = %d\n", a, b, kwadrat(a+b) ).
    3. Cztery klasy (możliwe, że była jeszcze jakaś funkcja wirtualna):
    class A { public: char a[100] };
    class B:virtual A { public: char b[100] };
    class C:virtual A { public: char c[100] };
    class D:A { public: char d[100] };
    class E:B,C,D { char e[100] };
    Ile (mniej więcej) zajmuje klasa E (możliwe 4, 5 wariantów):
    100, więcej niż 100, 200, więcej niż 200, 500, itd.
    4. Zaimplementowac klasę działającą jak stos (musza byc funkcje
    push, pop, print (wypisz ostatni jako pierwszy)).
    5. Znalezc blad. Podane 2 klasy A i B. B jest potomkiem A.
    B proboje uzyskac dostep do prywatnych skladnikow A (na tym
    polega blad).
    6. Kilka klas, wzajemne dziedziczenie. Klasy maja funkcje
    o tych samych nazwach, tylko jedna z nich jest wirtualna.
    Tworzony jest wskaznik klasy rodzica, ktory wskazuje na klase
    dziecko, potem za pomoca tego wskaznika sa wywolywane funkcje.
    Do tego przeładowanie funkcji o tej samej nazwie, jedna
    f(int) znajduje się w jednej klasie, druga f(void) znajduje
    się w drugiej klasie (dziecko tej pierwszej).
    7. Kilka klas, jedna dziedziczy druga. Pytanie co bedzie na wyjsciu
    (chodzi o kolejnosc wywolywania konstruktorow).
    8. 2 Klasy, jedna implementuje liste, druga dziedziczy liste i
    liczy sume elementow dodawanych do listy. Krotki programik -
    podac wynik (sume), jaka naliczy klasa. Trik polegal na tym,
    ze funkcja wstawiajaca elementy byla wirtualna i wywolywana
    za pomoca referencji do klasy List. Cos takiego
    (nie jestem pewien):
    class List
    {
    [blah, blah, inicjalizacja]
    virtual void insert( int a );
    };

    class TotalList:List
    {
    [blah, blah]
    insert( int a );
    func( List& );
    };

    TotalList::func( List &l )
    {
    l.insert(10);
    l.insert(20);
    };

    main()
    {
    [blah blah]
    TotalList a;
    a.func();
    }
    9. Tablica (chyba taka: int tab[] = { {'a','b'}, {'c','d'}, {'e','f'} };).
    Tworzony jest wskaźnik na tę tablicę, potem taka instrukcja:
    printf( "%d %d %d", *ptr++, *ptr++, *ptr++ ) - jaki bedzie wynik?
    10. Kolejna standardowa pulapka: #define abs(x) (x)>0?(x):(-x);,
    potem gdzieś to w programie zrobione z parametrem abs(++a);.
    11. Cos takiego:
    int tab[100], i;
    int *ptr = tab;
    for( i=0;i<100;i++ )
    {
    *ptr=i;
    f(&ptr);
    }
    f( **ptr)
    {
    **ptr++;
    *ptr++;
    }
    Jaka będzie zawartość tablicy tab (coś było z wskaźnikiem
    do wskaźnika)?
    12. Znaleźć prawdopodobny błąd - chodziło o to, że
    operator new, w konstruktorze, tworzył ciąg o długości
    100 znaków. Potem w ciele konstruktora kopiowane było
    pierwsze 100 znaków do tego nowego ciągu (pominięto
    znak końca '\0'). Gdzie błąd i jak poprawić?
    13. Dokończyć program, który zlicza ilość linii w podanym pliku
    (był zaczęty w C++).
    14. Taki program (w podobnym stylu):
    #define y x
    #define z x
    #define x y

    main()
    {
    int z,x;
    z = 2
    {
    x = y + z;
    // ile wynosi x tutaj.
    }
    }
    Dla mnie kłopotem było, czy w pytaniu też dokonać zamiany, czy nie.
    15. Dziwnie prosty program (może miał jakiś haczyk):
    f( char *a )
    {
    memcpy( a, "abcd", 4 );
    }
    main()
    {
    char b[] = "1234";
    f( b );
    }
    Co będzie w b? (możliwośc wyboru gotowej odpowiedzi)


    --
    Łukasz Góralczyk
    http://liku.sdfpau.org


  • 2. Data: 2005-12-17 17:45:43
    Temat: Re: Motorola Kraków - rozmowa
    Od: Krzysztof Stachlewski <s...@f...pl>

    Łukasz Góralczyk wrote:
    > Może komuś pomoże/przyda się. Całkiem niedawno (2, 3 tyg. temu),
    > pierwszy etap na stanowisko Software Engineer w dziale rozwojowym UMTS.
    > Czas: 1,5 godziny (można było ciut dłużej pisać). Cały test po angielsku
    > (pytania), odpowiedzi można było pisać po Polsku. 1 pytanie z UML, 4 z
    > Java, ok. 3 z Perla, reszta z C/C++.

    No i teraz ci biedacy ;-) będą musieli robić nowe testy.

    --
    Tlen:stachobywatelpl Jabber:s...@j...atman.pl GG:1811474


  • 3. Data: 2005-12-17 20:08:38
    Temat: Re: Motorola Kraków - rozmowa
    Od: " leszek" <s...@N...gazeta.pl>

    Łukasz Góralczyk <l...@g...com> napisał(a):

    Ktoś swieżo po kursie C++ sobie poradzi, gdyż pewnie na kursach sie rozwiązuje
    takie łamigłówki w dużych ilościach. Ale w praktycznym programowaniu tego typu
    'tricky' programming trzeba unikac jak ognia, bo jak nawtykasz takich bamboli,
    to sam diabeł potem nie rozwikła co tam się na końcu liczy i dlaczego.


    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 4. Data: 2005-12-17 20:45:45
    Temat: Re: Motorola Kraków - rozmowa
    Od: Sławomir Szyszło <s...@p...onet.pl>

    Dnia Sat, 17 Dec 2005 20:08:38 +0000 (UTC), " leszek"
    <s...@N...gazeta.pl> wklepał(-a):

    >Ktoś swieżo po kursie C++ sobie poradzi, gdyż pewnie na kursach sie rozwiązuje
    >takie łamigłówki w dużych ilościach. Ale w praktycznym programowaniu tego typu
    >'tricky' programming trzeba unikac jak ognia, bo jak nawtykasz takich bamboli,
    >to sam diabeł potem nie rozwikła co tam się na końcu liczy i dlaczego.

    Potem ktoś przejmuje taki kod "w spadku" i stara się zrozumieć, co poeta miał na
    myśli i jak to w ogóle ma prawo działać.

    Zamiast tricków powinny być sprawdzane umiejętności pisania efektywnego kodu.
    Np. jest jakiś fragment programu i należy go poprawić. Albo problem do
    rozwiązania - przedstawić rozwiązanie "proste i naiwne" oraz efektywne. Bo takie
    problemy potem się spotyka, a nie coś w stylu "wskaźnik na wskaźnik wskazujący
    tablicę wskaźników do tablic ze wskaźnikami". :)

    --
    Sławomir Szyszło mailto:s...@p...onet.pl
    FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
    FAQ pl.comp.www.nowe-strony http://www.faq-nowe-strony.prv.pl/


  • 5. Data: 2005-12-17 22:57:18
    Temat: Odp: Motorola Kraków - rozmowa
    Od: "Lukasz" <b...@b...pl>

    > przedstawić rozwiązanie "proste i naiwne" oraz efektywne

    To jedna z najmądrzejszych wypowiedzi, które przeczytałem na tej grupie.
    Zgadzam się w całej rozciągłości. Kod ma być lekki, łatwy i przyjemny.

    Cały czas walczę z "nawiedzonymi", którzy świeżo opanowali jakąś modną
    technikę i chcąc zaszpanować strzelają z armaty do muchy. A później tłumaczą
    mi, że jestam zacofany, bo zrobiłem coś starszą metodą. Ale za to:
    2xczytelniej, 2xszybciej, 2xmniej kodu i 2xmniej błędów.

    --
    Lukasz
    N 50 05' 04"
    E 19 53' 43"



  • 6. Data: 2005-12-17 23:13:03
    Temat: Re: Motorola Kraków - rozmowa
    Od: Sławomir Szyszło <s...@p...onet.pl>

    Dnia Sat, 17 Dec 2005 23:57:18 +0100, "Lukasz" <b...@b...pl> wklepał(-a):

    >> przedstawić rozwiązanie "proste i naiwne" oraz efektywne
    >
    >To jedna z najmądrzejszych wypowiedzi, które przeczytałem na tej grupie.
    >Zgadzam się w całej rozciągłości. Kod ma być lekki, łatwy i przyjemny.

    Trochę za szybko wysłałem, miało być: przedstawić rozwiązanie "proste i naiwne"
    lub efektywne. Nie zawsze rozwiązanie najprostsze jest efektywne, jednakże
    często jest ono wystarczające.

    --
    Sławomir Szyszło mailto:s...@p...onet.pl
    FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
    FAQ pl.comp.www.nowe-strony http://www.faq-nowe-strony.prv.pl/


  • 7. Data: 2005-12-18 00:43:52
    Temat: Re: Motorola Kraków - rozmowa
    Od: Łukasz Góralczyk <l...@g...com>

    leszek wrote:
    > Ktoś swieżo po kursie C++ sobie poradzi, gdyż pewnie na kursach sie rozwiązuje
    > takie łamigłówki w dużych ilościach. Ale w praktycznym programowaniu tego typu
    > 'tricky' programming trzeba unikac jak ognia, bo jak nawtykasz takich bamboli,
    > to sam diabeł potem nie rozwikła co tam się na końcu liczy i dlaczego.

    Właśnie... doszedłem do drugiego etapu, ale ostatecznie dostałem
    negatywną odpowiedź (spartaczyłem, naprawdę spartaczyłem rozmowę z osobą
    z HR). To był właśnie problem, że w tych testach (i na samej rozmowie
    też) nie było jak się wykazać praktyczną wiedzą z programowania - być
    może to by coś zmieniło.

    Mam podobne zdanie, co kolega - te testy sprawdzały/ją tylko i wyłącznie
    książkową wiedzę na temat języków. W ogóle zauważyłem, że jest kilka
    problemów (z c/c++, java), których na pewno można się spodziewać /wide:
    #define kwadrat(x) x*x, brak case w switch/). Analiza programów to
    pomyłka[1], co z tego, że wyklepie na pamięć tablice z priorytetami
    operatorów, jak nie będę wiedział, jak debugować, odszukiwać błędy w
    programie.

    A Motorola - niech tworzą nowe testy :) . Testy, które pisałem same w
    sobie miały parę nieścisłości, błędów, może zrobią lepsze.

    A sama rozmowa - pełen profesjonalizm (może te testy) - tutaj właściwie
    nie mam zastrzeżeń.

    Miłego.

    [1] to jest pewien sposób, ale bez przesady - 80% testu to same programy
    do analizy? Na samej rozmowie było to samo, program - co nie działa, co
    poprawić (blah, zaciąłem się na jednym).

    --
    Łukasz Góralczyk
    http://liku.sdfpau.org


  • 8. Data: 2005-12-18 01:07:12
    Temat: Re: Motorola Kraków - rozmowa
    Od: Łukasz Góralczyk <l...@g...com>

    Sławomir Szyszło wrote:
    [ciach]
    > Potem ktoś przejmuje taki kod "w spadku" i stara się zrozumieć, co poeta miał na
    > myśli i jak to w ogóle ma prawo działać.

    Tak mi się przypomniało: http://thc.org/root/phun/unmaintain.html
    (długie, ale ciekawe, o tym, jak być niezastąpionym przez pisanie
    "ładnego" kodu).

    --
    Łukasz Góralczyk
    http://liku.sdfpau.org


  • 9. Data: 2005-12-18 09:20:28
    Temat: Re: Motorola Kraków - rozmowa
    Od: " leszek" <s...@N...gazeta.pl>


    Nie chodzi mi o to, żebym miał krytykowac Motorolę - nie mój cyrk i nie moje
    małpy, w końcu sami wiedzą lepiej, kogo potrzebują. CHodzi mi tylko o to,
    jakiego typu wiedzę weryfikują takie testy, z tym sobie poradzi świeży
    absolwent kursu C++, natomiast niekoniecznie zda osoba, która nawet napisała
    duży i działający program w C++. Po prostu w praktycznym programowaniu się
    zwraca uwage na zupełnie inne rzeczy, a nie na łamigłówki typu jaki będzie
    efekt uzycia **++*ptr++

    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 10. Data: 2005-12-18 11:44:58
    Temat: Odp: Motorola Kraków - rozmowa
    Od: "Lukasz" <b...@b...pl>

    > w końcu sami wiedzą lepiej, kogo potrzebują

    Ja jakoś odnoszę wrażenie (i ktoś to chyba tutaj pisał), że nie szukają
    dobrych, samodzielnych programistów, ale "klepaczy kodu", którzy są w stanie
    grzecznie wytrzymać psychicznie, gdy zostaną wyprani z własnej inwencji.
    Klient musi mieć jakąś podstawową wiedzę z danej dziedziny, trochę
    inteligencji a reszty go przyuczą, co nie jest trudne, gdy się robi
    niewielki kawałek "od-do". Idealni do tego są absolwenci, bo dają się łatwo
    ulepić.

    --
    Lukasz
    N 50 05' 04"
    E 19 53' 43"


strony : [ 1 ] . 2 ... 5


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1