# ETOOBUSY ðŸš€ minimal blogging for the impatient

# Leader element

**TL;DR**

My second week into the Perl Weekly Challenge - and a reflection.

It seems that the Perl Weekly Challenge challenges this week are a bit
*easier* than the last week. Or are they?

The task #1 is this:

You are given an array

`@A`

containing distinct integers. Write a script to find all leader elements in the array @A. Print (0) if none found. An element is leader if it is greater than all the elements to its right side.

Its solution is somehow straightforward, it suffices to go backwards to figure out whoâ€™s a leader:

```
1 #!/usr/bin/env perl
2 use 5.024;
3 use warnings;
4
5 # This problem is easier to tackle if moving from the *end* of the array
6 # back to the beginning. So, we reverse the input array to analyze it
7 # and then reverse it again to get back to the original order.
8 sub keep_leaders { # @A <=> @_
9 return (0) unless @_;
10 my $last_leader = $_[-1] - 1;
11 return reverse grep {
12 my $condition = $_ > $last_leader;
13 $last_leader = $_ if $condition;
14 $condition;
15 } reverse @_;
16 }
17
18
19 # testing stuff
20 for my $Aref (
21 [9, 10, 7, 5, 6, 1],
22 [3, 4, 5],
23 [],
24 ) {
25
26 printout('Input: @A = ', @$Aref);
27 printout('Output: ', keep_leaders(@$Aref));
28 }
29
30 sub printout {
31 my $prefix = shift;
32 say $prefix, '(', join(', ', @_), ')'
33 }
```

It also got me thinking that there were such *somehow simpler* solutions
last time, at least with respect to mine.

The bottom line is that these challenges resemble a lot those that you
might get in interviews: the basic info to get *some* solution, but not
enough to get *the* solution. In this way, people can see how you react,
e.g. to check whether you ask questions, whether you think about corner
cases, limitsâ€¦ in brief, to see your though process.

In this case, for example, it might make sense to understand whether
using `reverse`

is the right way to go, as opposed to e.g. scan the
array backwards. Or even ask whether thereâ€™s a limit on the possible
input values, how many will be of them, if we have memory constraints,
time constraintsâ€¦ the list goes on.

Last time for Fibonacci, for example, I definitely avoided finding solution with a brute force search over all possible arrangements of the Fibonacci candidates, and went the much harder way of figuring out the most compact solution and then working from that, chipping off the remaning overlaps.

For low input numbers, in hindsight this probably makes no sense. This
approach probably starts paying off with way bigger numbers. So in a
sense that complicated solution was a reflection of my inner self that
usually aims at solving a problem and forgetting about it - with enough
lazyness and hubris that will will even work if someone decides to put a
very big number in. Call me *defensive*.

On the other hand, this is a wonderful occasion to realize that itâ€™s not always like this.

By making questions in an interview, you might be told that the numbers
will always be below a threshold, etc. so it might make sense to express
the different alternatives loud and say that there is a brute force
solution that will save programmer time at the expense of some
performance, and that there is a more *linear* solution that requires
more time to code and test.

At the end of the day, this is probably what theyâ€™re after.