- Forum
- General C++ Programming
- interviews
interviews
i am a grad student, about to graduate soon and looking to study for interviews. As i was looking for books to study for interviews i came across a forum on stackoverflow.com where somebody wrote "I ask questions from Design Patterns: Elements of reusable object oriented software by Erich Gamma". I have that book but i can't understand what kind of interview questions can somebody ask from that book for c++.
Additionally can you guys help me by telling me what to focus on for preparing for interviews. What specific parts and areas . i know many of you must be interviewers, so can you suggest me what should i study and what kind of questions i can expect
I know c++ well and actually that is the only thing i really know.
Additionally can you guys help me by telling me what to focus on for preparing for interviews. What specific parts and areas . i know many of you must be interviewers, so can you suggest me what should i study and what kind of questions i can expect
I know c++ well and actually that is the only thing i really know.
I think you spend your time in vain. In my opinion the man you have mentioned is very stupid. Well he read this book but some other programmer did not read this book. Does it mean that he is a bad programmer? No it does not. Moreover even if somebody read this book and can answer on questions from this book it does not mean that he is a good programmer. There are many such stupid men that after reading some book start to ask question based on the book. And what about him himself when he did not yet read this book?:) Was he a good programmer before reading this book or was not? Or he think that if he read the book he become at once a good programmer?:)
Such questions usually are asked by whose who is himself a very weak programmer.
Such questions usually are asked by whose who is himself a very weak programmer.
No i think it isn't like that because many people have recommended that book .
check this out
http://stackoverflow.com/questions/1403064/best-c-book-for-interview
check this out
http://stackoverflow.com/questions/1403064/best-c-book-for-interview
I am not argueing that the book is bad. I want only to say that you are unable to read all books that were published.:)
My opinion is that that man is a weak programmer and you are also a very weak programmer if you think that it is enough to read this book. Even if you read the book and will be able to answer questions it does not mean that you are a good programmer.
I will demonstrate you an example. Many young programmers read books by Herb Sutter and after that name variables as for example SomeVariable_. They do not understand that it is a very bad style to name such a way variables by appendiing the trailing underscore. But they see that Herb do so and copy its style without critical rethinking.
My opinion is that that man is a weak programmer and you are also a very weak programmer if you think that it is enough to read this book. Even if you read the book and will be able to answer questions it does not mean that you are a good programmer.
I will demonstrate you an example. Many young programmers read books by Herb Sutter and after that name variables as for example SomeVariable_. They do not understand that it is a very bad style to name such a way variables by appendiing the trailing underscore. But they see that Herb do so and copy its style without critical rethinking.
Last edited on
The best preparation for an interview is to actually know what you're talking about.
A good interviewer will be able to tell the difference between someone who knows the language and someone who just did a binge study of "interview questions". And a bad interviewer is a sign that the job you're applying for is probably going to suck.
A good interviewer will be able to tell the difference between someone who knows the language and someone who just did a binge study of "interview questions". And a bad interviewer is a sign that the job you're applying for is probably going to suck.
oh okay .... got your point Vlad and it was helpful...i appreciate it .... but i am actually looking for books which will help me make my concept understanding better so that i can respond to questions asked by the interviewer in a better way.
i have already gone through c++: The complete reference thoroughly but when i appeared for an interview i got stuck.
Also to expand my knowledge, like the interviewer asked me what goes in the background of a map. And i had no clue and so the interviewer told me its the binary tree.
And i am asking for an advice for the topics which i really shouldn't miss such as inheritance and polymorphism in c++, sorting algorithm ,etc etc
i have already gone through c++: The complete reference thoroughly but when i appeared for an interview i got stuck.
Also to expand my knowledge, like the interviewer asked me what goes in the background of a map. And i had no clue and so the interviewer told me its the binary tree.
And i am asking for an advice for the topics which i really shouldn't miss such as inheritance and polymorphism in c++, sorting algorithm ,etc etc
Technical knowledge isn't something that you can cram for before an interview. The best way that you could have known what was in std::map<> would have been to have re-implemented it at some point in your past. That isn't something you can study for, it's an indication of what type of experience you have. He may also be trying to figure out if you're the type of person that will try to re-invent the wheel at the drop of the hat (as we programmers have a habit of doing) or if you will re-use libraries that are already available to you.
If you come across questions like these that you don't know the answers to, don't BS them as they'll know. A direct quote from a book won't impress them either. You say simply "I don't know" followed by "but I understand the purpose of this container and can use it in a practical manner, I have done so on this project and this project".
If you come across questions like these that you don't know the answers to, don't BS them as they'll know. A direct quote from a book won't impress them either. You say simply "I don't know" followed by "but I understand the purpose of this container and can use it in a practical manner, I have done so on this project and this project".
An interview is not an exam. They want to know if you could be a good addition to their team. If they can work with you, side-by-side, for the next x years.
Nobody expects a recent graduate to have practical work experience, but what people expect is:
1. desire to learn
They will have to teach you a lot, fast - policies, practices, guidelines, tools of the trade, technology, business. Show that you've been able to learn something new and different fast, there must have been a time, in school. Don't wait for those questions either, ask what they use, ask how it works, be interested.
2. desire to work
Your output is your work, show that you want to work. If you haven't yet, engage in open source, talk, passionately, about stuff you program at night for fun, even if it's something entirely impractical (like an "OS"). I always ask graduates to describe a personal project they worked on. If you don't bother with programming outside classroom, you won't likely succeed at work.
3. knowledge!
You were just learning CS! You lack practical knowledge, but you should know all the OOP buzzwords and what they mean, in theory. You should know Design patterns, at least some of them, in theory. You should be more up to date on computer science than the interviewer. Otherwise, what were you doing instead of studying?
If you can't imagine what interview questions are based on Design Patterns - it's anything from 'name any five patterns' to 'what's the difference between Decorator and Facade' to 'describe a possible implementation of Abstract Factory in C++', but you it's okay to fail to come up with an implementation as long as you have an idea of what the pattern is about. Keep in mind that the book is rather old (it predates C++!), and the industry moved on, especially in C++. It became something like basic background knowledge.
Nobody expects a recent graduate to have practical work experience, but what people expect is:
1. desire to learn
They will have to teach you a lot, fast - policies, practices, guidelines, tools of the trade, technology, business. Show that you've been able to learn something new and different fast, there must have been a time, in school. Don't wait for those questions either, ask what they use, ask how it works, be interested.
2. desire to work
Your output is your work, show that you want to work. If you haven't yet, engage in open source, talk, passionately, about stuff you program at night for fun, even if it's something entirely impractical (like an "OS"). I always ask graduates to describe a personal project they worked on. If you don't bother with programming outside classroom, you won't likely succeed at work.
3. knowledge!
You were just learning CS! You lack practical knowledge, but you should know all the OOP buzzwords and what they mean, in theory. You should know Design patterns, at least some of them, in theory. You should be more up to date on computer science than the interviewer. Otherwise, what were you doing instead of studying?
If you can't imagine what interview questions are based on Design Patterns - it's anything from 'name any five patterns' to 'what's the difference between Decorator and Facade' to 'describe a possible implementation of Abstract Factory in C++', but you it's okay to fail to come up with an implementation as long as you have an idea of what the pattern is about. Keep in mind that the book is rather old (it predates C++!), and the industry moved on, especially in C++. It became something like basic background knowledge.
Topic archived. No new replies allowed.