Searching \ for '[OT] About writing tests for employment interviews' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=about+writing+tests
Search entire site for: 'About writing tests for employment interviews'.

Exact match. Not showing close matches.
PICList Thread
'[OT] About writing tests for employment interviews'
2007\11\12@132455 by Peter P.

picon face
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 P.


2007\11\12@214348 by Vitaliy

flavicon
face
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

2007\11\12@230754 by Nate Duehr

face
flavicon
face

On Nov 12, 2007, at 7:42 PM, Vitaliy wrote:

{Quote hidden}

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_OUTnateTakeThisOuTspamnatetech.com

2007\11\13@011240 by Peter P.

picon face
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.


2007\11\13@084315 by Martin Klingensmith

face
flavicon
face


Nate Duehr wrote:
{Quote hidden}

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

2007\11\13@105447 by William \Chops\ Westfield

face picon face
So here's another one; sorta interesting.  Harder, I think:

http://arastra.com/recruit/quiz.py

2007\11\13@120658 by Vitaliy

flavicon
face
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.


2007\11\13@123025 by Martin Klingensmith

face
flavicon
face
Martin Klingensmith wrote:
{Quote hidden}

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

2007\11\13@123539 by Bob Axtell

face picon face
Vitaliy wrote:
{Quote hidden}

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

2007\11\13@131011 by Nate Duehr

face
flavicon
face

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
.....nateKILLspamspam.....natetech.com



2007\11\13@222202 by John Chung

picon face

--- "William \"Chops\" Westfield" <EraseMEwestfwspam_OUTspamTakeThisOuTmac.com>
wrote:

> So here's another one; sorta interesting.  Harder, I
> think:
>
> http://arastra.com/recruit/quiz.py
> --

2007\11\13@223600 by Neil Cherry

picon face
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       ncherryspamspam_OUTlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\13@233520 by John Chung

picon face
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@ncherryKILLspamspamcomcast.net> wrote:

{Quote hidden}

> --

2007\11\13@235511 by William \Chops\ Westfield

face picon face

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

2007\11\14@005922 by Neil Cherry

picon face
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       RemoveMEncherryTakeThisOuTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\14@012307 by John Chung

picon face

--- "William \"Chops\" Westfield" <spamBeGonewestfwspamBeGonespammac.com>
wrote:

{Quote hidden}

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

2007\11\14@012636 by Cedric Chang

flavicon
face

> 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

2007\11\14@024107 by William \Chops\ Westfield

face picon face

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

2007\11\14@024606 by wouter van ooijen

face picon face
> 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




2007\11\14@031616 by William \Chops\ Westfield

face picon face

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!

BillW

2007\11\14@075849 by Neil Cherry

picon face
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       TakeThisOuTncherryEraseMEspamspam_OUTlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\14@080207 by Neil Cherry

picon face
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       RemoveMEncherryspamTakeThisOuTlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\14@092328 by Peter Todd

picon face
-----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-----

2007\11\14@092451 by Rolf

face picon face
William "Chops" Westfield wrote:
{Quote hidden}

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

2007\11\14@133646 by William \Chops\ Westfield

face picon face

>> Question 9. A singly linked list is often a good way to represent

I had an interesting discussion with the guy at arastra, and the
question has been changed slightly (it now makes clear that there
is only a "head" pointer, rather than the two pointers that make
for a reasonable queue...)

BillW

2007\11\14@133906 by William \Chops\ Westfield

face picon face

On Nov 13, 2007, at 11:46 PM, wouter van ooijen wrote:

> 2. Consider a lossless dedicated gigabit Ethernet link
>
> Wow, I might once have been able to calculate this, but no more.

It's easier than you think.  Since the link speed is higher than
the delay*bandwidth product, your speed is limited to one TCP
window (64kbytes) per round trip time.

BillW

2007\11\14@140344 by William \Chops\ Westfield

face picon face

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

2007\11\14@143942 by Rolf

face picon face
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

2007\11\14@165809 by wouter van ooijen

face picon face
> 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



2007\11\14@174414 by Neil Cherry

picon face
William "Chops" Westfield wrote:
>>> Question 9. A singly linked list is often a good way to represent
>
> I had an interesting discussion with the guy at arastra, and the
> question has been changed slightly (it now makes clear that there
> is only a "head" pointer, rather than the two pointers that make
> for a reasonable queue...)

Thanks much better!

