Post by thread:[OT] About writing tests for employment interviews

Peter P wrote: > This is a self explaining dialogue fragment that took place some time ago > on an > IRC channel: > > <ae88925> I was at a job interview on Thurs where the guy told me I > couldn't do > a=(*.txt) to build an array (a) of filenames (*.txt) (in BASH). > <_abc_> Were you the interviwer or the victim ? > <ae88925> victim > <ae88925> I guess we mutually don't want to work together ... > <ae88925> he told me I /need/ to use the ls command > <_abc_> Did you offer him to swap places after trying it out ? > > No comment. Peter, it's not as self-explanatory as may appear. :) What, in your opinion, is the moral of the story? Hopefully it is "one needs to keep an open mind about what constitutes a correct answer", rather than "empoyment tests are useless". By the way, I am planning to finaly put together the EE/PIC test from the responses I got last time, and put it to good use this Friday. :) Of course, I will make it available to PICListers for review & critique, and hopefully it will be useful to other people involved with interviewing EEs. Vitaliy

On Nov 12, 2007, at 7:42 PM, Vitaliy wrote: {Quote hidden}> Peter P wrote: >> This is a self explaining dialogue fragment that took place some >> time ago >> on an >> IRC channel: >> >> <ae88925> I was at a job interview on Thurs where the guy told me I >> couldn't do >> a=(*.txt) to build an array (a) of filenames (*.txt) (in BASH). >> <_abc_> Were you the interviwer or the victim ? >> <ae88925> victim >> <ae88925> I guess we mutually don't want to work together ... >> <ae88925> he told me I /need/ to use the ls command >> <_abc_> Did you offer him to swap places after trying it out ? >> >> No comment. > > Peter, it's not as self-explanatory as may appear. :) What, in your > opinion, > is the moral of the story? > > Hopefully it is "one needs to keep an open mind about what > constitutes a > correct answer", rather than "empoyment tests are useless". Okay: "Employment tests written by someone without the skills of a 10 year old, are useless?" :-) Anyone interviewing someone for a Unix job -- apparently what the above is -- who said that using an array in the shell directly versus using a bunch of pipes and an ls command, is a) behind in their skillset, and b) closed-minded. On the flip side, anyone who stubbornly wouldn't try to do the job the way the new boss wanted it done during the interview process, no matter how backwards/stupid it was, is also stupid -- in a different way. Being "elitist" to the point of not getting the job, is pretty silly unless the ae88925 person has plenty of job offers on the table. Can't really tell the whole story from the snippet of discussion without more context. The above discussion could be dissected in a number of ways. And even then, the real issue may have been a personality clash between the interviewer and interviewee. You can't tell. -- Nate Duehr spam_OUTnateTakeThisOuTnatetech.com

Vitaliy <spam <at> maksimov.org> writes: > Peter, it's not as self-explanatory as may appear. :) What, in your opinion, > is the moral of the story? I am not sure at all. There are several points: 1. The person administering the test did not know the subject of the item well enough (perhaps he picked it up on a mailing list and he thought it would be a good one to ask) 2. The person administering the test wanted to make this a 'there is your constraint, now show me you can work around it' question but did not make it clear enough and picked an especially stupid example (that is a book move for the program in question, i.e. bash - the equivalent of asking the candidate to drive in a nail with a microscope while ignoring the hammer in his hand). 3. Many other things, including the fact that the candidate may be boasting a little bit. In any case the candidate knew the relevant subject (bash) more than well enough. In general I think that tests not prepared by someone who knows how to write batch tests are useless to the tester and to the candidate. There are a lot of interesting and non-intuitive concepts used in recognized tests, for a reason. Even so, there is a lot of controversy as to their accurateness. I do not think that it is possible to cobble together a test using the opinions of a couple of well intentioned professionals and expect it to work. As I wrote before testing is about ... testing more than anything else. Peter P.

Nate Duehr wrote: {Quote hidden}> :-) > > Anyone interviewing someone for a Unix job -- apparently what the > above is -- who said that using an array in the shell directly versus > using a bunch of pipes and an ls command, is a) behind in their > skillset, and b) closed-minded. > > On the flip side, anyone who stubbornly wouldn't try to do the job the > way the new boss wanted it done during the interview process, no > matter how backwards/stupid it was, is also stupid -- in a different > way. Being "elitist" to the point of not getting the job, is pretty > silly unless the ae88925 person has plenty of job offers on the > table. Can't really tell the whole story from the snippet of > discussion without more context. > > The above discussion could be dissected in a number of ways. And even > then, the real issue may have been a personality clash between the > interviewer and interviewee. You can't tell. > > -- > Nate Duehr > .....nateKILLspam@spam@natetech.com > The point was that the interviewer told the candidate that they had to use ls. Now we don't know if that was a constraint ahead of time, but I interpreted that it was not. If you solve a problem using a solution that works, I cannot argue with you that you should have done it my way. If I wanted it done my way I would have done it myself right? I can only tell you why my way might be better. Personally, I like the find utility =) - MK

Peter P wrote: > In general I think that tests not prepared by someone who knows how to > write > batch tests are useless to the tester and to the candidate. There are a > lot of > interesting and non-intuitive concepts used in recognized tests, for a > reason. > Even so, there is a lot of controversy as to their accurateness. I do not > think > that it is possible to cobble together a test using the opinions of a > couple of > well intentioned professionals and expect it to work. As I wrote before > testing > is about ... testing more than anything else. We'll have to agree to disagree then. :) In my experience, tests are not a guarantee that the candidate is going to work out (as you point out there are other dimensions that come into play). However, they are very useful in weeding out the incompetents.

