If you would try prototypes (and you really do not want to do that unless you know pretty well what you are doing) you can try this:

use Modern::Perl;

sub no_ref(\@\@) {
    my ($first, $second) = @_;
    say "First:  @$first";
    say "Second: @$second";
}

my @alfa = (1 .. 10);
my @beta = ('a' .. 'j');

no_ref @alfa, @beta;
[download]

First:  1 2 3 4 5 6 7 8 9 10
Second: a b c d e f g h i j
[download]

without reference, we can do by splitting and merging the arrays.

As I said, by jumping through a lot of hoops. :)

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

(@listc, @listd) = simplesort(\@lista, \@listb);

sub simplesort
{
   my ($listaref, $listbref ) = @_;

   # De-reference the array list
   my (@lista) = @$listaref;
   my (@listb) = @$listbref;
   # Now you can play with both arrays.
}
[download]

I mentioned without references.

Just use references. Oh, and tell the interviewer its a stupid question.

Thanks Sir.

You could add a parameter that gives the length of the first array like this:

&d(scalar(@a),@a, @b);

sub d{
  my ($len,@c)= @_;
  my @d= splice(@c,$len);
  ...
[download]

But you really need a good reason to do that, this is 2/3 of a bad hack. Use references (and strict and warnings, by the way)

UPDATE: Typo in the script corrected. Thanks go to CountZero for finding it

If you want to walk on the wild side, you can use the (very) old-fashioned typeglob arguments for passing something like a reference that is yet not (quite) a reference... technically... I guess... See Typeglobs and Filehandles in perldata.

>perl -wMstrict -le
"use Data::Dumper;
 ;;
 our @a = (1, 2, 3, 4);
 our @b = (9, 8, 7, 6);
 f(*a, *b);
 ;;
 sub f {
   local (*c, *d) = @_;
   print Dumper \*c;
   print Dumper \*d;
   print @::c;
   print @::d;
   }
"
$VAR1 = \*::a;

$VAR1 = \*::b;

1234
9876
[download]

(OTOH, the prototype answer given by CountZero is probably what your interviewer/teacher is looking for.)

I shudder to think about a teacher or interviewer who wishes to check if the student or interviewee knows about such *forbidden* knowledge as prototypes. Personally I will give better marks to someone who says it needs to be done with references than to someone who immediately thinks about prototypes and still calls subroutines the "ampersand" way, thus utterly defeating the use of prototypes. Those are not the people you want to tinker with the control program of your nuclear reactor.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James