--
Linux Home Automation         Neil Cherry       ncherryEraseMEspam.....linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\14@175816 by Rolf

face picon face
wouter van ooijen wrote:
{Quote hidden}

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

2007\11\14@182836 by Neil Cherry

picon face
Rolf wrote:
{Quote hidden}

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       EraseMEncherryspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\14@195416 by William \Chops\ Westfield

face picon face

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

2007\11\14@202647 by Xiaofan Chen

face picon face
On 11/13/07, William Chops Westfield <RemoveMEwestfwEraseMEspamEraseMEmac.com> wrote:
> So here's another one; sorta interesting.  Harder, I think:
>
> http://arastra.com/recruit/quiz.py

I failed quite badly, only managed to get 4 out of 10. ;-( ;-( ;-(

Xiaofan

2007\11\14@225528 by John Chung

picon face
same here!!!!!

John


--- Xiaofan Chen <RemoveMExiaofancspam_OUTspamKILLspamgmail.com> wrote:

{Quote hidden}

> --

2007\11\15@000219 by Xiaofan Chen

face picon face
On 11/15/07, John Chung <EraseMEkravnusspamspamspamBeGoneyahoo.com> wrote:
> --- Xiaofan Chen <RemoveMExiaofancKILLspamspamgmail.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

2007\11\15@002750 by John Chung

picon face
--- Xiaofan Chen <xiaofancSTOPspamspamspam_OUTgmail.com> wrote:

> On 11/15/07, John Chung <spamBeGonekravnusSTOPspamspamEraseMEyahoo.com> wrote:
> > --- Xiaofan Chen <KILLspamxiaofancspamBeGonespamgmail.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

2007\11\15@012606 by Neil Cherry

picon face
John Chung wrote:
{Quote hidden}

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_OUTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\15@041038 by Nate Duehr

face
flavicon
face

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.....spamTakeThisOuTnatetech.com

2007\11\15@082308 by Dave Lagzdin

picon face
On 15/11/2007, Nate Duehr <TakeThisOuTnateKILLspamspamspamnatetech.com> wrote:
>
>
> 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.
>
> --
>

Or the old echo cancellers that didn't recognize data calls?
That was trouble shooting fun...

2007\11\15@135059 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Nov 15, 2007 at 02:10:34AM -0700, Nate Duehr wrote:
{Quote hidden}

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-----

2007\11\15@153909 by Nate Duehr

face
flavicon
face

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
.....natespamRemoveMEnatetech.com

2007\11\15@160115 by Herbert Graf

flavicon
face
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

2007\11\15@160211 by Neil Cherry

picon face
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       RemoveMEncherryspamspamBeGonelinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2007\11\15@163206 by Dario Greggio

face picon face
Herbert Graf wrote:

>>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

5/10EUR in here too (Italy)
and I agree that it is worth... if you need any voice feature on that
line...


--
Ciao, Dario
--
ADPM Synthesis sas - Torino
--
http://www.adpm.tk

2007\11\15@165453 by David VanHorn

picon face
> 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.


Oh yeah... :-P  Former modem designer, and happy to be in that status.

2007\11\16@073448 by Nate Duehr

face
flavicon
face

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}

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@spamspam_OUTnatetech.com



2007\11\16@075438 by Xiaofan Chen

face picon face
On Nov 16, 2007 8:34 PM, Nate Duehr <TakeThisOuTnatespamspamnatetech.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

2007\11\16@190249 by Nate Duehr

face
flavicon
face
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

2007\11\16@192101 by William \Chops\ Westfield

face picon face

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

2007\11\16@193443 by Xiaofan Chen

face picon face
On Nov 17, 2007 8:20 AM, William Chops Westfield <westfwEraseMEspammac.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

2007\11\16@200610 by Dave Lagzdin

picon face
On 16/11/2007, Nate Duehr <RemoveMEnateEraseMEspamspam_OUTnatetech.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?

Dave

2007\11\16@225244 by Nate Duehr

face
flavicon
face

On Nov 16, 2007, at 6:06 PM, Dave Lagzdin wrote:

> On 16/11/2007, Nate Duehr <@spam@nateRemoveMEspamEraseMEnatetech.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
EraseMEnatespam@spam@natetech.com

2007\11\16@233437 by Neil Cherry

picon face
Nate Duehr wrote:
{Quote hidden}

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       spamBeGonencherryEraseMEspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...