Re: [tlug] No video playback in Iceweasel

[Josh Glover <jmglov@example.com>]

On 5 December 2014 at 09:52, Benjamin Kowarsch <trijezdci@example.com> wrote:

> Coding as part of the interview process is part of the problem, not
> part of a solution.
>
> It favours practitioners who jump right into coding without any
> requirements solicitation process, without any design, without any
> implementation plan.

I wouldn't say that at all.

The point of a programming assignment as part of an interview process
is to weed out candidates who produce awful code, which, as I said, is
the majority (by this, I mean slightly over half, not a *vast*
majority). The "requirements solicitation process" for such an
assignment is me sending an email with the problem description, fully
specified, but containing at least one slight ambiguity or
incompleteness. I expect a candidate, in the course of designing the
solution (which she must do to be successful, but I don't care *how*
she designs it), to ask for clarification on the unclear bits.

Just to be clear, this is not something I expect a person to do whilst
sitting in an interview room. It is rather a tiny programming
assignment that should be doable in a couple of hours in the comfort
of the person's own home.

I do also ask a coding question in my face-to-face technical
interview, and it is a dead-simple one: reverse an array *in place* in
the language of your choice. Writing code on a whiteboard is hard,
even for a simple task like this, and it gives me a chance to see how
a candidate deals with pressure, whether she tests her code before
declaring it done, and how she defends her choices and fixes bugs
(I've never seen a solution that didn't have at least one tiny issue,
like failing to handle a null in C or something along those lines).

> The kind of person who will excel in such a test
> is the kind of person that is not accustomed to proper process.

I submit that no interview can assess how a candidate will perform in
the job for which you're hiring. Rather, you want to look for danger
signs, and the best way to do that, in my experience, is to come at
the assessment from several different angles, and dig deeper into
areas you're worried about.

> Preparation takes time and it has to be practised in order to be mastered.

True, but the style of preparation that works for one person may not
work for another.

> To produce quality, there has to be a proper requirements solicitation
> process, [...] a proper design process, [...] [and] a risk management and
> planning process[.]
>
> Only at that point should any coder be allowed to write the first line of code.

Oh my. How is this not Waterfall software development?

> Foregoing proper preparation is precisely the reason why software is
> so bad these days, why projects go out of scope, over time and over
> budget.

I personally think that failing to decompose and iterate is a bigger
danger to the success of a project.

> Unfortunately, this is common practise now, and as a result, the art of thinking and
> weighing before doing has been lost.

On what evidence do you base this statement?

For some, sketching in code is a very good way to start thinking and
organising. Others find hammock time[1] more useful. Others use
whiteboards and colleagues to do this.

I personally think the approach you are advocating is how software has
been developed in large corporations for many years, and that we as an
industry are learning from those mistakes and figuring out how to
accomplish more faster and with smaller teams, turning out *better*
quality code, and delivering more value to our users.

Cheers,
Josh