explaining code

stevedave

Supreme [H]ardness
Joined
Mar 6, 2007
Messages
5,737
I have my third interview on Thursday and they are going to have me explain segments of code and I have never done that before so I need some practice does anyone have code segments with comments in it that explain what it's doing for me to practice with. I have no idea what kind of code they are going to have me explain so any code you have could help.
 
http://blogs.msdn.com/doronh/

It's drivers stuff, but you should be able to analyze and follow the flow / logic of any code put in front of you (comments should only play on areas where the code is overly complex). Otherwise it's horribly written. ;)

And no, I'm not Doron.
 
Um, what language? Isn't the pseudo code logic more important?
 
Don't know what language they are going to use, but I have only know C# and Java so if it's anything else I'll just have to guess on the syntax.

If it is pseudo code then I shouldn't have a problem but I'm not sure what they meant by have me explain some code.
 
Not sure what they mean either but those are two good languages know so I think you will do okay. Hopefully they just want you to be able to grasp some basic concepts of memory allocation for variables and control stuctrures, etc.
 
i think they might be looking more at testing your communication skills. it's often hard to explain code without talking in code, if you catch my drift.

"explain this code to me"

"uhhh...well...if c > b then c = function(z-c), else c = function(z+c), else blah if blah return blah"

"..."

i'm sure they're also making sure you can understand code, which it seems like you shouldnt have too much trouble with, just keep in mind that might not be all they're testing. just make sure you sit back and get a feel for the code before you start trying to "explain" it.
 
Good point Fluxion... I agree, they are most definately interested in not only your ability to understand code, but to be able to effectively communicate it with other human beings. That is really hard to do for some people.
 
Yeah I should do good I'm just really nervous because the job is through Apollo group which owns university of phoenix and if I get the job me and my wife can get our masters for free which is like a 45,000+ bonus right of the back. Well back to reading code.
 
it's often hard to explain code without talking in code, if you catch my drift.
I can't agree with this. In fact, I think it's one of the traits that marks the difference between a rookie and a more seasoned developer.

"explain this code to me"

"uhhh...well...if c > b then c = function(z-c), else c = function(z+c), else blah if blah return blah"

I'd think a good interview of this sort would let the candidate have a way to discover the context of the routine. Instead of just reading the code's semantics as you've done, I'd expect the candidate to find that context, reason out the code, and explain to me what the code does for the application (or the business, or ...)

A better read, then, would be something like "if the customer's risk coeficient is greater than the average, will adjust their risk rating up using Smiths' Function and the Zeta constant; otherwise, we'll adjust it down using the same function and constant. This method normalizes the values around Zeta, but doesn't cause them to converge too quickly."

... or, of course, whatever fits the context.
 
I can't agree with this. In fact, I think it's one of the traits that marks the difference between a rookie and a more seasoned developer.

certainly a distinction an interviewer might like to draw out from a candidate. if only one could be assured all their applicants were seasoned developers... ;)

I'd think a good interview of this sort would let the candidate have a way to discover the context of the routine. Instead of just reading the code's semantics as you've done, I'd expect the candidate to find that context, reason out the code, and explain to me what the code does for the application (or the business, or ...)

A better read, then, would be something like "if the customer's risk coeficient is greater than the average, will adjust their risk rating up using Smiths' Function and the Zeta constant; otherwise, we'll adjust it down using the same function and constant. This method normalizes the values around Zeta, but doesn't cause them to converge too quickly."

... or, of course, whatever fits the context.

good advice, and much agreed. that's what i was getting at with my example. in case it wasnt clear, the "..." was the interviewer's dissatisfaction with the "explanation".
 
like fluxion has said, a series of dots usually denotes an awkward silence.
An ellipsis denotes an unfinished thought--not one that wasn't even started. In quoted speech, as Fluxion tried to use it, it indicates a pause, but doesn't directly imply anything about tension or comfort, as you're saying. It can also indicate an omission.

Perhaps your assertion is true in some other languages, but not English.

not a bad Perl question, actually
And a good one for C and C++, too.
 
An ellipsis denotes an unfinished thought--not one that wasn't even started. In quoted speech, as Fluxion tried to use it, it indicates a pause, but doesn't directly imply anything about tension or comfort, as you're saying. It can also indicate an omission.

I agree with you. However, I personally still had no problem grasping that he meant it as an awkward silence.
 
I sent one of our contractors an email earlier this week that started off by saying "Read the ticket." I meant it as "I read the ticket and please verify blah has been done". He took it as "Read the f'ing ticket, man, you need to do this!". I have since clarified with him and he no longer thinks I am a jerk (I hope).
 
Thing is, I'd never expect an interviewer to sit in awkward silence. Their job is to help discover great candidates, not to stare at them and let them flounder.

Given a very coarse or obviously low answer like the one fluxion wrote in his hypothetical, I'd expect the interviewer to explain the question better; to prompt for details.

Pointing out that the question is more about why, or that they expect a higher-level answer, or explain that they're wondering if there's any bugs, or thinking the candidate might have suggestions about better ways to write the same function are all professional responses.

If an interviewer said "..." to me in an interview, it would be a sign that the company is not really the kind of place I'd want to work.
 
It went ok. They asked me to find as many errors as possible in a sql script I found 2 there were 5 total. Then he gave me some java code and asked me to explain it so I did but not how he was looking for. There was an array that went from, 0, 1, 3, 5, 8 instead of 0,1,2,3,4,5,6 and I didn't explain why he did it that way. I rocked ass on all the other non technical questions they said I answered the non technical questions the best out of all the candidates.

I get the answer tomorrow it's 50/50 in my mind because i didn't do great but I didn't bad the wait sucks.
 
Forth interview next week it's down to me and another dude just gota put on charm.
 
I can't agree with this. In fact, I think it's one of the traits that marks the difference between a rookie and a more seasoned developer.

I'm of the opinion that if a developer can't discuss code or a project in simple terms to a nontechnical person then they truly DO NOT understand the code or programming. Be wary of them.
 
Did he explain why he did it that way? I'm just curious.

It was to measure the severity of each check box, some boxes were more serious so they got a larger number. It was some risk analysis application.
 
Got the job I'm the new rookie software developer for University of Phoenix's online classes. If you get kicked out of a class......it was probably my bad.

Feels kind of cool because when I was in high school I told everyone I would be a software developer and now I am one, while most of them are still working at bookmens or barns and noble wasting there life talking about what they are going to do with there life and doing nothing to get there.
 
Back
Top