cursork

Absolutely this. When facing a tough problem it’s a great tactic to write out what you’re trying to solve and how you plan to solve it in prose-style English.

I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.

I’d also add that a very prototype that you throw away also helps line up your thoughts.

The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code

I agree with this to a large extent. A new codebase in the latest Java/whatever can be OK. But most of the time I feel like it's dealing with the same bad code, with just a smattering of nice syntax on top.

I started learning Perl in 2007; after it was no longer popular, but also around the time that the principles/practices that became 'Modern Perl' were becoming popular in the community.

I think there is a difference between the two though. Java was always a language which required a lot of ceremony and typing to get anything done at all. Perl was always focused on expressivity. Modern Perl was a case of learning from past mistakes and consciously avoiding some of the more egregious code the language easily afforded. Modern Java is more a case of Java playing catch-up to the more expressive languages out there.

One is applying constraints on your coding style, the other is trying to lift constraints. Both are trying to reach some middle point.

But! I agree that no company writes purely 'Modern Perl' - you will have to deal with some terrifying code at some point.

So. I agree with the concept of the 'Modern X' fallacy, but I would say that dealing with non-modern code is pretty normal, and people who are OK putting up with the pre-modern code may be some of your best employees. I suffer from rewrite-it-all syndrome myself sometimes, but it's something I try to avoid. Code that frustrates me, isn't necessarily bad.

(If it helps contextually, I'm - at heart - a Clojure programmer.)

See also Liberator for Clojure

Seems to be a typo?

    $ perl6 -e 'say "नि".codes'
    2

Presumably a riff on "Lisp has no syntax"

Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview. It's a bad signal.

Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.

There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.

Not a direct response, but expanding my thoughts slightly:

1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.

2. Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. I'd hate being pigeon-holed just because I happen to know one thing.

3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.

That's only superficially the same. There's questions and there's "let's work through this" questions. The latter are awesome when explicitly stated as such and can be (should be?) as hard as you want to make them - I find I learn from them whatever happens.

Love it! One of my favourite bad interview questions. I got asked this in an interview ~5 years ago. My response was to look shocked... Pause. Then ask: "What do you mean? What detail do you need? DNS? SYN / ACK? HTTP?"

At the point I started talking about syn/acks they just cut me off and moved on to the next question.

Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question.

I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.

Oh wow. The attitude on display is really not good.

That's a great book. I've just started reading I Am A Strange Loop by Hofstadter and it's promising.

Also by Hofstadter: Le Ton beau de Marot was a good read.

GEB is the big one, but if you like his style - probably worth checking out some of the others. Best to get print books for this particular author though.

Re. "Continuously Deliver them to the Docker Registry". Is this focussed on open projects going to the public registry? Or will you provide a private one / integrate with services like quay.io, etc.?

EDIT: Love CircleCI by the way.

Yeah. Bad use of 'patent' maybe. Just interesting that the same arguments are provably going around and around.

Possibly more interesting... start the video from the beginning and they're talking about software patents. The same points were being brought up then as now.

But yes. Good video! Cheers!