I'm a professional programmer, but I don't know everything. For the next month, I need to go deeper into Java than I ever have before. Using the Internet is great for solving specific problems, but I don't have a specific problem yet. All I know so far is that it will be intense.
A structured approach works best for me, so I'm mostly looking for an in-depth book. I can probably only make it through one during this time, so I want it to be a good one.
Dont freak yourself out too much. If you have done any OO programming before java is extremely easy to learn and is well documented. Which is probably why a lot of colleges use it for teaching.
I'm currently a Java developer. Before that I programmed in C++, but that was a long time ago. There was a huge gap between then and the recently acquired Java job. I have years of OOP experience, but I am definitely rusty. Also, my knowledge of the terminology is out of date and incomplete.
I am supposed to have an interview with a large tech company that doesn't mess around. Apparently, I'll have 45 minutes to write code without the use of a compiler/IDE. I don't want to go in trying to recall details I learned 10 years ago.
I've decide to go with "Thinking in Java" for now. Even though it is a little old (2006), it seems to touch on the fundamental concepts and terminology I need, while going much deeper than a typical beginner's book.
I am supposed to have an interview with a large tech company that doesn't mess around. Apparently, I'll have 45 minutes to write code without the use of a compiler/IDE. I don't want to go in trying to recall details I learned 10 years ago.
This sounds asinine. There is literally no situation where you won't have an IDE. Testing your knowledge on Java syntax is hardly going to evaluate your skills as a developer. A good company will want to know your experience with industry standard practices and common libraries. Seeing if you know the syntax of a language should be evident during a kick-the-tires tryout by letting you code like you should.
In my opinion you're probably not headed for somewhere you'd want to work. Any company that tests its applicants in scenarios that just aren't going to happen are likely being staffed by people who haven't adapted to changes in the industry. Anybody who wants to "evaluate" your programming skills outside of an IDE is probably somebody who thinks real programmers do it in vi (or emacs). Teams led by those kind of people are teams you want to stay away from if you ever want to advance your career.
I've been a programmer for a decade now and I've only ever been asked once to forgo an IDE during an interview. The guy who asked had been programming in C for 30+ years and didn't trust anybody else's code, including GNU. That's a huge warning sign to stay far, far away.
If the interview has already happened then I hope it went well. If not, call them back and tell them you feel that any sort of test under unrealistic conditions is not going to give them any real insight into your skills. If they push back, go look for a job somewhere else. It sucks to turn down an interview (or even a position) when you really need it, but having to work for any company that treats you like a junior developer fresh out of Comp Sci 201 is worse.
Just because you'll have access to an IDE doesn't mean an interview shouldn't ask basic questions. You'd be surprised how many people have all of the asked for requirements yet aren't actually qualified for the job (not accusing the OP of anything, just saying).
There's also something to be said about how well someone codes, e.g. industry standard syntax. It can actually cost a lot of money (time) for a resource to have to take the time to decipher bad code.
Private Mod Note
():
Rollback Post to RevisionRollBack
#define ALWAYS SOMETIMES
#define NEVER RARELY
#define ALL MANY
-=GIVE US SOMETHING TO BELIEVE IN=-
I'm nerd enough to link my WoW Armory Though I'll put it in a small font.
Just because you'll have access to an IDE doesn't mean an interview shouldn't ask basic questions. You'd be surprised how many people have all of the asked for requirements yet aren't actually qualified for the job (not accusing the OP of anything, just saying).
That's to be expected, of course. But putting a seasoned developer into a situation that just isn't going to happen not only wastes his time, but yours (the interviewer) as well. Interviews need to be about seeing how an applicant thinks and evaluating how well he can mesh with the team. Any sort of evaluation on basic syntax is something that should come beforehand either through checking the applicant's references or, better yet, their Github (or equivalent). Honestly I don't even consider a person unless they give me some sort of link where I can evaluate their work.
I could maybe see testing a junior developer to make sure he actually has some knowledge of a language, but even then when I'm hiring a junior developer I'm looking for potential.
There's also something to be said about how well someone codes, e.g. industry standard syntax. It can actually cost a lot of money (time) for a resource to have to take the time to decipher bad code.
Depending on the complexity of the task and the time allotted for the test, what gets churned out might not be of the best quality no matter who writes it. I'm a huge proponent of using frameworks instead of writing new code, of using patterns when applicable, and of test driven development. Being plunked down in an unfamiliar development environment and told to code without tools meant for the job is going to result in rough code no matter who you put there.
Really I'm all for kick-the-tires challenges; I use them myself after I have interviewed someone I believe is a good fit for the position. However, I test them in a way that shows me how they work in realistic conditions. I want to see their development process, how they interpret requirements, how they cope with an unfamiliar code base. I don't want to see if they know how to make javac not error out because I'm not using javac to compile my code (and everybody else in enterprise Java development shouldn't be either).
A structured approach works best for me, so I'm mostly looking for an in-depth book. I can probably only make it through one during this time, so I want it to be a good one.
Recommendations?
http://vergil.chemistry.gatech.edu/resources/programming/pdf/TIJ2.pdf
http://docs.oracle.com/javase/tutorial/
http://www.artima.com/jvm/booklist.html
http://www.coderanch.com/t/561171/books/good-book-Java-depth-reading
http://www.coderanch.com/t/513770/books/Java-Book-Depth-studies
Hope those links helped.
I am supposed to have an interview with a large tech company that doesn't mess around. Apparently, I'll have 45 minutes to write code without the use of a compiler/IDE. I don't want to go in trying to recall details I learned 10 years ago.
I've decide to go with "Thinking in Java" for now. Even though it is a little old (2006), it seems to touch on the fundamental concepts and terminology I need, while going much deeper than a typical beginner's book.
This sounds asinine. There is literally no situation where you won't have an IDE. Testing your knowledge on Java syntax is hardly going to evaluate your skills as a developer. A good company will want to know your experience with industry standard practices and common libraries. Seeing if you know the syntax of a language should be evident during a kick-the-tires tryout by letting you code like you should.
In my opinion you're probably not headed for somewhere you'd want to work. Any company that tests its applicants in scenarios that just aren't going to happen are likely being staffed by people who haven't adapted to changes in the industry. Anybody who wants to "evaluate" your programming skills outside of an IDE is probably somebody who thinks real programmers do it in vi (or emacs). Teams led by those kind of people are teams you want to stay away from if you ever want to advance your career.
I've been a programmer for a decade now and I've only ever been asked once to forgo an IDE during an interview. The guy who asked had been programming in C for 30+ years and didn't trust anybody else's code, including GNU. That's a huge warning sign to stay far, far away.
If the interview has already happened then I hope it went well. If not, call them back and tell them you feel that any sort of test under unrealistic conditions is not going to give them any real insight into your skills. If they push back, go look for a job somewhere else. It sucks to turn down an interview (or even a position) when you really need it, but having to work for any company that treats you like a junior developer fresh out of Comp Sci 201 is worse.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
There's also something to be said about how well someone codes, e.g. industry standard syntax. It can actually cost a lot of money (time) for a resource to have to take the time to decipher bad code.
Though I'll put it in a small font.
Please stop hijacking my reply box.
That's to be expected, of course. But putting a seasoned developer into a situation that just isn't going to happen not only wastes his time, but yours (the interviewer) as well. Interviews need to be about seeing how an applicant thinks and evaluating how well he can mesh with the team. Any sort of evaluation on basic syntax is something that should come beforehand either through checking the applicant's references or, better yet, their Github (or equivalent). Honestly I don't even consider a person unless they give me some sort of link where I can evaluate their work.
I could maybe see testing a junior developer to make sure he actually has some knowledge of a language, but even then when I'm hiring a junior developer I'm looking for potential.
Depending on the complexity of the task and the time allotted for the test, what gets churned out might not be of the best quality no matter who writes it. I'm a huge proponent of using frameworks instead of writing new code, of using patterns when applicable, and of test driven development. Being plunked down in an unfamiliar development environment and told to code without tools meant for the job is going to result in rough code no matter who you put there.
Really I'm all for kick-the-tires challenges; I use them myself after I have interviewed someone I believe is a good fit for the position. However, I test them in a way that shows me how they work in realistic conditions. I want to see their development process, how they interpret requirements, how they cope with an unfamiliar code base. I don't want to see if they know how to make javac not error out because I'm not using javac to compile my code (and everybody else in enterprise Java development shouldn't be either).
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.