Martin Klingensmith wrote: {Quote hidden}> Nate Duehr wrote: > >> :-) >> >> Anyone interviewing someone for a Unix job -- apparently what the >> above is -- who said that using an array in the shell directly versus >> using a bunch of pipes and an ls command, is a) behind in their >> skillset, and b) closed-minded. >> >> On the flip side, anyone who stubbornly wouldn't try to do the job the >> way the new boss wanted it done during the interview process, no >> matter how backwards/stupid it was, is also stupid -- in a different >> way. Being "elitist" to the point of not getting the job, is pretty >> silly unless the ae88925 person has plenty of job offers on the >> table. Can't really tell the whole story from the snippet of >> discussion without more context. >> >> The above discussion could be dissected in a number of ways. And even >> then, the real issue may have been a personality clash between the >> interviewer and interviewee. You can't tell. >> >> -- >> Nate Duehr >> nateKILLspamnatetech.com >> >> > The point was that the interviewer told the candidate that they had to > use ls. Now we don't know if that was a constraint ahead of time, but I > interpreted that it was not. If you solve a problem using a solution > that works, I cannot argue with you that you should have done it my way. > If I wanted it done my way I would have done it myself right? I can only > tell you why my way might be better. > > Personally, I like the find utility =) > > - > MK > IANABOFH, but I'll add because this is OT anyway: Using ls or shell completion are both bad ways of doing an operation on each file because you could have perhaps 1000+ files in your directory. If you need to execute an operation on a long list of files you should use the find command and either the -exec option, or create a list in a temporary file and read each line when you continue your script. find -exec echo {} \; find -type d -exec echo {} \; find -type d > list; cat list | while read line; do { find "$line" | wc -l; echo " $line"; }; done; I did a lot of this to manually remove 30,000 "hinet.net" spam from my mail queue, and to unsort my mp3s that iTunes sorted for me (Thanks.) - MK

Vitaliy wrote: {Quote hidden}> Peter P wrote: > >> In general I think that tests not prepared by someone who knows how to >> write >> batch tests are useless to the tester and to the candidate. There are a >> lot of >> interesting and non-intuitive concepts used in recognized tests, for a >> reason. >> Even so, there is a lot of controversy as to their accurateness. I do not >> think >> that it is possible to cobble together a test using the opinions of a >> couple of >> well intentioned professionals and expect it to work. As I wrote before >> testing >> is about ... testing more than anything else. >> > > We'll have to agree to disagree then. :) > > In my experience, tests are not a guarantee that the candidate is going to > work out (as you point out there are other dimensions that come into play). > However, they are very useful in weeding out the incompetents. > > > I agree; tests rarely prove how competent a person will be when hired. The BEST way, in my opinion, is to hire the person on a temporary basis for 90 days, no benefits, etc. Then you have enough time to decide if they are helpful or not. You can then hire him on a standard basis if he "works out". I once hired a PhD EE as a technician because he passed all the standard technician written tests and there were no engineering jobs open. But he was incapable of performing the job, because he had no common sense whatever. He had a family to support, yet we had to let him go as he was a danger to the company. --Bob A

On Nov 13, 2007, at 6:42 AM, Martin Klingensmith wrote: >> The point was that the interviewer told the candidate that they had >> to > use ls. Now we don't know if that was a constraint ahead of time, > but I > interpreted that it was not. If you solve a problem using a solution > that works, I cannot argue with you that you should have done it my > way. Sure you can, if you're the boss. LOL! > If I wanted it done my way I would have done it myself right? I can > only > tell you why my way might be better. That'd be a perfect world, but we're talking about people here! (GRIN) > Personally, I like the find utility =) find -exec {} :-) Me too. -- Nate Duehr .....nateKILLspam.....natetech.com

I choose queue....... It could be either way. It is common to use a queue to add in more element at the tail and remove them at the head...... http://www.cs.bu.edu/teaching/c/queue/linked-list/types.html Stack I am NOT sure. Oh well screw convention :) John --- Neil Cherry <@spam@ncherryKILLspamcomcast.net> wrote: {Quote hidden}> Question 9. A singly linked list is often a good way > to represent: > a stack. > a queue. > a vector. > > So how is a singly linked list a stack (last in > first out). Isn't > it a queue? Of can it be either? > > -- > Linux Home Automation Neil Cherry > KILLspamncherryKILLspamlinuxha.com > http://www.linuxha.com/ Main > site > http://linuxha.blogspot.com/ My > HA Blog > Author of: Linux Smart Homes For Dummies > --

On Nov 13, 2007, at 7:35 PM, Neil Cherry wrote: > Question 9. A singly linked list is often a good way to represent: > a stack. > a queue. > a vector. > > So how is a singly linked list a stack (last in first out). Isn't > it a queue? Of can it be either? A disagreed with that answer as well, along with their answer on multi-threading (I don't think I liked ANY of their answers on the multithreading question, but expecting multithreading to do better in a low memory situation, in spite of memory overhead of multiple threads (eg typically a stack of significant size for each thread, plus scheduling parameters and such) seems like a bad idea. Didn't have a clue on the C++ or algorithm analysis question :-( BillW

William "Chops" Westfield wrote: > On Nov 13, 2007, at 7:35 PM, Neil Cherry wrote: > >> Question 9. A singly linked list is often a good way to represent: >> a stack. >> a queue. >> a vector. >> >> So how is a singly linked list a stack (last in first out). Isn't >> it a queue? Of can it be either? > > A disagreed with that answer as well, along with their > answer on multi-threading (I don't think I liked ANY of > their answers on the multithreading question, but expecting > multithreading to do better in a low memory situation, in > spite of memory overhead of multiple threads (eg typically > a stack of significant size for each thread, plus scheduling > parameters and such) seems like a bad idea. > > Didn't have a clue on the C++ or algorithm analysis question :-( I had C++ (1 semester) and I do remember that one, barely. I've always disliked C++, it has lots of annoying things that make it very complex. I also learned Java, I prefer Java. Right now I'm using Perl which I like but that's for the string handling more than anything. -- Linux Home Automation Neil Cherry RemoveMEncherryTakeThisOuTlinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

