Job interview
I'm about to do a carreer change. I've been using computers and have done a some programming on my spare time and in school, mostly procedural C++. Now I have applied for a job as a trainee java developer and are scheduled for an interview next week. I'm preparing myself with books in java because I'm pretty new to this language.
So my question is, what kind of questions do you think they will ask me, I'm sure they will put my Java skills to a test but is there something I should prepare myself extra carefully for? They said the interview would take an hour (help).
Thanks for any input.
/C
Living in a part of a world where a job interview is no exam (lucky me!), I may be the wrong person to throw in a suggestion here. However, my $0.02 would be to look at some questions from certification mock exams: http://faq.javaranch.com/view?ScjpMockTests. Don't be scared, there are some tricky ones in there. And good luck with your career change.
OleVVa at 2007-7-12 10:36:26 >
Thanks, I will go through it!
Better concentrate in the fundamentals. such as oops, thread, exception handling, io and swing.all the best ace the interview
some common basics include...
The differences between ArrayList & Vector and/or Hashtable & HashMap.
The access modifier keywords and what they mean (private, public, protected, -). Also other modifiers (static, transient, final).
The differences between an applet and an application.
The difference between an interface and abstract class.
Threading and synchronized keyword.
Try/catch/finally.
Lightweight vs Heavyweight components.
Double buffering.
Layout Managers
Puckstoppers's rules of interviewing # 3: Know what they are expecting you to know.
Do your research. Explore their website(s) and learn what the company does, what their chief products are, where they fit in the corporate landscape that sort of thing. You're looking for general information about the company.
As far as the technical, there are a couple of things to remember. One, this is a trainee position, they aren't expecting you to be an expert. Get a toolset together for yourself. If you can find out what tools they're using more's the better because you can try to duplicate it for yourself but if not that's ok too. (I use IntelliJ at the office and a combination of NetBeans and eclipse at home because I refuse to pay for IntelliJ) Start working through tutorials. Start at the beginning and try to learn what you can.
The second thing you need to remember from a technical standpoint is this:
Puckstopper's rules of interviewing # 1 : DO NOT LIE!
Do not lie about your abilities or knowledge. Be candid remind them that you've done some work in C++ and you're learning but it is new to you. Your honesty and your willingness to learn are your key selling points at this point.
The smartest thing an interviewee every said to me was, "I don't know." and then proceeded to ask me to explain it to him.
So to sum up.
1. Learn about the company and their culture.
2. Learn about the technologies that they use.
3. Learn the technology as much as you can. (not being able to parrot back what a book says but learn how to write code and answer problems with the technology)
4. Be confident and honest and remember what your selling points are.
5. Remember that you're interviewing them too.
Good luck,
PS.
They will ask to see a portfolio. You need to bring portfolio of prgrams you have done as well as proof of your education. They will prbobably do a test to make sure that you know some of the things that they require.
> They will ask to see a portfolio. You need to bring
> portfolio of prgrams you have done as well as proof
> of your education. They will prbobably do a test to
> make sure that you know some of the things that they
> require.
I agree with puckstopper31. They don't expect him to be a good programmer since he's applying for a trainee program. They want to see if he can become a good programmer, and if he has any social skills.
Kaj
kajbja at 2007-7-12 10:36:26 >
Thanks guys, excellent tips. I almost done going through "Head first: Java" which is a very good book. I have the basic skills but, as some of you pointed out, I'm gonna focus to really understand what I have already read.
And as you said, it is a trainee program and they can't really expect me to be an expert. I'm pretty new to the whole OO concept and that is not a small area to cover. Inheritance, polymorphism, abstract classes etc. take time to learn. I think the best way is to write own apps and see when you actually need them. My strength has always been procedures and algorithms.
Again, thanks alot.
/C
puckstopper31 Thanks for your reply, I will keep your tips in mind.
@Op.
The most important thing for you (IMHO) is to show that you really want to become a good developer and not just another average Joe. They might also want to find out for how long you will stay if you get a job at the company after the trainee program. They don't want to spend money on you if you say that you only want to work there for a year or so.
Kaj
kajbja at 2007-7-12 10:36:26 >
I've sat on some hiring panels as the technical guy, and here are my thoughts.
(As always, every shop works differently!)
If you've made it to an interview, you've already make it past hurdles.
There is a lot of winnowing at the resume stage -- some people think
should apply for everything, and you'd be surprised how unqualified some
people are for the job they apply for! So if you have an interview, the shop
is interested in you, to a certain extent.
For a trainee or junior position, they're not expecting a lot of experience --
anyone with that would be going for a higher-salaried job! Think of your
interviewers assigning points to each candidate and the one with the most
points wins. You get points for experience, especially work experience.
Doesn't have to be in Java, and the work doesn't even have to be
programming -- showing you can work on a team wins you points, too.
You also have to have decent communication skills. I can think of some
candidates we talked to, where getting answers from them was like
pulling teeth. After they'd leave the room, we look at each other and say,
"do you feel like a dentist?", "can you imagine having to do that every day?",
etc...
>Hippolyte
I like what you wrote. I'm certainly no newbie when it comes to work, nor making contacts with new people. The things that scares me most are the things typical to OO programming. Private, public, protected, abstract, static, interfaces etc. I have a decent record in science and I hope my mathematical/physics background can help me with the abstract thinking which I think OO programming is. Am I wrong? Also, I've ordered a book in design patterns, because I have no idea what they do at larger enterprises and I just hope I can put together a piece of code in the right way.
Regards, C
> The things that scares me most are the things
> typical to OO programming. Private, public,
> protected, abstract, static, interfaces etc. I have a
> decent record in science and I hope my
> mathematical/physics background can help me with the
> abstract thinking which I think OO programming is. Am
> I wrong?
That sounds like a solid background, but I could be biased since
my background has a lot of logic and proof theory in it ;-)
This could be my bias, but I prefer people who think and analyze
things through versus just tossing things together. I've had to
carry on with too much tossed-salad code, I guess.
You will be at a disadvantage to someone who already has more
o-o experience, but most trainees are going to be light in their loafers
in that stuff. Or half of what they've picked up is wrong -- we've all seen that.
> Also, I've ordered a book in design
> patterns, because I have no idea what they do at
> larger enterprises and I just hope I can put together
> a piece of code in the right way.
Design Patterns, by the Gang of Four?
http://en.wikipedia.org/wiki/Design_Patterns
When I first read that in '95, I had one of those fall-to-the-ground-because-
the-world-is-spinning-so-fast moments. So that's how objects collaborate!
To get the most out of design patterns, you should be comfortable defining
classes. Most design patterns are about the next level -- getting objects to
play well with each other.
Good luck!
> >Hippolyte
>
> I like what you wrote. I'm certainly no newbie when
> it comes to work, nor making contacts with new
> people. The things that scares me most are the things
> typical to OO programming. Private, public,
> protected, abstract, static, interfaces etc. I have a
> decent record in science and I hope my
> mathematical/physics background can help me with the
> abstract thinking which I think OO programming is. Am
> I wrong? Also, I've ordered a book in design
> patterns, because I have no idea what they do at
> larger enterprises and I just hope I can put together
> a piece of code in the right way.
>
> Regards, C
I haven't met you or seen your resume or talked with you beyond this thread, but it sounds to me like you've got the tools to make a solid developer. You're inquisitive, you're self motivating. Based on what you've said, I would anticipate that you'll do very well. I can't speak for everyone, but when I'm hiring junior and trainee level developers I'm looking for two things, a basic grasp of what an application is and is not, and a desire to learn and grow. If a candidate has the desire to learn and grow and a basic grasp of technology. (Having some idea of what a computer is and does is a start.) I can teach them the rest, and in truth would rather have someone like that than someone with a whole pile of half baked preconceived notions that I have to winnow out before I can turn them into something useful.
As far as OO conceptually is concerned I can sum that up very briefly for you. Think organically. Instead of thinking about a program as a series of instructions to be carried out, think of it as an organism. It has a lifecycle, it is born, it matures, it may procreate and it dies. As an organism it lives in an ecosystem of other organisms. Sometimes organisms get together in clusters and often they communicate with each other in interesting ways. They have a genetic lineage and may well give their dna to other generations of organisms.
If what I just said makes sense to you, you'll do just fine.
Scope, inheritance, implementation, polymorphism and encapsulation are all just expressions of the ideas in the preceding paragraph. Design patterns are synonymous with genetic blueprints.
PS.
> it may procreateTrying that got me fired from my last job ;-)
> > it may procreate> > Trying that got me fired from my last job ;-)Not with the interns Hip. Not with the interns.PS.
They don't call me Code Monkey for nothin'...
> Thanks guys, excellent tips. I almost done going
> through "Head first: Java" which is a very good book.
> I have the basic skills but, as some of you pointed
> out, I'm gonna focus to really understand what I have
> already read.
> And as you said, it is a trainee program and they
> can't really expect me to be an expert. I'm pretty
> new to the whole OO concept and that is not a small
> area to cover. Inheritance, polymorphism, abstract
> classes etc. take time to learn. I think the best way
> is to write own apps and see when you actually need
> them. My strength has always been procedures and
> algorithms.
>
> Again, thanks alot.
>
> /C
Again, watching curiously from the side, I think this sounds right. The best way to learn is by practicing, and having written your first Java programs, how modest they might be, will be a great asset, I can't imagine otherwise even though they cannot expect an expert.
BTW, they have inheritance, polymorphism and abstract classes i C++ too. If this helps you over the gap, fine, if it doesn't, just forget it.
OleVVa at 2007-7-21 21:22:29 >
Thanks everyone for your replies and encouraging words, I will let you know how the interview went next week./C
