I disagree. If you want an entry level IT gig (desktop support) or get your foot in the door, you will need your A+
We can agree to disagree then. Because I've landed a couple of entry level IT jobs without ANY certifications whatsoever. I still don't have a certification.
but I'll probably be getting my CEH whenever my "professional" experience hits two years.
Anybody have any tips for answering the technical questions in software engineer interviews. I'm still in college and they seem to always trip me up. Most of the questions are about Object Oriented Programming some are asking how I would approach specific problems.
I can lend a little assistance to this.
First of all, they aren't asking you those questions with the expectation that you describe a perfect algorithm. What they are looking for is how well you understand the concept of Object-Oriented design in comparison to imperative design. They want to hear about how you can take two similar objects (let's say a sedan and a coupe, just for example) and create a generic class that instance of each said object can inherent from (I.e. A Vehicle or Car class, where a Sedan Object and a Coupe Object can inherit from the parent class.)
OO-programming is a different frame of mind than Imperative-programming, and you can tell just by writing a simple program of each type. Just ask a C developer and a Java developer how they would approach the same problem, and you'll probably get very different answers. OO excels when you create code that is reusable, scalable, and RECURSIVE (caps for emphasis.) Its a high-level language, so interviewers are looking for a thorough understanding of that beyond just saying "Well, C uses pointers and Java uses variables, so Java is OO."
They want you to incorporate the qualities of OO in your answer. The best way to do that varies between problems, but things like memory management, pointers/variables, class declarations, etc vary dramatically between OO and Imperative. Pay close attention to the scenarios that you're given, not only so that you understand the problem, but also so that you understand what aspects of OO can be used to help solve the problem in a way that would be better than an imperative design.