--- "William \"Chops\" Westfield" <spamBeGonewestfwspamBeGonemac.com> wrote: {Quote hidden}> > On Nov 13, 2007, at 7:35 PM, Neil Cherry wrote: > > > Question 9. A singly linked list is often a good > way to represent: > > a stack. > > a queue. > > a vector. > > > > So how is a singly linked list a stack (last in > first out). Isn't > > it a queue? Of can it be either? > > A disagreed with that answer as well, along with > their > answer on multi-threading (I don't think I liked ANY > of > their answers on the multithreading question, but > expecting > multithreading to do better in a low memory > situation, in > spite of memory overhead of multiple threads (eg > typically > a stack of significant size for each thread, plus > scheduling > parameters and such) seems like a bad idea. > > Didn't have a clue on the C++ or algorithm analysis > question :-( > > BillW > -- For the multithread was a bit whack.... Still I am open to new perspective. John ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

> Question 9. A singly linked list is often a good way to represent: > a stack. > a queue. > a vector. > > So how is a singly linked list a stack (last in first out). Isn't > it a queue? Of can it be either? Upon reflection, a stack makes the most sense to me. I would not have answered the question correctly to begin with. I think it is a stupid question. Cedric start with a head element add an element that becomes the head element and points to the previous element. repeat ....... ad nauseum A queue is generally first in, first out. I guess you could make the first element the head. A new element would be added and pointed to by the head. The n element would be pointed at by the n-1 element. I think the "trick" in the question is "good way". The queue would benefit from two pointers. one points at the head and one points at the tail. Yikes

On Nov 13, 2007, at 10:26 PM, Cedric Chang wrote: >> Question 9. A singly linked list is often a good way to represent: >> a stack. a queue. a vector. >> >> So how is a singly linked list a stack (last in first out). Isn't >> it a queue? Of can it be either? > > Upon reflection, a stack makes the most sense to me. > I would not have answered the question correctly to > begin with. I think it is a stupid question. Upon further thought, a singly linked list can make a fine stack if you add things to the list by "appending" the list to the new item. You can make a fine queue if you have both an "head" and "tail" pointer. The question is insufficiently specified... BillW

> http://arastra.com/recruit/quiz.py 1. UDP is preferred over TCP for VoIP mainly because: IMHO the correct answer is: Compared to UDP, TCP provides additional services, like reliability using an acknowledge/timeout/resend mechanism. Such additional services (like delayed reliability) are of no use in a voice context. 2. Consider a lossless dedicated gigabit Ethernet link Wow, I might once have been able to calculate this, but no more. 3. Compare these two C programs: I have no clue at all. Wouldn't that depend a lot on the effeciciency of the system() implementation (== fork or vfork or whatever)? 4. Referring to the programs of Question 3, under what condition could one of these programs create a new directory? That is a good question for a sysadmin type of job. I could make program 2 do anything I want with a clever argument, and if that was somehow block there would still be the buffer overrun option. A good sysadmin type would start to shiver and shake reading program 2. PS it is considered bad practice to 'chain' questions in this way. (skipping some q's) 9. A singly linked list is often a good way to represent IMHO 'vector' is definitely wrong, queue and stack are both right. But only one answer seems to be allowed. 10. The most practical approach to accurately predict the delivery schedule of a 10-person 12-month software engineering project is: IMHO the most important answer is: derive the figure by any means, but * avoid pressure from higher management to produce an 'acceptable' figure' *. Software estimation is not hard at all, resisting pressure is. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Cedric Chang wrote: >> Question 9. A singly linked list is often a good way to represent: >> a stack. >> a queue. >> a vector. >> >> So how is a singly linked list a stack (last in first out). Isn't >> it a queue? Of can it be either? > > Upon reflection, a stack makes the most sense to me. > I would not have answered the question correctly to > begin with. I think it is a stupid question. > > Cedric > > start with a head element > add an element that becomes the head element and points to the > previous element. > repeat ....... ad nauseum Two pointers, one to the add_end one the the start, Start points to the next element that is being added (or null if the end). Add new elements at the add end. Now you have a queue. One function adds, one take'th away. My opinion, now is that it could be either one. Depends on how you have it set up (pointer points back a previous data, stack, pointer points forward, queue). -- Linux Home Automation Neil Cherry TakeThisOuTncherryEraseMEspam_OUTlinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

