Fork me on GitHub
#off-topic
<
2019-10-18
>
seancorfield00:10:11

@idiomancy If you scroll down on that page it explains how to solve that particular puzzle

seancorfield00:10:51

(and how to solve the next puzzle where you must pick just two pieces to form the desired result)

seancorfield00:10:37

My personal opinion is that these sorts of tests are stupid as any sort of screening for a job and I'd probably name and shame the company trying to do that 🙂

idiomancy00:10:38

I couldnt possibly agree more. This "aptitude" test is a really remarkable source of both false negatives and false positives

idiomancy00:10:38

I couldnt possibly agree more. This "aptitude" test is a really remarkable source of both false negatives and false positives

gibb06:10:37

I’m into those kinds of puzzles / pattern matching exercises but how are they helpful when recruiting?

gibb06:10:54

Last time I did an interview I did some research on how - and came to the conclusion that I had no idea how to do it and my internet research was not helping. Big companies that have a very large number of applicants seem to have something to gain from eliminating “bad” candidates, i.e if they make the interview process so hard that it filters out all weaker candidates it’s a net win.

gibb06:10:16

That does not seem to apply at all to most of the normal distribution of companies tho.

seancorfield06:10:37

But filtering out people who can't do stupid puzzles has no bearing on whether they could be great software engineers 😞

gibb06:10:13

Sure - but if you apply enough stupid filters on a large enough pool something is going to happen eventually.

seancorfield06:10:19

