I have a job interview on Monday and they said there's going to be a test.
What's usually on these tests? I don't know what should I practice.
Job is junior Java developer btw and the conditions are knowing object oriented programming, knowing Java SE/Java EE and using Eclipse. Additionally object relational models and MVC.
you should know by now
How would I know, I never got a test on a job interview before.
ok, let me rephrase it - If you've ever done anything else other than watching Pajeet Java tutorials on youtube, you should know what to expect by know
So the usual, not related to Java EE
If it's a junior job then there probably won't be anything too demanding.
Make sure you know fizzbuzz like the back of your hand
Learn a couple of the popular beginner sorting algos
Memorise some of the popular design patterns
Depending on how hip they seemed, learn some of the new Java features (thinking about streams, filters)
Thanks, that's what I thought.
Advanced questions:
What is an annotation?
What does 'final' do?
What is the default access modifier?
>What is an annotation?
>What does 'final' do?
>What is the default access modifier?
Useless theory shit that nobody cares about.
An annotation is the @ before a class or method name.
Final makes a variable unchangeable. Default access is protected-ish
Be prepared to receive a section of code that you give suggestions on how to refactor. Look for security flaws(injections), if the code follows SOLID principles etc.
Memorize the most used functions of the string library, in many of my interviews I've had to do string manipulation, not on the level of KMP but problems that are quite easy if you just remember what the string library offers.
Fuck off
Why fuck off
>useless theory shit
I wouldn't want to hire someone who couldn't tell me what those terms mean or, if they could, thought they were useless.
In addition to what others have said a general piece of advice worth saying is to talk through what you are doing and don't be afraid to ask questions. Not necessarily for something like fizzbuzz, but if they give you a more complicated problem to solve don't think it is awkward to in some way describe your thought process as you solve it. This is especially important if you get stuck for some reason, you can stil express your skill and abilities even without solving the problem completely. Additionally, communcation is an underrated skill and if you are able to communicate problems or successes you are having that is may be just as valuable to the employer as being able to solve everything in silence. Also ask simple questions, like if for some reason you cannot remember something like a string function that would be fine to ask. As long as you express it like "I want to do x but cannot remember the name of the function," rather than "How do I do x?".
>Java EE
Why do you want this job?
This is good advice.
When they give you a problem to solve: work through it out loud, ask them to clarify the requirements of the question if you need to, don't be afraid to ask questions and talk to them as you try to solve it.
In my test (Junior Java Developer), i got asked, to implement a function that returns the numbers of 'a's in a given string... i was confused, bc it's so basic, but what they really wanted to know, was not how I solve the problem, but instead, what questions I would ask. That's important, too! Nobody needs an excellent programmer who can't talk to costumers, or who question their needs.
>sorting algorithms
is this really a common part of Java interviews?
when i worked with java, writing your own boiler plate code was discouraged heavily.
Understanding design patterns is important of course.
You don't mention any frameworks. I doubt the company is hiring you to start their java programming department, so you fucked up by not figuring out what they work with.
>so you fucked up by not figuring out what they work with.
Yes OP dubs is a good point. If you can find out what libraries/framework/other tools they use and take a crash course on them this will give you a real edge over your peers because you can demonstrate you'll hit the ground running.
I learned all that in my comp sci 1 class, don't seem very advanced to me
Doesn't final also make it so a class can't be inheireted from if used on a class?
I don't particularly want it, but I won't complain if I get it.
>Doesn't final also make it so a class can't be inheireted from if used on a class?
Pretty sure that's done with "abstract" in java, "final" is for variables. Could be wrong though.
I think he's right.
Abstract classes can't be instantiated but can, and should, be inherited from.
Final classes can be instantiated but can't be inherited from.
I think final classes are made that way specifically to prevent inheritance.
Not sure what use cases are there for final classes though.
Yeah, that's it.
I bet you fags never even made something legitimate that uses an abstract class.
How could you tell? Did the fact that we admitted we aren't that familiar with abstract classes tip you off?