William "Chops" Westfield wrote: > On Nov 13, 2007, at 11:46 PM, wouter van ooijen wrote: > >> 4. Referring to the programs of Question 3, under what condition could >> one of these programs create a new directory? > > I really liked this set of questions. Made me think a bit, but had > relatively "obvious" answers. And ... relevancy in a paranoid world. > Clearly they have "opinions" about shell script wizards. So do I! Shell script wizard, I like that better than lazy Perl programmer. ;-) -- Linux Home Automation Neil Cherry RemoveMEncherryTakeThisOuTlinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Nov 14, 2007 at 08:46:01AM +0100, wouter van ooijen wrote: > > http://arastra.com/recruit/quiz.py > > 1. UDP is preferred over TCP for VoIP mainly because: > > IMHO the correct answer is: Compared to UDP, TCP provides additional > services, like reliability using an acknowledge/timeout/resend > mechanism. Such additional services (like delayed reliability) are of no > use in a voice context. Yeah, gotta agree with you on that one. Simply put, a late TCP packet is still usefull, a late VOIP packet isn't. > 2. Consider a lossless dedicated gigabit Ethernet link > > Wow, I might once have been able to calculate this, but no more. Looking at the answeres given, they want you to be able to rule stuff out quickly. The first answere is definetely wrong, from 1gigabit / 8 bits. The second looks plausible (I choose it) as the math works out roughly with another bit per byte for overhead. But if you have any experience with TCP, (or read a bunch of wikipedia articles after getting the answere wrong) you realise how incredibly hard it is to get really fast TCP streams due to latency and other issues, and you'll pick the third answere without any calculations. > 3. Compare these two C programs: > > I have no clue at all. Wouldn't that depend a lot on the effeciciency of > the system() implementation (== fork or vfork or whatever)? Yes, but I think they are again looking for the sort of person who could come up with a quick estimate of "system()'s gotta be bloody slow compared to a quick unlink()" After all, the answeres were powers of 10... > 4. Referring to the programs of Question 3, under what condition could > one of these programs create a new directory? > > That is a good question for a sysadmin type of job. I could make program > 2 do anything I want with a clever argument, and if that was somehow > block there would still be the buffer overrun option. A good sysadmin > type would start to shiver and shake reading program 2. I think they definetely want to avoid employees who don't have that response! All in all though, I got the impression from the test that the company is filled with grizzled unix system programmer types who may not be always strictly correct, but at least they've run into weird unexpected problems in the real world enough to give quick answeres, and that's what they're looking for in new employees. - -- http://petertodd.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHOwMx3bMhDbI9xWQRAuK1AKCVQj0nHNtQjJ1j1kNWklX/+WrwhACeNL/p O3rBZf6dMOoJmyTAUeLiA18= =8OxK -----END PGP SIGNATURE-----

William "Chops" Westfield wrote: {Quote hidden}> On Nov 13, 2007, at 7:35 PM, Neil Cherry wrote: > > >> Question 9. A singly linked list is often a good way to represent: >> a stack. >> a queue. >> a vector. >> >> So how is a singly linked list a stack (last in first out). Isn't >> it a queue? Of can it be either? >> > > A disagreed with that answer as well, along with their > answer on multi-threading (I don't think I liked ANY of > their answers on the multithreading question, but expecting > multithreading to do better in a low memory situation, in > spite of memory overhead of multiple threads (eg typically > a stack of significant size for each thread, plus scheduling > parameters and such) seems like a bad idea. > > Didn't have a clue on the C++ or algorithm analysis question :-( > > BillW > Hmmm... a scenario that I can answer based on professional experience... ;-) Singly-linked lists make good stacks, but bad queues! With a singly-linked list you have only a pointer to the first element in the list. That element then has a pointer to the next, etc. In the case of a stack, the thing we add last is what we want to retrieve first, so, the process is easy: We have an existing list with the list pointer (the pointer to the first element) pointing to (hypothetical) element X. To 'push' something, say element Y, to the stack, it is as simple as making Y's "next" point to element X, and make the list pointer point to new element Y. To POP from the stack, we simply get the list pointer's element (element Y), then make list pointer point to Y's next element (Element X). Thus, X is now once again at the top of the stack. To implement a queue using a singly linked list, we would have to make a decision... do we scan the list when we join the queue, or when we leave the queue.... By way of example, we want to add element Y to the list, we take the new Element Y and make it's next pointer the same as the list pointer (pointer to element X). We then make the list pointer point to element Y. This is easy (and the same as what we did with a stack). But, to get an element out of the queue, we now have to go to the end of the list. With a Singly-linked-list the only way to do this is to traverse the list, which means going to the list pointer's element (Y), then going to it's 'next' element (element X), and so on until we get to an element that has no 'next' element (call this element 'n'), i.e. the end of the list. This may take a long time if there are lots of elements. We would also have to keep a reference to the last element we visited before we found the element without a 'next' (call this element 'n-1'). To remove the element from the queue, we have to go to our element 'n-1', and remove it's 'next' element, essentially shortening the queue by one entry..... Using a singly-linked-list for a queue is very inefficient (for any reasonably sized queue). Rolf

William "Chops" Westfield wrote: > On Nov 14, 2007, at 6:24 AM, Rolf wrote: > > >> Singly-linked lists make good stacks, but bad queues! >> >> With a singly-linked list you have only a pointer to the first element >> in the list. That element then has a pointer to the next, etc. >> > > Says who? Pretty much all the packet queues in a cisco router are > SLLs, but the "queue" data structure includes two pointers, one for > element entry and a separate one for element removal. It works fine. > > (your objection is the same one they had at Arasta, BTW...) > > BillW > I am curious about two things.... 1. by definition, a SLL has just a single pointer to the head element, and elements have two fields, the data content, and the 'next' pointer. As far as I understand it (and my comp.sci. has been proven wrong before), by having multiple pointers in to the list the data structure you have is no longer a plain Singly-linked-list. 2. The way you describe the cisco structure, it sounds more like a doubly-linked-list. Would it be possible for you to expand on what Cisco does to get efficient linked lists? I think there may just be a conflict in terminology here. Perhaps wikipedia may help... : http://en.wikipedia.org/wiki/Linked_list#Singly-linked_list Rolf

> 1. by definition, a SLL has just a single pointer to the head > element, 'single linked' is just that: one *link* pointer in each list element. nothing said about how many eternal (head, tail, body, intestines) pointers exist *oustide* the list element. > 2. The way you describe the cisco structure, it sounds more like a > doubly-linked-list. a double-linked-list has two link pointers in each list element. (and again, an unspecified amount of external pointers to list elements). this is habdy when you must (often) remove an element from the middle of the list. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

