ajuna . . do you pretty much agree with sam stones advice?
Yes, if you can do it. His learning advice is good, but would be hard to do without going to school and getting a computer science degree (which would be an excellent way to start, but may not be practical in your case). If you can find an experienced programmer willing to spend a lot of time with you, you could learn a great deal. I’m not sure of what you end up learning in a “certification” course- I’ve never taken one, or seen much about them. I’d bet that you’d be better off taking a night class(es) at a university and learing VB or VC++ syntax, etc. on your own.
Arjuna34
I think the following are bad examples of interview questions because they rely on knowledge of semantics rather than understanding the element’s context or usefulness. Okay, one may argue that definitions are useful for communicating ideas, but I, being a professional software developer, rarely encounter any of these terms (with the exception of thread) at work. More often people talk about interactions among different subsystems, or the design as a whole. Actually I discuss design patterns more often than any of these low-level CS terms. And have fun trying to find a graduate with a BS in CS who knows what an Observer is or even how to read a UML diagram.
My point is that the smart people will be able to come up with the concepts on their own without regurgitating a CS textbook. Some of these terms below are common sense.
Why not ask, “How would you implement a function that takes an ordered set of elements and returns another set of the same size, but with the elements in reverse order?” Or, “Describe how you would build an order system, where orders are processed in the reverse order they were received.” Or, “Explain how you would handle operations if the operations are received faster than they can be processed.”
Why not ask, “How would you store a list of elements?” “How would you store a list of elements, if the list is very large?” “How would you store a list of elements, if the list is very large, and elements are deleted and added regularly?” “What would be the problems with your implementation?”
Why would you need to know how a string is represented in C, if you’re not using C?
I personally encounter this word a lot in my day to day work. Surprisingly though, many new graduates, although they know the term, don’t know the impact of using threads. I’d ask, “Where are threads useful? Where are they more problems then they’re worth?”
Many modern programmers don’t access the heap directly, so intricacies of the heap are irrelevant for all but the lowest level programmers.
I like to ask this one, “Think of a case in which you’d want a constructor to be declared protected? Private?”
Why not ask this, “After you declare a variable, how long will it be valid?”
Who uses recursion? I can’t think of a case where recurision is necessary where an iterative solution isn’t better.
Even I don’t know what the context of this means. Do you want me to say accessor and method?
What I think is scarier are graduates with 4 year degrees who can answer the above questions, but who can’t write a concise function. Or who can’t abstract enough to understand where one class ends and another begins. Or who thinks that member variables with names like ‘a’, ‘b’, and ‘c’ are adequate. Or who believes that a line of code that uses a ternary operator no less that 4 times is considered ‘good’.
So, yes, there may be a lot to learn from four years of university classes, but there’s a lot more to learn outside of the university. And most smart people pick up the skills they need from on the job training and postgraduate training.
Like I said, I’m not familiar with the term “queue.” Guess it’s one of those terms that fell through the cracks in my education, or lack thereof. My wild ass guess, though, is that you’re referring to a logical stack vs. a simple list, and the fundamental difference is that a stack works on the last-on, first off concept (ie, if there’s 5 objects in the stack, and you add a 6th, then start popping them off, the 6th is the first one you get back), and a queue would be the opposite. IE, in the above example, the first you popped off would be the first object in the queue, not the last one you added. Do I get the prize?
(note: I have a whole bookshelf full of books that I’m sure I could refer to on this issue, but I thought it would be more fun to pretend I was interviewing and couldn’t look it up.)
Boy, nothin’ like discussing coding theories on the net, vs. actually doing some coding and getting my work done. How come the one is so fun, and the other is (gasp!) work?!?
Dunno what Windows specifically uses a queue for. I’d bet they’re used all over, though, if it’s the logical structure I’m thinking of.
Yeah, you got it, Athena. An example of a Queue would be the messaging system in Microsoft Windows.
Zero: You forget that this is a live interview. Sometimes the simple questions are the best, because they draw the person’s knowledge out. I can often learn more from the questions the person asks me to clarify the problem than I could from a straight answer, which may just be regurgitated from a textbook.
Another reason why your questions are no good for an initial interview is that it takes too long. I could spend half an hour with a guy just on your first question alone. And the problem with ‘problem’ questions like you are suggesting is that the person may go down a different path to the solution and not tell you what you want to know in the first place. Your questions would be much better on an exam, but for a live interview I don’t believe they are the way to go.
As for recursion, I built two recursive modules just this month. One was a routine for walking a tree of an undefined number of nodes with an undefined number of leaves under each node, and another was an RPN->Infix conversion. Both of those solutions are ‘classic’ recursive functions.
And even if there are rarely uses for recursion, it’s still a staple subject in Computing Science, and I would be leery of a programmer who had never heard of it. The same for Re-entrancy. These are topics covered in CS101, and should be part of the fundamental knowledge set of a working programmer. The fact that you immediately thought of the limitations of recursion proves my point - you are intimately familiar with the topic. Can you imagine an educated programmer who had never HEARD of it?
Two ways to communicate with an object: Properties and Methods. I grant you the question is somewhat ambiguous, but again, that forces the candidate to ask you more questions which will illuminate his knowledge.
I agree with you that the most important things are logical skills, the ability to write concise code, etc. But that’s not the subject of an initial interview. If a person survives the initial, then we’ll get into analyzing code samples with defects, asking for simple quick algorithms for certain problems, some order-of-precedence tests, code cleanup tests (ie give someone some mangled code, and ask them how it could be improved), etc. The specifics of that depend on the job description we’re currently hiring for.