Implementing a stack and using it to print alternate elements in reverse
Since you passed this may be a moot point,
but if this was an interview question,
when the spec says "implement an interface",
I would expect to see an interface:

public interface Stack&lt;T&gt; {

    void push(T item);

    T pop();
}


And an implementation:

public class StackImpl&lt;T&gt; implements Stack&lt;T&gt; {

    LinkedList&lt;T&gt; list = new LinkedList&lt;&gt;();

    @Override
    public void push(T item) {
        list.add(item);
    }

    @Override
    public T pop() {
        return list.removeLast();
    }
}


It's better to separate the interface, the implementation, and the runnable.
So the code of the main program,
and the retrieveAlternates method doesn't belong in a Stack class.

Also note that you don't need a stack at all to solve the problem.
You can just reference the elements of the input by the right indexes,
and you don't need to convert them to integers either:

static String retrieveAlternates(String[] input) {
    StringBuilder result = new StringBuilder();

    for (int i = 0; i &lt; input.length; i++) {
        if ((i &amp; 1) == 0) {
            result.append(' ').append(input[input.length - i - 1]);
        }
    }

    return result.substring(1);
}


I know this is cheating,
but actually,
you're already cheating when you implement a Stack interface using a LinkedList...
At an interview I would expect that you'd have to implement an array-backed stack or something,
without using the wonderful high level elements of the JDK.

Unit testing

Oddly, your unit tests have syntax errors: () missing from test1(),
and both tests call a method whose signature doesn't exist.
It's as if you've never run these tests,
just typed them up here because you know I would pick on not having any tests...

Also, test1 and test2 are not good names:
it's best when tests have descriptive names,
so that they are easier to understand,
both when reading the code later,
and when something fails and reading the error messages.

I would propose this naming style:

@Test
public void test_1_2_3_4_gives_4_2() {
    assertEquals("4 2", Solution.retrieveAlternates("1 2 3 4".split("\\s+")));
}

@Test
public void test_10_m2_3_4_gives_4_m2() {
    assertEquals("4 -2", Solution.retrieveAlternates("10 -2 3 4".split("\\s+")));
}


The splitting, necessitated by the method under test is tedious,
using new String[]{ ... } in each test case would also be tedious,
so I'd suggest to simplify using a helper method:

void assertAlternates(String expected, String input) {
    assertEquals(expected, Solution.retrieveAlternates(input.split("\\s+")));
}

@Test
public void test_1_2_3_4_gives_4_2() {
    assertAlternates("4 2", "1 2 3 4");
}

@Test
public void test_10_m2_3_4_gives_4_m2() {
    assertAlternates("4 -2", "10 -2 3 4");
}


And I suggest adding some more potential corner cases:

@Test
public void test_1_gives_1() {
    assertAlternates("1", "1");
}

@Test
public void test_1_2_gives_2() {
    assertAlternates("2", "1 2");
}


Note that I'm not following camelCase for test method naming.
I'm not aware of a standard for this,
and static code analysis tools like Sonar don't complain about this kind of naming,
even though I'm using the most strict rule set.

Keep in mind that unlike regular code,
it's acceptable (and even recommended) to use long names for test methods.
And these names tend to get long,
snake_case is far more readable (in my opinion) than camelCase.