wouter van ooijen wrote: {Quote hidden}>> 1. by definition, a SLL has just a single pointer to the head >> element, >> > > 'single linked' is just that: one *link* pointer in each list element. > nothing said about how many eternal (head, tail, body, intestines) > pointers exist *oustide* the list element. > > >> 2. The way you describe the cisco structure, it sounds more like a >> doubly-linked-list. >> > > a double-linked-list has two link pointers in each list element. (and > again, an unspecified amount of external pointers to list elements). > this is habdy when you must (often) remove an element from the middle of > the list. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > Hi Wouter, I appreciate your response, but, I feel you are missing something. Even with multiple pointers in to a Single Linked List (SLL), there is no way to 'reverse' in thge list. A pointer to the end of the list will only work once to 'remove' an element from the list. i.e. to make a queue from a SLL you need an external pointer (call it pointer Q) to element n-1 in the SLL. With this pointer, you can find, and remove the last element quickly, but, then you need to back the pointer Q up one element so that it is ready for the next time. With a SLL there is no way to back up the list without a full scan. Hang on, I see... you reverse the order of the elements in the SLL... instead of adding at the beginning of the SLL, you add to the end, and remove from the beginning. This way you have the 'list' pointer to the head of the list, and another pointer to the last element. Duh Rolf

Rolf wrote: {Quote hidden}> wouter van ooijen wrote: >>> 1. by definition, a SLL has just a single pointer to the head >>> element, >>> >> 'single linked' is just that: one *link* pointer in each list element. >> nothing said about how many eternal (head, tail, body, intestines) >> pointers exist *oustide* the list element. >> >> >>> 2. The way you describe the cisco structure, it sounds more like a >>> doubly-linked-list. >>> >> a double-linked-list has two link pointers in each list element. (and >> again, an unspecified amount of external pointers to list elements). >> this is habdy when you must (often) remove an element from the middle of >> the list. >> >> Wouter van Ooijen >> >> -- ------------------------------------------- >> Van Ooijen Technische Informatica: http://www.voti.nl >> consultancy, development, PICmicro products >> docent Hogeschool van Utrecht: http://www.voti.nl/hvu >> >> > Hi Wouter, I appreciate your response, but, I feel you are missing > something. > > Even with multiple pointers in to a Single Linked List (SLL), there is > no way to 'reverse' in thge list. A pointer to the end of the list will > only work once to 'remove' an element from the list. i.e. to make a > queue from a SLL you need an external pointer (call it pointer Q) to > element n-1 in the SLL. With this pointer, you can find, and remove the > last element quickly, but, then you need to back the pointer Q up one > element so that it is ready for the next time. With a SLL there is no > way to back up the list without a full scan. > > Hang on, I see... you reverse the order of the elements in the SLL... > instead of adding at the beginning of the SLL, you add to the end, and > remove from the beginning. > > This way you have the 'list' pointer to the head of the list, and > another pointer to the last element. > > Duh > > Rolf Head Tail | | V V [a]->[b]->[c]->[d]->[e]->...->[x]->NULL Tail is where you add Head is where you remove That's a queue using 2 external pointers. If only one pointer were allowed (such as suggested in the fix) then it would be a stack as you can only add/remove from the Head. Does that look correct? I'm not a professional programmer just someone who writes programs. -- Linux Home Automation Neil Cherry EraseMEncherrylinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

On Nov 14, 2007, at 11:39 AM, Rolf wrote: > Would it be possible for you to expand on what Cisco > does to get efficient linked lists? Sure. I don't think it's proprietary or brilliant; just a slightly different way of looking at things. I though it was common. (I THOUGHT it was ubiquitous, causing me to get that question wrong.) > > 1. by definition, a SLL has just a single pointer to the head element, > and elements have two fields, the data content, and the 'next' > pointer. I would have said that the definition of a linked list is that each element has a single pointer to the "next" element. I'm not sure there are any restrictions on the "external api" to the list, and the list still has a beginning and an end. If you save pointers for both, then you can do: enqueue (Q, element) { Q->tail->next = element; Q->tail = element; } dequeue (Q) { element = Q->head; Q->head = element->next; return element; } BillW

--- Xiaofan Chen <xiaofancSTOPspamspam_OUTgmail.com> wrote: > On 11/15/07, John Chung <spamBeGonekravnusSTOPspamEraseMEyahoo.com> wrote: > > --- Xiaofan Chen <KILLspamxiaofancspamBeGonegmail.com> wrote: > > > > > > http://arastra.com/recruit/quiz.py > > > > > > I failed quite badly, only managed to get 4 out > of > > > 10. ;-( ;-( ;-( > > > > > same here!!!!! > > > > That is why I am not a software programmer (in > process of > constant learning but not much progress yet). > > How about you? ;-) > > Xiaofan > -- Unfortunately I am a software programmer. Some of the questions were questionable...... Anyway my score sucks. The questions are more for system programmers which I am........ John ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

John Chung wrote: {Quote hidden}> --- Xiaofan Chen <EraseMExiaofancEraseMEgmail.com> wrote: > >> On 11/15/07, John Chung <@spam@kravnus@spam@spam_OUTyahoo.com> wrote: >>> --- Xiaofan Chen <spamBeGonexiaofancKILLspamgmail.com> wrote: >>> >>>>> http://arastra.com/recruit/quiz.py >>>> I failed quite badly, only managed to get 4 out >> of >>>> 10. ;-( ;-( ;-( >>>> >>> same here!!!!! >>> >> That is why I am not a software programmer (in >> process of >> constant learning but not much progress yet). >> >> How about you? ;-) >> >> Xiaofan >> -- > Unfortunately I am a software programmer. Some of > the questions were questionable...... Anyway my score > sucks. The questions are more for system programmers > which I am........ I did well, I got an 80 but that's because 3 questions were obvious as to what the answers they wanted and not because I knew the correct answer. I would have gotten only a 60 as I didn't agree with a couple of the answers. BTW, I'm a 'network engineer' though I'm not sure what that means. -- Linux Home Automation Neil Cherry .....ncherryspam_OUTlinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

