Wow, I was surprised to see mine at the edge of the graph on its own. I wonder is that a good or bad thing..! :-)
My first two submissions aren't even on the graph. :-)
Mine's also absent, though I suppose that's to be expected: I did it in Python.
Interviewing programmers: Analysis taster (work in progress)
21–30 of 34 posts
Re: Interviewing programmers: Analysis taster (work in progress)
#22Is there a full size image so I can read the labels and find my submission? :)
It wasn't intended for that purpose, but stand by ... EDIT: OK, I've uploaded a larger version where the labels are readable, but I've had to change the layout so the nodes don't overlap. The lengths of the edges are now not always realted to the distance, although it's approximate. http://www.solipsys.co.uk/Writings/x.dot.png Note: Yours might still not be on it, as yours might be one of the outliers. You can email…
Yeowch! Mine (g034.d) shows up as the second red dot from the left. I submitted a quick pseudocode answer without any research in an effort to mimic interview whiteboarding conditions.
I had no idea my solution would be automatically validated - I was happy enough to get an in-place O(n) solution. The complete lack of pointers on my part must be what separated me from the cluster of correct solutions at the center.
Re: Interviewing programmers: Analysis taster (work in progress)
#23Earlier quoted context omitted.
It wasn't intended for that purpose, but stand by ... EDIT: OK, I've uploaded a larger version where the labels are readable, but I've had to change the layout so the nodes don't overlap. The lengths of the edges are now not always realted to the distance, although it's approximate. http://www.solipsys.co.uk/Writings/x.dot.png Note: Yours might still not be on it, as yours might be one of the outliers. You can email…
Yeowch! Mine (g034.d) shows up as the second red dot from the left. I submitted a quick pseudocode answer without any research in an effort to mimic interview whiteboarding conditions. I had no idea my solution would be automatically validated - I was happy enough to get an in-place O(n) solution. The complete lack of pointers on my part must be what separated me from the cluster of correct solutions at the center.
You use sizeof(test_string) which isn't what you want.
As an experiment I fixed that, but you had another problem as well which also caused it to fail.
Re: Interviewing programmers: Analysis taster (work in progress)
#24Is there a full size image so I can read the labels and find my submission? :)
It wasn't intended for that purpose, but stand by ... EDIT: OK, I've uploaded a larger version where the labels are readable, but I've had to change the layout so the nodes don't overlap. The lengths of the edges are now not always realted to the distance, although it's approximate. http://www.solipsys.co.uk/Writings/x.dot.png Note: Yours might still not be on it, as yours might be one of the outliers. You can email…
What proportion of the entries are on the graph?
Re: Interviewing programmers: Analysis taster (work in progress)
#25whew! I'm glad I passed, though it should be obvious from my submission that my C is far from fluent! I am looking forward to the analysis - thank you for doing this RoG!
Re: Interviewing programmers: Analysis taster (work in progress)
#26I'm quite familiar with C, but I don't see the difference between the while and for loops in the trivia box on article 2 of the series.
I would expect the while loop to compile something like this:
while(condition)
{
// stuff
i++;
}
loop:
if(!condition)
goto end;
// stuff
i++;
goto loop;
end:
for(;condition;i++) {
// stuff
}
loop:
if(!condition)
goto end;
// stuff
i++;
goto loop;
end:
Re: Interviewing programmers: Analysis taster (work in progress)
#27I'd be interested in an analysis of the compiled assembly for those 5 versions in 2b. A quick test on my end shows them all to be extremely similar.
I know little assembly, and am not going to attempt to pick it apart, so I can't attest to any speed difference. But as an example the first and the last compile to the same, though the last has 2 fewer instructions and some -16s changed to -24s. The first is identical to the second. The third has a bit of shuffling, but also appears identical to the first. And the last two are identical to each other (well, obviously).
How much optimization are you looking for in your C-code vs your coder's productivity? If they can get the last ones in one shot, all well and good, but if not is refactoring worth anything in this case?
edit: with -O3 optimizations on gcc, they all appear to be literally identical, the only differences I can see being variable names and the order of functions (in code, not in call order) between the first three and the last two.
Re: Interviewing programmers: Analysis taster (work in progress)
#28Is there a full size image so I can read the labels and find my submission? :)
It wasn't intended for that purpose, but stand by ... EDIT: OK, I've uploaded a larger version where the labels are readable, but I've had to change the layout so the nodes don't overlap. The lengths of the edges are now not always realted to the distance, although it's approximate. http://www.solipsys.co.uk/Writings/x.dot.png Note: Yours might still not be on it, as yours might be one of the outliers. You can email…
Err. Never mind. Found what I was looking for in my inbox, buried. Thanks for the interesting experiment.
Edit: I suspect one of the clusters will be people like me who use array access syntax rather than pointer access.
Re: Interviewing programmers: Analysis taster (work in progress)
#29I'd be interested in an analysis of the compiled assembly for those 5 versions in 2b. A quick test on my end shows them all to be extremely similar. I know little assembly, and am not going to attempt to pick it apart, so I can't attest to any speed difference. But as an example the first and the last compile to the same, though the last has 2 fewer instructions and some -16s changed to -24s. The first is identical t…
Indeed - these are issues that I will be discussing, and would discuss with a candidate once I had their code in hand. I say in 2b:
Each of these changes is unnecessary and in some cases
damage readability. Further, a good compiler will get
most, if not all, of the efficiency for you without
making these changes.
Readability has to be balanced against efficiency, but too often people think something is more efficient when it isn't. As always, profile before "improving."
As I say, these are issues for discussion. Let me add at this point that some of the submitted versions, and some of my reference versions, are significantly different in both style and efficiency.
There is more to come.
Re: Interviewing programmers: Analysis taster (work in progress)
#30I'm quite familiar with C, but I don't see the difference between the while and for loops in the trivia box on article 2 of the series. I would expect the while loop to compile something like this: while(condition) { // stuff i++; } becomes loop: if(!condition) goto end; // stuff i++; goto loop; end: I would expect the for loop to do this: for(;condition;i++) { // stuff } becomes loop: if(!condition) goto end; // stu…
Consider the effect of a "continue" statement in the "stuff" section.