Testy co to takiego?

testy sa przewaznie tak banalne ze normalny programista po przeczytaniu skladni danego jezyka jest w stanie odpowiedziec na pytania, zadnych kruczkow w nich nie ma

cepa napisał(a)

testy sa przewaznie tak banalne ze normalny programista po przeczytaniu skladni danego jezyka jest w stanie odpowiedziec na pytania, zadnych kruczkow w nich nie ma

Cepa, jesteś pewien?

Właśnie o tym mówię, że raz jest to prosta składnia np. co ma być w pliku konfiguracyjnym Hibernate'a, żeby odwzorować many-to-many, albo po jakiej klasie dziedziczy NullPointerException, jakieś pytanie o dziedziczenie i ok, takie pytania są w porządku.

Ale weźmy np. pytanie z mojego ostatniego testu:

Ile jest dziewiątek w przedziale liczb od 0 do 100?

WTF?

Albo:

Jaki modyfikator może mieć klasa Inner?

i kod:

public class Outer{
       public void doSomething(int p){
          /*tutaj*/ class Inner{
            public void doInner(){}
          }
       }
}

Typowe pytanie z SCJP, może powinienem pamiętać, ale nawet w książkach do SCJP jest napisane, że tak się nie pisze, bo to są ciekawostki i sztuczki, które mają cie zmylić.
I oto mi właśnie chodzi, po co testować kogoś na ciekawostki, skoro na co dzień się tego nie używa, co z tego że wykuje takie rzeczy na pamięć, skoro nie testuje to praktycznej wiedzy z wytwarzania oprogramowania?

Ja tam wole dostać do zaprojektowania i napisania drobny program, np. na tydzień w tej i tej technologii.
Dzięki temu potwierdzam, że to co piszę w CV nie jest kłamstwem, a jak czegoś nie umiem, bo nie robiłem w tym wcześniej to jestem w stanie się tego nauczyć. Umiejętność szybkiego uczenia też jest ważna. Natomiast jeśli chodzi o to, że zadanie domowe może być zrobione przez kogoś innego, to myślę, że po tygodniu to wyjdzie. Sam swego czasu byłem Team leaderem i takich gości po tygodniu kopałem w tyłek, a do tego miał jeszcze nasrane w świadectwie pracy, że kłamie w CV.

Pozdrawiam.

testy sa przewaznie tak banalne ze normalny programista po przeczytaniu skladni danego jezyka jest w stanie odpowiedziec na pytania, zadnych kruczkow w nich nie ma

Składnie Javy pewnie znasz więc może jedno małe pytanie z rozmowy kwalfikacyjnej:

Short b1 = 66;
Short b2 = 66;

Short b3 = 777;
Short b4 = 777;

System.out.println(b1 == b2);
System.out.println(b1.equals(b2));

System.out.println(b3 == b4);
System.out.println(b3.equals(b4));

Pytanie czemu program wypisze:

true
true
false
true

Odpowiedzi na to pytanie nie znajdziesz nawet 1200-stronicowej Thinking In Java. Przez półtora roku komercyjnego programowania w Javie nigdy nie spotkałem się z sytuacją gdzie taka wiedza była by mi potrzebna. Składnia tu nie ma nic do rzeczy; czemu tak się wypisze można jedynie wyjaśnić znając wewnętrzne optymalizacje jakie robi JVM.

A że akurat nie byłeś na rozmowie gdzie się o takie gówienka pytają to nie uogólniaj, że wszystkie rozmowy są takie proste.

A możesz opisać szerzej tę ciekawostkę? Na myśl rzuca się, że małe wartości Java traktuje sobie jak prymitywy (ale jak małe? <256?)

Kunai napisał(a)

A możesz opisać szerzej tę ciekawostkę? Na myśl rzuca się, że małe wartości Java traktuje sobie jak prymitywy (ale jak małe? <256?)

dobrze myślisz. I tu muszę się pochwalić, że nawet ja, który w swoim życiu napisał może z 20 linijek kodu w javie (zmusili mnie kiedyś) to akurat wiedziałem :p - a skąd - trzeba czytać 4p :D

A tak nie całkiem OT to nie wydaje się Wam, że powyższy przykład jest dość istotny? Nie mam pojęcia jak często porównuje się liczby przez equals i czym się to różni od == ale jeśli ktoś tego nie wie to może spędzić sporo czasu szukając przyczyny "błędu".

A odnośnie pytań z zakresu "kruczków" i pytań banalnych. Czy nikt z Was nie widzi tutaj związku :>. Jeśli gość wyłoży się na pytaniu banalnym (jak fizzbuzz, czy test SQL który podałem) ale np. zna wszystkie "kruczki" to co byście sobie o nim pomyśleli? Ja bym pomyślał, że to gość który ma teorie wykutą na blache (tak jak się zakuwało regółki w szkole - zero zrozumienia, liczy się znajomość słów) i nie potrafi logicznie (czy też algorytmicznie) myśleć. Taki jest skreślany od razu, bo o ile z takiego co się wyłożył na prostych pytaniach może coś być to z takiego co zna kruczki ale nie potrafi prostego kodu sklecić to już nic nie będzie.