On Nov 14, 2007, at 7:16 AM, Peter Todd wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Nov 14, 2007 at 08:46:01AM +0100, wouter van ooijen wrote: >>> http://arastra.com/recruit/quiz.py >> >> 1. UDP is preferred over TCP for VoIP mainly because: >> >> IMHO the correct answer is: Compared to UDP, TCP provides additional >> services, like reliability using an acknowledge/timeout/resend >> mechanism. Such additional services (like delayed reliability) are >> of no >> use in a voice context. > > Yeah, gotta agree with you on that one. Simply put, a late TCP > packet is > still usefull, a late VOIP packet isn't. Depends on how big your buffers are, and if you have enough CPU and/or DSP horsepower to reassemble the correct order fast enough to recover -- before the end user hears it. ;-) Problem is -- in most VoIP applications, any appreciable delay in audio coming out the handset into a typical "not perfect" hybrid on any standard 2-wire phone, creates echo back to the calling party. This happens because you can't get too far behind or you fall out of the window of the PSTN carrier's DSP-based echo-cancellation buffers -- especially on International circuits/calls which are heavily DSP processed and echo-cancelled because of the natural latency of the distances involved. :-) :-) :-) Ah, the joys of the modern PSTN. -- Nate Duehr TakeThisOuTnate.....TakeThisOuTnatetech.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Nov 15, 2007 at 02:10:34AM -0700, Nate Duehr wrote: {Quote hidden}> Depends on how big your buffers are, and if you have enough CPU and/or > DSP horsepower to reassemble the correct order fast enough to recover > -- before the end user hears it. ;-) > > Problem is -- in most VoIP applications, any appreciable delay in > audio coming out the handset into a typical "not perfect" hybrid on > any standard 2-wire phone, creates echo back to the calling party. > > This happens because you can't get too far behind or you fall out of > the window of the PSTN carrier's DSP-based echo-cancellation buffers > -- especially on International circuits/calls which are heavily DSP > processed and echo-cancelled because of the natural latency of the > distances involved. Is there the same effect in any way with cell phones on either end? They use seperate audio channels for each direction, and then synthesize some "talk-back" right? Just thinking, cause I often hear heavy echo from my voice when my brother in Australia calls me on cheap VoIP calling cards. - -- http://petertodd.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPHaQ3bMhDbI9xWQRAh/SAKCZUOS74rnpOr0rbNZLbFAhsQHElwCbBXox adOcvWuq/11aNJFrCyjR/ZE= =e6GK -----END PGP SIGNATURE-----

On Nov 15, 2007, at 9:40 AM, Peter Todd wrote: > Is there the same effect in any way with cell phones on either end? > They > use seperate audio channels for each direction, and then synthesize > some > "talk-back" right? Most cell phones create the "sidetone" (hearing your own voice) right in the handset. The person on the other end is usually hearing you about 200ms or longer after you actually said something. > Just thinking, cause I often hear heavy echo from my voice when my > brother in Australia calls me on cheap VoIP calling cards. Yup. Mixing IP with a network that was originally all synchronous is definitely interesting... it's not TOO bad when you're just talking one phone to one phone, but since I work on conferencing systems... Imagine the joys of listening to three people calling from Skype, two on cell phones, one in a big conference room with echo off the glass walls (room designers, take note -- round rooms and glass in the walls makes for a pretty, but very stupid acoustic setup for a conference room!) and one poor soul on his "antiquated" home POTS phone. Out of all of those callers being muxed together, guess who sounds the best? :-) Now imagine the conferencing system is fed with VoIP from the carrier's network, and the backbone is compressing all that audio with something like G.729, and the guys on Skype are experiencing packet loss to whatever network-du-jour they're on from their laptops. Now add in video. I have a feeling I'll have a "support" job for as long as I want one. None of this VoIP stuff is bringing anything to the engineering table in the way of quality or reliability. I'm about to drop my VoIP consumer-grade service at home and re- install a good old POTS line. It was more reliable, more flexible (try placing a modem call through a VoIP service or sending faxes at any reasonable speed, of course you can't...), powered by someone else, I didn't have to maintain any equipment myself, and 911 worked. For $5 a month more, I'd say it's worth it. -- Nate Duehr .....nateRemoveMEnatetech.com

On Thu, 2007-11-15 at 13:38 -0700, Nate Duehr wrote: > I'm about to drop my VoIP consumer-grade service at home and re- > install a good old POTS line. It was more reliable, FWIW my VOIP has been extremely reliable. Even if it wasn't it has a feature where if the VOIP is down incoming calls get forwarded to your cell phone, it's awesome! > more flexible > (try placing a modem call through a VoIP service or sending faxes at > any reasonable speed, of course you can't...), powered by someone Placing a modem call over a VOIP line seems kinda counter intuitive since you already HAVE an internet connection to use the VOIP!? That said, I have tried dial up over my VOIP (wanted to make sure my laptop modem actually worked before I went on the road) and the result wasn't pretty (only got a 300bps connection), but then I didn't expect it to be. For fax I wouldn't know since I either use one of the online fax sending services, or just send the fax at work, which is pretty rare anyways these days. I send maybe 10 faxes a year... > else, I didn't have to maintain any equipment myself, and 911 worked. I'm not sure what country you are in (the US?), but 911 works on my VOIP line (I'm in Canada). Although I've never tried it (that's a good thing) AFAIK it does work. That said, I've got two cell phones in the house as well, plus my internet connection is over DSL on a phone line with no voice service, but does have emergency service, so I think I'm covered. > For $5 a month more, I'd say it's worth it. Difference for me is on the order of about $25/month, and that's assuming I never call long distance, which I do, quite a bit, so the actual difference is probably much more considering the insane rates long distance is charged by the local POTS provider. TTYL