I refused to interview at Google because of their stupid interview process and the silly "puzzle" questions they asked (they've gotten better recently)

seancorfield06:10:58

Many big tech firms have this same very broken approach to interviewing. They are slowly learning that it is a stupid approach.

gibb06:10:26

I don’t necessarily think that it’s stupid from Google’s perspective.

seancorfield06:10:49

They've admitted it was stupid.

gibb06:10:10

It’s mostly the smaller companies without thousands of applicants per positions that are going to suffer from emulating googles process.

seancorfield06:10:28

They've done a huge amount of analysis and they now accept their previous interview filter technique was broken.

gibb06:10:45

Interesting! Did they come up with some better solution now?

seancorfield06:10:46

There are much better processes.

seancorfield06:10:36

I've used a mind map to guide interview discussions for years (decades?) and I've never had to fire anyone for incompetence.

seancorfield06:10:54

I don't do "technical quizzes" at all. They're useless.

gibb06:10:32

How do you use a mind map?

seancorfield06:10:04

Hmm, I had it pinned in a bunch of channels... let me dig it up and re-post it...

seancorfield06:10:00

Interview topic mindmap

cider 16
seancorfield06:10:29

I start in the top-right and I just use it as a guide to get candidates talking about projects and experience/techniques. I want to hear them explain what they like, what they don't like, what excites them, what bores them.

gibb06:10:14

I have something like a mind map over the problem space that we are in, and then we probe a few trunks until the expertise level of the candidate tapers out (or exceeds mine). And then usually a design exercise of some kind on a whiteboard

gibb06:10:42

That looks neat!

seancorfield06:10:53

Whiteboard stuff sucks. Sorry. It's mostly a terrible way to understand whether a candidate can actually do the work/fit in.

gibb06:10:53

That seems a bit harsh to whiteboards. Isn’t how you use them the important part?

seancorfield06:10:57

Unless your team works on a whiteboard all time of course 🙂

gibb06:10:30

Well I guess we do, but in this case it’s more to have something to hang a discussion about system design on

seancorfield06:10:51

Right, but is that how you work or is that just how you interview?

seancorfield06:10:13

If it's the latter, then your interview is worthless -- because it doesn't reflect how you work.

gibb06:10:21

Good point - yeah absolutely how we work. But I agree it’s not the major part of the work

seancorfield06:10:49

That's cool. If you typically use whiteboards a lot for work, then having them in the interview process is fine.

gibb06:10:08

There’s absolutely no writing of code on whiteboards tho

gibb06:10:21

But sketching simple models of systems for sure

gibb06:10:51

In this case we had a real service that needed building and two junior guys interviewing, and they each did a quick design discussion / exercise of the service during the interview. In the end we saw that they had great understanding of most of the work that needed to be done except the data modeling stuff and database work. So we hired them and assigned a lead to their team with some instructions based on that and it worked out great

Nico Van Belle06:10:02

I ask candidates to pre-configure an empty project for unit testing on their own laptop and let them solve an existing coding kata

Nico Van Belle06:10:26

They need to solve it in a TDD fashion then I ask them to think out loud

Nico Van Belle06:10:57

and ask them about possible patterns, refactorings, pros, cons + I check how they think and how well they know the toolings / languages

Nico Van Belle06:10:12

the coding katas themselves are very very easy

Nico Van Belle06:10:32

it's just the way they solve it and what goes on into their heads

gibb06:10:39

Interesting approach

Nico Van Belle06:10:00

I've had one senior developer so far to cancel the interview when he heard he had to write code

Nico Van Belle06:10:12

I bet he could have answered all kinds of theoretical questions

seancorfield06:10:54

@nico.vanbelle What happens for developers who do not own laptops?

Nico Van Belle06:10:39

They reply to me they don't have one, I ask which IDE they prefer and I let them use one of ours

seancorfield06:10:59

IDE? Or plain text editor?

Nico Van Belle06:10:36

IDE with tooling they prefer. The only prerequisite is they need to be able to write unit tests. The reason why I ask the candidates to set up an environment with the tools of their likings is because tooling also counts towards productivity

seancorfield06:10:52

I don't work on a laptop generally. And I don't do TDD -- I believe RDD is better. How does that fit?

Nico Van Belle06:10:46

I've had a couple of developers using tools I've never heard of. They really knew their stuff and were able to assert tests in a much better way than I've mostly encountered

seancorfield06:10:20

(I think most companies have a fundamentally broken hiring process so my immediate reaction to most people is to challenge how they interview people)

4
gibb06:10:27

Thanks for the discussion @seancorfield & @nico.vanbelle

gibb06:10:51

I have no doubts that our process is broken - I just dont know how to fix it 🙂

gibb06:10:18

At the very least it’s less than ideal..

seancorfield06:10:22

The last time I ever asked a candidate to do anything "live" in any interview was about 30 years ago.

Nico Van Belle06:10:03

I ask them to write it using test-driven development because then you need to be able to reason about the smallest testable unit they can start developing. It's quite difficult for some (myself included at times) and it makes these exercises more interesting

Nico Van Belle06:10:42

Also, thinking about the design of the software upfront is difficult for most junior developers

seancorfield06:10:02

I think that's old-fashioned and I would refuse (TDD). I don't think it's a good way to interview people.

Nico Van Belle06:10:46

I respect that. I've found it to be refreshing as it leads to many interesting conversations

Nico Van Belle06:10:25

Before that my colleague asked the theoretical stuff. SQL query questions, SOLID principles, simple design, patterns, ... but most candidates can question those

seancorfield06:10:34

And that's an even worse interview process. I'd support live TDD over that any day! 🙂

seancorfield06:10:23

Like I said, most companies have terrible interview processes that don't determine whether candidates will fit in and be good developers.

👍 12
seancorfield06:10:42

Our whole industry is broken in that area 😞

Nico Van Belle06:10:26

I only interview candidates who are hired on consulting jobs as I'm a consultant myself. So it's kind of picking my own direct colleagues. Whether they are hired on the job or not, the only difference for them is that they no longer sit and wait for the next project

Mattias06:10:21

@seancorfield You’ve made me want to look up RDD, but there are lots of options. Which one do you like?

seancorfield06:10:51

REPL-Driven Development 🙂

seancorfield06:10:15

It was interesting hearing Stu Halloway talk about "Rich Comment Forms" since that was already the way I was developing and I've focused very heavily on immediate feedback and live evaluation from the source file I'm working on over the last few years.

seancorfield06:10:29

I was fairly TDD-sympathetic before I switched to Clojure (nearly nine years ago).

seancorfield06:10:17

If you're hiring for languages that don't have that tight feedback loop then TDD may well make sense. I'm sort of assuming we're talking about hiring for Clojure jobs tho'.

seancorfield07:10:16

But I'll also reiterate my point about talking with developers in interviews rather than making them code stuff live via any means -- seriously, it's been nearly 30 years since I last expected a candidate to work under those constraints.

👍 8
seancorfield07:10:28

Communication and collaboration are what development is about. You can always train people on your processes and technology. Well, you should be able to train them on processes, which is what a lot of that mind map and discussion is intended to uncover...!

👍 4
Nico Van Belle07:10:12

TDD and tight feedback loops have no connection in my opinion. It's about thinking about design upfront and enforcing a good design that is easy to test. I've had candidates do TDD with javascript, quokka.js and wallaby.js which directly evaluates the code + run all unit tests while changing only 1 character

seancorfield07:10:39

TDD doesn't really help with system design.

seancorfield07:10:57

It helps makes things testable which is not the same thing.

seancorfield07:10:11

It's a local maxima.

💯 4
seancorfield07:10:03

People can, and do, produce awful software via TDD... it's just very easy to test. It's still awful, tho'...

☝️ 8
Nico Van Belle07:10:20

But it has its advantages

seancorfield07:10:56

Its advantages... better than nothing 🙂

seancorfield07:10:35

"Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming." -- DHH 🙂

seancorfield07:10:28

(I don't agree with him on much but...)

Nico Van Belle07:10:05

I'm no TDD advocate. I use it only when I feels like it's helping me accomplish a goal

Nico Van Belle07:10:29

when fixing a bug I'll try to use TDD 100% of the time

Nico Van Belle07:10:56

when I need to break up a complex story, I'll use TDD to get be starting

Nico Van Belle07:10:10

and it helps creating good conversations when doing technical interviews 🙂

🙂 4
Mattias09:10:10

I have a vague feeling that TDD is used (to good effect at times) as a battering RAM in enterprise Java et al settings where breaking stuff up into pieces is a revolution and an eye-opener. For people who are more aligned with common FP idioms it’s much less interesting. Maybe.

Mattias09:10:26

And RDD should have been obvious. Thanks 😅

sysarcher09:10:36

We use TDD because before software ships, Legal requires we have 80% test coverage :thinking_face:

4
Conor09:10:40

Protip: You can just write tests that have assertTrue(true) in them like we caught an offshore team doing

Alexander Heldt09:10:43

LEGAL requires that? interesting

Alexander Heldt09:10:16

maybe you can set some arbitrary requirement for legal, for fun

😂 8
sysarcher09:10:18

🙂 the automotive industry has their kukoos

mloughlin12:10:53

my experience with TDD is that it encourages step-by-step discovery of the details of a problem space, which is fine if you already understand it in the large but it tends not to work if you don't [in that it encourages a settling on a specific implementation early on]

👍 12
jeroenvandijk13:10:22

Why does it have to be black and white? I mix REPL driven development with TDD and whatever feels great in that moment. After a reported bug, I would probably confirm this via the REPL, try to think of a solution, write a failing test, then implement it

👍 12
sysarcher13:10:51

are you still talking in Clojure-land? Because the original poster was specific about it

jeroenvandijk13:10:28

I actually don't know exactly where the discussion started, but I read the comments as either TDD or RDD

jeroenvandijk13:10:57

I believe TDD flow could be improved a lot (especially within Clojure, better than in any other language), but the concepts behind TDD have always been relevant I think, also for Clojure

sysarcher14:10:44

sure... I'm very new to clojure so I'm just observing 👀

👍 4
agigao13:10:13

Dang, apply onto pandas DataFrame using lambda expression is 16 times slower than a regular double loop :face_with_rolling_eyes:

mloughlin13:10:43

I always think of the example given by Peter Seibel of Norvig/Jeffries and their sudoku solvers. https://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/

👍 4
jeroenvandijk13:10:54

I can only say that I believe in the concepts of TDD, not in the current practical implementation. To give a real live example; if I create a new feature in a project, the TDD way, if i'm unlucky an insignificant change will trigger my whole test suite. This doesn't mean that the idea of TDD is wrong, it means my tool that scans for changes is wrong. It does have the practical implication I cannot use TDD all the time

jeroenvandijk13:10:37

So I don't believe what is said in the article by Uncle Bob, unless there exists very advanced tooling I have no idea of yet. But I also don't agree with "TDD deniers". I hope tooling will improve and we get closer to what TDD promises to be

souenzzo14:10:34

In my TDD workflow, for each feature that I will write, I start with a test I write this test, develop the functionality running just this tests. Once complete, I push it then the CI will run all tests. Any regression will blow up and I will solve it.

souenzzo14:10:36

My tests are usually things like when a user confirms a buy, it receive a email A test like this run all my system, but runs in 100ms and has no side-effect.

mloughlin14:10:43

isn't sending an email a side effect?

souenzzo15:10:06

It can be The "email-driver" should be a parameter from my system (not only my funcion) And should be easy to swap/mock in my test If it's not simple to mock/test, I review all my code to make it easy.

jeroenvandijk08:10:59

I used very well tested components (as in stuart sierra's component) with different implementations (e.g. for Redis I have an in-memory version). When the mock implementation works I assume it works with the real implementation as well. I can make this assumption because the fake components are tested on compatibility. If I come accross an exception in this assumption I try to fix it. To get this working you need to go all the way (fake time, control randomness etc)

jeroenvandijk13:10:40

@michael.e.loughlin ok read it slightly better, I think the point of Peter Norvig is good and nuanced

mloughlin13:10:04

my interpretation is he's advocating for more hammock time

simonkatz14:10:06

I see REPL-based development as orthogonal to TDD vs real-code-then-tests (or top-down vs bottom-up, etc). REPL-based development allows you do do any of those other things, but with faster feedback. (Note: I said “REPL-based” — not sure what “REPL-driven” means.)

seancorfield16:10:08

Glad that triggered quite a bit of discussion 🙂

seancorfield16:10:46

Despite my apparent stark black and white position, I agree that TDD is better than write-code-then-write-tests.

seancorfield16:10:46

And, yes, if you have some clear requirement (or bug!) for which it is easy and obvious to write a failing test that will only pass when the requirement is implemented (or bug is fixed).

seancorfield16:10:38

But, more often, you need to do some investigation around the requirement/bug first -- in Clojure we generally do that in the REPL.

seancorfield17:10:34

So I'm advocating a REPL-first workflow -- REPL-Driven Development in the exact same way that TDD is development driven by tests. But don't type into the REPL, type into a source file, maybe in a (comment ,,,) form, and keep that exploration around. Some of it should become your production source code, some of it might become tests (to make sure you don't break this feature in the future).

seancorfield17:10:53

At work we have about 90K lines of Clojure overall and nearly 20K of that is test code at various levels from very fine-grained "unit" tests up to full, end-to-end UAT style. And, yes, some of those tests were written for specific TDD pieces of work (mainly around our API: we write down a detailed description of the API, then write a tests for all the documented failure modes and a few tests for the success mode, and then we implement the code). But mostly our tests are either regression (after the fact) or evolve out of REPL exploration.