Zauważcie też, że te pytania dla kandydatów (ZAZWYCZAJ) nie są tworzone 5 minut przed ich przyjściem ale są przemyślane i każde ma jakiś cel i daje jakiś obraz kandydata. Z drugiej strony każde zadane pytanie daje też obraz potencjalnego pracodawcy i tego co jest dla niego ważniejsze

rtl napisał(a)

Składnie Javy pewnie znasz więc może jedno małe pytanie z rozmowy kwalfikacyjnej:

nie jestem programista javy, wiec nie wiem :P

pytania z jakimi ja sie spotkalem, to np: w c++ jaka bedzie wartosc zmiennej po paru operacjach na wskaznikach czy wrecz iteracja petli do 10 i wartosci zmiennych po niej, z kartkowych przykladow to np: napisac klase abstrakcyjna w php lub interfejs czy tam zrobic prostego singletona. i tak ludzie sie na tym wykladaja :P

Program zadziała tylko na jdk 1.6
Dlaczego?

Bo liczby całkowite poniżej 127 nawet jak są w klasach opakowujących, to można porównać przez ==.

Tak samo by było, jakby tam były dwa egzemplarze klasy Integer.

Ciekawostka? Tak.
Przydatne?
Nie.

A takie pierdoły są na rozmowach.

Rownie dobrze moze stanowic to przyklad na to, ze porownanie == i Equals to nie jest to samo w ogolnosci, choc czasem dziala. Co tez oznacza, ze jak ktos przeczytal kurs i napisal 10 linijek kodu z i = 10 i petla j = 0; j < 100; j++ to tego nie zauwazyl :P

johny_bravo napisał(a)

Rownie dobrze moze stanowic to przyklad na to, ze porownanie == i Equals to nie jest to samo w ogolnosci, choc czasem dziala. Co tez oznacza, ze jak ktos przeczytal kurs i napisal 10 linijek kodu z i = 10 i petla j = 0; j < 100; j++ to tego nie zauwazyl :P

To znaczy, ze w javie 1.6 porównanie egzemplarzy opakowujących proste typy liczbowe, których wartość numeryczna jest w zakresie -127 do 127 można wykonać przez operator ==.

Jednak nie należy tego robić, gdyż ogólną zasadą jest, że egzemplarze klas porównujemy przy pomocy metody equals, koniec kropka.

Zagadka: Biorąc pod uwagę, że przykładowy program działa na oficjalnej maszynie wirtualnej SUN, dlaczego można (ale nie zaleca się!!!) porównywać obiekty typu String przez operator == ?

To tez z 4p - bo takie same stringi dla wydajnosci pamieciowej powinny byc reprezentowane przez jeden string w pamieci czyli jeden adres.

IMHO wszystko zalezy od interpretacji przeprowadzajacego rozmowe:

• "nie wie tego, jest idiota" - nie ma o czym rozmawiac
• "wie, ze powinno byc equals, ale tej konkretnej cechy nie zna" - jest w porzadku

Nie ma co zwalac na testy. Jak firma kieruje sie znajomoscia takich kruczkow TYLKO to i tak nie chcialbym tam pracowac.

nie jestem programista javy, wiec nie wiem

W poprzednim poście napisałeś, że wystarczy znać składnie języka, żeby przejść rozmowę a tutaj nie wiesz? :P To chyba jednak nie wystarczy znać składni języka :P

Testy na rozmowach kwalifikacyjnych są jak najbardziej potrzebne i nawet te przykłady pytań-kruczków nie są argumentem, żeby takich testów nie robić w ogóle.

Jeżeli jakaś firma robi testy z takimi kruczkami to powinniście się cieszyć, że Was nie przyjęli. Naprawdę nie ma się czym przejmować i trzeba podczas poszukiwania pracy przygotować się na to, że na interview zetkniecie się z pełnym przekrojem społeczeństwa. Od totalnych idiotów, którzy mają papier ale nie mają wiedzy po ludzi genialnych, którzy wiedzą o co pytać żeby zbadać wiedzę, a nie znajomość kruczków z SCJP.

[OT]

to ja się jeszcze podepnę pod ten przykład

rtl napisał(a)

Short b1 = 66;
Short b2 = 66;

Short b3 = 777;
Short b4 = 777;

System.out.println(b1 == b2);
System.out.println(b1.equals(b2));

System.out.println(b3 == b4);
System.out.println(b3.equals(b4));

Pytanie czemu program wypisze:

true
true
false
true