Nate Duehr wrote: > On Nov 15, 2007, at 9:40 AM, Peter Todd wrote: > Yup. Mixing IP with a network that was originally all synchronous is > definitely interesting... it's not TOO bad when you're just talking > one phone to one phone, but since I work on conferencing systems... > > Imagine the joys of listening to three people calling from Skype, two > on cell phones, one in a big conference room with echo off the glass > walls (room designers, take note -- round rooms and glass in the walls > makes for a pretty, but very stupid acoustic setup for a conference > room!) and one poor soul on his "antiquated" home POTS phone. > > Out of all of those callers being muxed together, guess who sounds the > best? :-) POTS Line! > I'm about to drop my VoIP consumer-grade service at home and re- > install a good old POTS line. It was more reliable, more flexible > (try placing a modem call through a VoIP service or sending faxes at > any reasonable speed, of course you can't...), powered by someone > else, I didn't have to maintain any equipment myself, and 911 worked. > For $5 a month more, I'd say it's worth it. I just dumped my VoIP not because there was anything wrong with the VoIP but because I had to depend on the IP service of my cable ISP. Their normal cable services are not battery backed up. I also had Asterisk up and running with the SPA-3000 and the big problem was the echo (soft DSP) vs. call volume at the handset. Turn up the volume and you'd get echo. Get rid of the echo and you lost your volume. Currently a hardware DSP would cost too much for just fooling around so I shut it for now. Eventually it will be VoIP but for a little bit longer I'll be sticking with a POTS line. -- Linux Home Automation Neil Cherry RemoveMEncherryspamBeGonelinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies

On Nov 15, 2007, at 2:01 PM, Herbert Graf wrote: >> more flexible >> (try placing a modem call through a VoIP service or sending faxes at >> any reasonable speed, of course you can't...), powered by someone > > Placing a modem call over a VOIP line seems kinda counter intuitive > since you already HAVE an internet connection to use the VOIP!? Some of us still have to use modems to access customer/secured networks. Really. It'd be nice if they'd install a VPN router, but they don't. > For fax I wouldn't know since I either use one of the online fax > sending > services, or just send the fax at work, which is pretty rare anyways > these days. I send maybe 10 faxes a year... Most large companies require faxes of expense reports. If I feel like finishing up that paperwork from home instead of dragging it back and forth from home to office, I must fax from here. {Quote hidden}>> else, I didn't have to maintain any equipment myself, and 911 worked. > > I'm not sure what country you are in (the US?), but 911 works on my > VOIP > line (I'm in Canada). Although I've never tried it (that's a good > thing) > AFAIK it does work. That said, I've got two cell phones in the house > as > well, plus my internet connection is over DSL on a phone line with no > voice service, but does have emergency service, so I think I'm > covered. Mine gets sent first to a call-center that confirms location, etc... before going to the local 911 dispatch office. Having a middle-man isn't a good idea in a real emergency. >> For $5 a month more, I'd say it's worth it. > > Difference for me is on the order of about $25/month, and that's > assuming I never call long distance, which I do, quite a bit, so the > actual difference is probably much more considering the insane rates > long distance is charged by the local POTS provider. That's a significant difference in price. As far as long-distance, that's easily handled by my cell phone, these days. > Everyone's needs are different, I guess. I'm heavily involved in VoIP technologies at work, but find that a normal POTS line both performs better and makes more sense for the uses I have at home, after using a VoIP service for a year. -- Nate Duehr spamBeGonenate@spam@spam_OUTnatetech.com

On Nov 16, 2007 8:34 PM, Nate Duehr <TakeThisOuTnatespamnatetech.com> wrote: > Everyone's needs are different, I guess. I'm heavily involved in VoIP > technologies at work, but find that a normal POTS line both performs > better and makes more sense for the uses I have at home, after using a > VoIP service for a year. The company I am working for is using Cisco IP phones. It is quite useful but it does not really pass the endurance test IMHO. Last Wednesday evening, we had a 3 hour conference about SAP using the CISCO IP phone and Microsoft Netmeeting. Microsoft Netmeeting worked through the 3 hours. The Cisco phone failed once here in Singapore (have to power cycle it). I am not so sure if the other side (Cleveland) is using CISCO or not but it also failed once. At home, I am always using international calling cards with the land phone. I think they are using partially IP based service. Never feel the need to use Skype or other PC based service. Xiaofan

Xiaofan Chen wrote: > The company I am working for is using Cisco IP phones. It is > quite useful but it does not really pass the endurance test > IMHO. Last Wednesday evening, we had a 3 hour conference > about SAP using the CISCO IP phone and Microsoft > Netmeeting. [Minor SAP/Siebel rant mode on.] Yep, SAP is hideous bloatware that will cause many more 3 hour conference calls. Everyone's using it, and it's great at lowering productivity worldwide now. Almost ubiquitous with "I can't get my job done because the SAP designers forgot a field on the screen or it's greyed out and I don't have access to it." SAP is probably the worst, with Siebel running a close second place in software that singlehandedly creates thousands of hours of unnecessary work. Things that used to be easy prior to these all-encompassing bloated tracking systems are now difficult. They don't add any real value other than that the CEO can tell his golfing buddies that "we're using it now too". [Rant mode off.] > Microsoft Netmeeting worked through the 3 hours. > The Cisco phone failed once here in Singapore (have to power cycle > it). I am not so sure if the other side (Cleveland) is using CISCO or > not but it also failed once. The whole phone crashed? That's odd. Sounds like a problem locally on the LAN or in CallManager if that's what they're using there as a gateway. Were you using the pass-through port on the phone for the Ethernet connection to the PC that was running Netmeeting? Maybe the phone became a bit overloaded. (Disclaimer: I work for a Cisco competitor, but I'll be nice. You can always buy our phones. They work very well! GRIN! No offense to William here on the list!) > At home, I am always using international calling cards with the > land phone. I think they are using partially IP based service. > Never feel the need to use Skype or other PC based service. A very large percentage of traffic carried internationally is now on IP, even if you came in from the PSTN. Economically, the last few years it made more sense for carriers to start to upgrade the core switching and turn it into packet-switched networks, than to throw out PSTN switches right away. Their depreciation cycles are 10 years or more on that big gear. Sonus gateways are very popular in International call routing circles. http://www.sonusnet.com/ Audiocodes seems to be popular for gateways out from IP to PSTN older gear. http://www.audiocodes.com/ And of course Cisco... http://www.cisco.com Nate

