-
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"