z racji jako iż "jestem w tych sprawach zupełnym lajkonikiem" i jave generalnie to widziałem na obrazku :p jaka jest różnica między == a equals?

@RTL raczej też odwoływał się do tego sql.

Sam miałem kilka lekcji z sql, miałem 4 błędy.
Zobacz na pythona. Wystarczy znać że trzeba robić wcięcia, popatrzeć na kilka skryptów i znasz połowę języka. Przejście z jednych reguł do drugich...

rtl napisał(a)

W poprzednim poście napisałeś, że wystarczy znać składnie języka, żeby przejść rozmowę a tutaj nie wiesz? :P To chyba jednak nie wystarczy znać składni języka :P

nie programuje w javie to niby skad mam wiedziec, poza tym imho testy zaleza od firmy, jak szukaja byle kogo ze znajomoscia jezyka to i bez testu moze sie obejsc, jak firma potrzebuje specjaliste to i testy beda poziom wyzej :P
poza tym jezeli w wymaganiach napisza konkretne technologie/narzedzia to chyba logiczne ze na tescie moga wymagac ich znajomosci

co do pytania, na tyle na ile znam skladnie odpowiedzialbym ze program powinien wypisac:

true
true
true
true

a wiec zle, gdybym mimo to przeszedl taka rozmowe to firma miala by na mnie strate bo musial bym sie wiele douczyc,
skoro wiec daja taki test to moze po prostu potrzebuja specjalisty, ktory z dnia na dzien bedzie mogl cos wniesc do projektu a nie po 3 miesiacach

Misiekd napisał(a)

z racji jako iż "jestem w tych sprawach zupełnym lajkonikiem" i jave generalnie to widziałem na obrazku :p jaka jest różnica między == a equals?

== sprawdza tozsamosc referencji - czyli czy wskazuja na ten sam obiekt
equals sprawdza tozsamosc wartosci.

AdamPL napisał(a)

Jeżeli jakaś firma robi testy z takimi kruczkami to powinniście się cieszyć, że Was nie przyjęli. Naprawdę nie ma się czym przejmować i trzeba podczas poszukiwania pracy przygotować się na to, że na interview zetkniecie się z pełnym przekrojem społeczeństwa. Od totalnych idiotów, którzy mają papier ale nie mają wiedzy po ludzi genialnych, którzy wiedzą o co pytać żeby zbadać wiedzę, a nie znajomość kruczków z SCJP.

Hej, ale o kruczki można też zapytać żeby zwyczajnie poznać tok rozumowania kandydata. Jeden powie od razu i źle, drugi chwile się zastanowi, a kiedy pozna odpowiedź zainteresuje się dlaczego tak, a nie inaczej. To pokazuje, że kandydat nie traktuje języka jako smutna konieczność. Nie zawsze liczy się odpowiedź binarna :)

Kiedyś czytałem jak rekrutujący zadawał pytanie typu: masz ogromną ilość rekordów, znajdź medianę. Podkreślane było, że chodzi o ogromną ilość. Teraz jeden człowiek powie, że dane trzeba posortować, a potem wybrać środkowy. Inny weźmie informację pod uwagę, skojarzy, że sortowanie to jest niedopuszczalny narzut i będzie kombinował. Nie chodzi o wymyślenie rozwiązania, bo te jest niebanalne, ale o drążenie tematu.

Misiekd napisał(a)

[OT]
z racji jako iż "jestem w tych sprawach zupełnym lajkonikiem" i jave generalnie to widziałem na obrazku :p jaka jest różnica między == a equals?

Operator == stosujemy w javie dla typów "prymitywnych", czyli int, boolean, short, char, long, double, float, natomiast ten sam operator dla klas zwróci ci true, tylko i wyłącznie, jeśli obydwie zmienne wskazują na ten sam obiekt w pamięci.

Przykład:
Mamy własną klasę:

package pl.bgora;

public class Person {

	private int age;

	private String name;

	private String surname;

	public Person(int age, String name, String surname) {
		this.age = age;
		this.name = name;
		this.surname = surname;
	}

	@Override
	public boolean equals(Object obj) {
		if (obj == null || !(obj instanceof Person)) {
			return false;
		} else if (obj == this) {
			return true;
		} else {
			Person p = (Person) obj;
			return (p.getAge() == getAge()) && (p.getSurname().equals(getSurname()) && p.getName().equals(getName()));
		}
	}

	/**
	 * Zwraca wartość pola age
	 * 
	 * @return Wartość pola age
	 */
	public int getAge() {
		return age;
	}

	/**
	 * Ustawia wartość pola age
	 * 
	 * @param age
	 *            Nowa wartość pola age
	 */
	public void setAge(int age) {
		this.age = age;
	}

	/**
	 * Zwraca wartość pola name
	 * 
	 * @return Wartość pola name
	 */
	public String getName() {
		return name;
	}