On Nov 16, 2007, at 4:04 PM, Nate Duehr wrote: > The whole phone crashed? That's odd. Indeed. Everyone (?) in cisco has an IP phone on their desk, and you can be sure that there would be many a flamewar on internal mailing lists if they were prone to crashing. OTOH, it's been a while since I've been on a 3-hour conference call. > Were you using the pass-through port on the phone for the Ethernet > connection to the PC that was running Netmeeting? Maybe the phone > became a bit overloaded. I'm pretty sure the "pass through port" is an off-the-shelf hub or switch IC; I don't think that the phone CPU becomes involved in passing through LAN traffic. (caveat: I don't work in the IP phone or even the VoIP arenas...) > (Disclaimer: I work for a Cisco competitor, but I'll be nice. You can > always buy our phones. They work very well! GRIN! No offense to > William here on the list!) None taken. :-) BillW

On Nov 17, 2007 8:20 AM, William Chops Westfield <westfwEraseMEmac.com> wrote: > > On Nov 16, 2007, at 4:04 PM, Nate Duehr wrote: > > > The whole phone crashed? That's odd. > > Indeed. Everyone (?) in cisco has an IP phone on their desk, and > you can be sure that there would be many a flamewar on internal > mailing lists if they were prone to crashing. OTOH, it's been a > while since I've been on a 3-hour conference call. It is odd. I have the CISCO IP phone at work as well and I use the pass-through all day. It has never crashed. > > Were you using the pass-through port on the phone for the Ethernet > > connection to the PC that was running Netmeeting? Maybe the phone > > became a bit overloaded. > > I'm pretty sure the "pass through port" is an off-the-shelf hub > or switch IC; I don't think that the phone CPU becomes involved > in passing through LAN traffic. (caveat: I don't work in the > IP phone or even the VoIP arenas...) > At the day, we were using wireless on the notebooks since it is in a conference room with many people. So we were not using pass through port anyway. And yes SAP (aka Slow And Problematic) is a big headache and delayed the schedule of quite some project by one or two months. But it is not too bad once it is up and running. I was actually doing only two thing over the pass three weeks: checking PCB layout and doing SAP related work. Xiaofan

On Nov 16, 2007, at 6:06 PM, Dave Lagzdin wrote: > On 16/11/2007, Nate Duehr <@spam@nateRemoveMEEraseMEnatetech.com> wrote: >> >> ... >> made more sense for carriers to start to upgrade the core switching >> and >> turn it into packet-switched networks, than to throw out PSTN >> switches >> right away. Their depreciation cycles are 10 years or more on that >> big >> gear. >> > > > I think you are a few decades short there Nate, > IIRC: A 4E is basically a souped up 1E which would have been > installed in > the 60's?/70's? The 4E's are the "stuff" that's being replaced in the core at most carriers by VoIP. In most cases the 4E's are now "front-ends" for VoIP switches... at least on a few carrier's networks. The newer 5E's and DMS-250's are the ones that are still (just barely) still depreciating. They are being augmented by IP gateways however, depending on whether the CPE equipment wants a traditional PSTN TDM/ digital interface (T1, T3) or IP. Most carriers implemented either a soft or a hard ban on purchasing TDM-based gear on long-term capital budgets about two years ago, depending on whether or not they thought they could get VoIP-interface CPE gear for their value-added features/products. -- Nate Duehr EraseMEnate@spam@natetech.com

Nate Duehr wrote: {Quote hidden}> On Nov 16, 2007, at 6:06 PM, Dave Lagzdin wrote: > >> On 16/11/2007, Nate Duehr <@spam@natespam_OUT.....natetech.com> wrote: >>> ... >>> made more sense for carriers to start to upgrade the core switching >>> and >>> turn it into packet-switched networks, than to throw out PSTN >>> switches >>> right away. Their depreciation cycles are 10 years or more on that >>> big >>> gear. >>> >> >> I think you are a few decades short there Nate, >> IIRC: A 4E is basically a souped up 1E which would have been >> installed in >> the 60's?/70's? > > The 4E's are the "stuff" that's being replaced in the core at most > carriers by VoIP. In most cases the 4E's are now "front-ends" for > VoIP switches... at least on a few carrier's networks. > > The newer 5E's and DMS-250's are the ones that are still (just barely) > still depreciating. They are being augmented by IP gateways however, > depending on whether the CPE equipment wants a traditional PSTN TDM/ > digital interface (T1, T3) or IP. A 4E is a long distance switch while a 5E is a local switch. I think that 5E's can support IP but don't quote me on that. I can't comment any further other to say that AT&T began replacing their 4E since the early/mid 90's when Lucent announced that no new software was being developed for the switches (just bug fixes). -- Linux Home Automation Neil Cherry spamBeGonencherryEraseMElinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies