The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Preping for a Java/C Technical Interview.
Sharp101
TorontoRegistered User regular
TorontoRegistered User regular
Ok, so following up on my thread last week getting help with my First 'real job search' resume coming out of school, I have a Job interview tomorrow afternoon!
It's for a small local Mobile Game Developer. I'm really happy. But,
Now we get to the hard part.
I really dont know what to expect for the technical questions. Up to this point I've only had your standard 'get through school' jobs, so this whole 'technical interview' is new to me. What should I expect to be expected to know? I haven't really done anything that complicated in my projects, and not knowing what to expect only feeds my fears of being unprepared to enter the job market.
Any Ideas?
It's for a small local Mobile Game Developer. I'm really happy. But,
Now we get to the hard part.
The interview will cover both basic information about yourself and the company as well as some technical questions that will focus on problem solving ability. The technical questions will assume familiarity on your part with either C++ or Java (you'll be able to pick the language).
I really dont know what to expect for the technical questions. Up to this point I've only had your standard 'get through school' jobs, so this whole 'technical interview' is new to me. What should I expect to be expected to know? I haven't really done anything that complicated in my projects, and not knowing what to expect only feeds my fears of being unprepared to enter the job market.
Any Ideas?
Sharp101 on
0
Posts
Take that with a grain of salt, though, because I've never had a technical interview.
Like, if you as a group were kidnapped by a bunch of people and they shaved your heads and painted them either red or green, and you were all forced to stand in a line, one in front of the other. And they started from the back of the line, and the person needed to say what color their head was (they could not see themselves) and if they got it right, the guy moved on, if not, they die. (Also, when you spoke, you could see everyone's head in front of you, and people could hear what you said... but you could only say "Red" or "Green"). And so you need to come up with a system beforehand to ensure, that if this happened, the least number were guaranteed not to die.
And he said they mostly do this to see your thinking process. You don't need to answer it like bam, but they want you to talk out loud and try and reason it out, and he said they often help work you through it. I dunno. I never had one. I'm young. But that's what I know.
My current job was just simple questions asking about basic perl functions, not even syntax, just what function I would use to perform some fairly common task, if I knew what a sql injection was, etc.
The only "general logic/troubleshooting" question I remember was this:
A semi-truck tries to drive under a bridge, but the bridge is barely too low, and the trailer gets wedged into it. The tow-truck cannot pull it out because of how hard it is wedged in. You only have a pencil. How would you get the trailer out?
Some people get the answer, some don't. It's really simple and obvious once you hear it if you don't get the answer. All they really care about is how you respond... did you think of something at all? Did you just give up? etc.
The worst offender I've seen as far as ridiculous shit was a Vi question.
"Open Vi, open a text file, write "some text here" 1000 times, add "!!!" to the end of every line, comment out lines 350-450"
Who cares? I've written thousands and thousands of lines of code in Vi and looked at even more and never needed any of the commands to do that shit. What if I used one of the billion other text editors in *nix instead of Vi? If I really needed to do that, in the real world I'd have internet access and if nothing else man pages and Vi help.
I know that wasn't all that helpful, but basically, it really could be anything. It could be very simple or it could be stupidly complex. I'm assuming this is an entry level dev job as you're fresh out of school and so it probably won't be too bad, though.
It says it focuses on your problem solving ability, so my guess is they will have some sort of "puzzle" that they will want you to solve in code. Counting the number of bits set to one in a 32 bit integer, reversing a string without allocating any new memory, or who knows what else.
Good luck.
1) What are the 4 main SQL commands?
2) What are the different JOINs in SQL and how are they used?
3) What do you do in PHP to get all the system information?
4) What kind of Exceptions can you catch in try..catch block
And more i'm sure but you get the idea. My advice is that getting the job interview is tough, but just be able to defend your resume.
What are the three key features of OOP? (inheritance, polymorphism, encapsulation)
Explain inheritance/polymorphism/encapsulation.
What is the difference between an object and a class?
etc. etc.
Don't be afraid to think out loud, and don't feel like you need to come up with the "brilliant" solution first: nothing wrong with saying "well, I could make two for loops like this which would cover all possible solutions, but there might be a quicker way... aha, I could do it like this as well." I much prefer that to someone who stares at the problem for 5 minutes and then says "Well, I'm not sure, I don't do this kind of thing very much."
As dsplaisted mentioned, make sure you've got a good handle on basic data structures and algorithms. I can't even count the number of people I've interviewed who can't answer a simple data structures question (Example: you have an unsorted linked list, a binary tree, and a hash table. Which is the fastest/slowest for appending an item? Which is the fastest/slowest for finding a particular item?)
One thing I personally don't do, but does come up a lot, is the difference between breadth-first and depth-first search - being able to whip up an algorithm in your language of choice for both types of searches is generally helpful for many problems.
Currently our interview questions start with asking some basics about the Java language (we're a Java house), asking to write a few lines of code, and to design something. We also ask questions about things on the resume. For fresh outs like yourself, a lot of it is going to be focused on your school work and projects.
It is important to be familiar with the phrase "I don't know." Especially when followed up by either "but I know where I can find it" or "but I'm willing to learn". Don't lie and don't make up shit. If you have a follow up interview, make sure that you can give an answer to anything that you said "I don't know" to.
Also, to the truck/trailer/bridge question.
Good lord those questions are awful. With the exception of about five of them, any interviewer that is asking those questions doesn't know how to interview. For much better advice for generic interview questions, go look at joelonsoftware.
-How do you swap two integer values in-place?
A = A xor B
B = A xor B
A = A xor B
Fun little trick
Awful in terms of just poor question material that doesn't tell the interviewer anything or just difficult questions that would require somebody to be very close to Java?
VERY COOL!! I've never seen that before! 8-)
took out her barrettes and her hair spilled out like rootbeer
That had better be a very strong pencil.
It looks fancy, but on most modern systems is actually slower than just using a temporary variable. If you get asked about it in an interview, state this for bonus points.
you don't pop the tires with it, you use the pencil tip to depress the pin in the valve.
took out her barrettes and her hair spilled out like rootbeer
Awful in that they don't tell the interviewer anything about the candidate. They fall into the realm of 'gotcha' questions where either you have needed to do something like that before and so you've done it or you have nothing better to do with your time than read javadoc. Questions about a particular API don't tell you as an interviewer anything about the candidate. The questions in there about language features and data structures are the only ones that are useful.
In that particular list of questions I do use a couple of them. The question about the difference between an abstract class and an interface is useful and when you would use each of them. The question about how to redirect stdin and stdout is garbage because it is an API question with no relevance to any production code that I have ever seen.
In short questions about API are bad, questions about language features are good.
I was thinking thats what you were getting at but wasn't sure. I never liked API questions, myself but I would argue that a small dose of API questions (simple ones, something the dev would know) might be beneficial to the interviewer. If anything, it might round out the candidate as a knowledgable programmer. My point I'm getting at is it seems without some API questions, you might find the candidate struggling with basic syntax and such.
I dunno, I'm not on the other side of the fence though :P
I personally prefer to ask a single question and give them an hour and a whiteboard to answer to test their design skills. Something easy enough to understand quickly, but with enough inherent difficulty that I can tell the difference between candidates.
The best advice I can give: Think out loud
Your thought process is just as important as your ability to code. Also, if you are more comfortable with one language as opposed to another I would ask the interviewer if you can answer any programming related questions in that language.
E.g. I do C++ programming now but since I did Java in school I asked if I could use Java during my interviews.
Questions they asked where
Given two circles with known centers and radiuses (radii?) how would you detect them colliding?
Given a bit string, describe an algorithm for determining the number of ones in the string.
If you were to make a simple/older game like asteroids or centipede, what name some of the methods/classes and hierarchy you would use.
I think there was one more, but I forget.....
Anyway, They told me that if they want to continue my interview process, sometime at the end of this week or begining of the next I'll get an email to set up a time to do an online test. (in which they will email me a set of questions in a text file and I have to answer them and email them back within the hour)
But yeah, it went well, I was able to work out the questions (Fairly easy). It was awesome, near the end me and the lead programmer were just talking about games for a good 15 minutes.
Thanks for the help guys.