Could my algorithm be considered Divide-and-Conquer? So for my homework, I was supposed to design an algorithm which was divide-and-conquer that fulfilled the task of finding the two smallest numbers in an array of size n. 

I recognize that my version is a bit cheap in that regard, in that it uses reference variables and only does work on the size 1 cases of the recursion. Is this still technically considered divide-and-conquer? Or is it practically too close to a linear search. If it is divide-and-conquer, how could you express the recurrence relation when the work is being done only on the "leaves" of the recursion.  

   find_mins(int A[], int&amp; min, int&amp; sec_min, int l, int r){
    int pivot = (l+r)/2;

    if(l==r){
      if(A[l] &lt; min){
        sec_min = min;
        min = A[l];
        return;
      }
      else if(A[l] &lt; sec_min &amp;&amp; A[l] &gt; min){
        sec_min = A[l];
        return;
      }
      return;
    }

    find_mins(A,min,sec_min,1,pivot);
    find_mins(A,min,sec_min,pivot+1,r);


}

"Pseudocode"

FUNCTION(Array, min1, min2, left, right)
  Find pivot
  if(size of subproblem is 1)
    calculate mins
  function(Array,min1,min2,1, pivot)
  function(array,min1,min2,pivot+1,right)


Keep in mind, the code really isn't all that relevant, I just am curious if the structure fits divide-and-conquer description. My concern is that because work is only being done on the case where the size is 1, that it's more of a "linear search" than anything else.
TL;DR
Divide and concur doesn't have any rigorous definition.  So any argument you make for or against will be just an emotional argument.  The situation is made worse by the fact that the task accomplished by this algorithm doesn't need D&amp;C.  So, the answer is &quot;probably&quot;.
Long version
One scenario where it would make sense to use D&amp;C in finding the minimum is a distributed system (eg. Hadoop), where the size of input may require from you that you do computation in chunks.  The algorithm as you designed it is not suitable for this task because it would have to communicate the best result found so far to all parts of the program handling the computation of each chunk.  The version I've written below eliminates this problem by computing local minima for given sublists and then calculating the minima of the previously computed minima and so on.  This feels (remember emotional argument?) more like D&amp;C.  Besides, it makes the algorithm more language-agnostic and eliminates the corner-case errors.

Empty lists have no minimum.
Lists with only one element have only one minimum (not two).
If a list happens to have more than one minimum element, then the second minimum will be equal to first minimum.
Solution doesn't require guessing the minimum before running the algorithm.

The code is set in Prolog.  I believe it is better than conventional pseudo-Pascal in that it allows to avoid &quot;uninteresting&quot; parts of the algorithm.
two_mins([], _, _) :- !, fail.  /* Empty list has no minimum */
two_mins([Min1], Min1, _) :- !. /* There is only one element */
two_mins([Min1, Min2], Min1, Min2) :- Min1 &lt; Min2, !.
two_mins([Min1, Min2], Min2, Min1) :- !.
two_mins(List, Min1, Min2) :-
    length(List, N),
    LenA is N div 2,
    length(A, LenA),
    append(A, B, List),
    two_mins(A, Min1A, Min2A),
    two_mins(B, Min1B, Min2B),
    Min1 is min(Min1A, Min1B),
    /* In case A or B had only one element, we will get
       rid of non-instantiated solutions. */
    include(ground, [Min2A, Min2B], Ground),
    min_list([max(Min1A, Min1B) | Ground], Min2).