	/**
	 * Ustawia wartość pola name
	 * 
	 * @param name
	 *            Nowa wartość pola name
	 */
	public void setName(String name) {
		this.name = name;
	}

	/**
	 * Zwraca wartość pola surname
	 * 
	 * @return Wartość pola surname
	 */
	public String getSurname() {
		return surname;
	}

	/**
	 * Ustawia wartość pola surname
	 * 
	 * @param surname
	 *            Nowa wartość pola surname
	 */
	public void setSurname(String surname) {
		this.surname = surname;
	}
}

A to główny punkt testu:

/**
 * 
 */
package pl.bgora;

/**
 *
 */
public class Main {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Person p1 = new Person(21, "Ania", "Nowak");
		Person p2 = p1;
		
		Person p3 = new Person(21, "Ania", "Nowak");
		
		System.out.println(p1 == p2); //true
		System.out.println(p1.equals(p2)); //true
		System.out.println(p1 == p3); //false
		System.out.println(p1.equals(p3));//true

	}

}

Black007 tyle to się domyśliłem, tylko czemu dla Short b2 = 66; Short b3 = 777; da co innego (w sensie dla 66 zadziała a dla 777 nie). Przecież oba są prymitywami (a przynajmniej tak wynika z tego co napisałeś).

Jeśli chodzi o obiekty to jest to dla mnie zrozumiałe i logiczne, że == porównuje referencje a equals to co obiekt "trzyma", jednak nie kumam dlaczego java inaczej traktuje zmienną typu short równą 66 i równą 777

short i Short w Javie to nie to samo. short jest prymitywem, a Short klasa opakowujaca short. W tym roznica. No i dla wartosci mniejszych od 128, z tego co ktos napisal, Short traktowany jest jako short. W sumie nie wiem po co takie zagmatwanie.

@Misiekd, co nieco pokręciłeś Short i short to coś zupełnie (prawie) innego. short to prymityw, a Short to typ obiektowy. Zagadkowe jest czemu dla 66 porównanie == zwraca true.

aaaaaa nie zwróciłem uwagi na wielkość liter :/
kto wymyślił język, który jest case sensitive :> :/
btw oprócz java i c# jeszcze któryś tak ma?

Fragment dokumentacji

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2

Można najwyżej pytać, dlaczego tak zdecydowano.

Zagadka równie żałosna jak pytanie o nieścisłości standardu C++.

Case sensitive jest praktycznie wszystko... W sumie Lispy pozwalają olać wielkość liter, tylko kto normalny teraz w Lispie pisze?

Misiekd napisał(a)

btw oprócz java i c# jeszcze któryś tak ma?

Case sensitive to chyba cecha wszystkich normalnych języków, tak jak statyczne typowanie.

A ten motyw z short, to faktycznie dziwny jest. Czemu nie mogli zrobić normalnie, jak w C#?

@RTL, a jaka odpowiedź była uznawana za poprawną? Moim zdaniem odpowiedź winna być taka: Ponieważ, (z jakichś tajemniczych powodów) tak zdecydowali twórcy Javy.

Case sensitive to chyba cecha wszystkich normalnych języków, tak jak statyczne typowanie

Co do case sensitive to zgoda. Ale z tym statycznym typowaniem już można się spierać.
Statyczny system typów to nic innego jak "neandertalski sprawdzacz poprawności programów"...
Dan Ingalls, twórca Smalltalka twierdzi, że lepiej jest w drugą stronę - uczynić w języku wszystko dynamiczne, a później ewentualnie pozwolić programiście na wprowadzanie statycznych ograniczeń.

To ja może odkopię...

Obecnie, tak bardziej z drugiej strony przyglądam się procesowi rekrutacyjnemu i jestem przerażony. Przychodzą ludzie, którzy nie wiedzą co to rzutowanie, nie znają różnic między klasą abstrakcyjną a interfejsem, nie wiedzą co zrobić, żeby przyspieszyć wyszukiwanie wg jednej kolumny w tabeli. A w zadaniu polegającym na odwróceniu stringa, wykładają się, bo nie potrafią napisać pętli for, np. pisząc >= zamiast =<. WTF?

somekind napisał(a)

WTF?

Wyższe wykształcenie, już nie z dna lecz z d**y.

btw oprócz java i c# jeszcze któryś tak ma?

jeśli pytasz o short vs Short, to C# tak nie ma. w przeciwieństwie do javy, nie ma w nim podziału na prymitywy i klasy opakowujące. int jest intem, ale jak chcemy to możemy zrobić 5.ToString()

A ten motyw z short, to faktycznie dziwny jest. Czemu nie mogli zrobić normalnie, jak w C#?
javie brakuje typów wartościowych, a na tym opiera się mechanizm typów prostych w C#.