Fork me on GitHub
#jobs-discuss
<
2018-10-01
>
pablore14:10:55

Code interviews became so “trainable” there are actually books and coaches on the subject. There are some very bad developers that can ace the interview just because they trained for it

roklenarcic17:10:26

Unfortunately I've seen so many candidates fail very basic tasks. It's really hard to get even moderately competent people.

roklenarcic17:10:29

Usually I am a dissenting voice when I say we should have harder interviews.

☝️ 1
roklenarcic17:10:07

Others are hell bent on reaching the target of "we need 10 more people in 3 months" so they'll take subpar employees. Company suicide if you ask me. But I keep my mouth shut because I'm a freelance hire.

seancorfield17:10:43

A lot of companies have a very broken hiring process... ¯\(ツ)

try-not-to-cry 2
orestis17:10:05

I had a very very nice interviewer some time ago, they asked me some high level questions about how I’d design a small system, then we did a code review of their initial attempt. I didn’t have to write any code but obviously I had to know to read it :)

scriptor17:10:02

I’m often curious to see how a candidate debugs, specifically

scriptor17:10:22

but that’s tricky to do in an interview

scriptor17:10:32

beyond a very small scope

mccraigmccraig18:10:50

@scriptor i take a small but already working codebase, with a few moving parts, do a rundown of it, then work on some modifications to the codebase with the candidate, helping them as necessary... tests code-comprehension, solution synthesis and debugging abilities

scriptor18:10:33

makes sense, I could see that working well

scriptor18:10:57

my biggest issue with coding exercises is that they’re often reliant on some sort of “pivot” halfway through

scriptor18:10:33

the initial solution someone starts writing is almost always not the correct one

scriptor18:10:09

this becomes evident at some point, and usually the candidate tries to figure out a new approach while the interviewer tries to coach them

scriptor18:10:51

the issue is, often this happens well into the time allotted, the candidate becomes nervious/anxious that they’re not able to come up with the final solution in the next 10 or 20 minutes

scriptor18:10:24

in real life, when someone sees that their initial approach doesn’t work, they’ll just take a step back, maybe get some coffee or something, and try again a bit later

👍 2
mccraigmccraig18:10:47

oh, yeah, i generally won't let them go too far down a bad path, but seeing someone realise their current path isn't going to work out and how they react to that is also instructive...

mccraigmccraig18:10:58

and i count on needing 2hrs for a solid pairing test

mccraigmccraig18:10:52

so i won't go there until i'm at least moderately sure about the candidate

alexlynham18:10:29

> in real life, when someone sees that their initial approach doesn’t work, they’ll just take a step back, maybe get some coffee or something, and try again a bit later oh this x 1000

☝️ 1
scriptor18:10:53

yeah, even a 2 hour pair test doesn’t really address this

scriptor19:10:10

because in the end, most of the time when an engineer gets stuck it’s not while someone else is watching them work (unless a company does pair programming extensively, and even there it’s a completely different context)

alexlynham19:10:35

I think I always feel the burn that I'm very very slow on the uptake, but I tend to build quite decent models in my head when I do get there

💯 3
alexlynham19:10:13

so at work I'll quite often listen to a record and scribble on a pad for an hour before I start typing, and then I'll type until I'm done... which I can never get across in a tech test haha

alexlynham19:10:41

it's very strange. I run quite a few interviews now and I really feel odd being over the other side of the desk

mg20:10:40

This is why I prefer hiring approaches that don't involve me watching someone code

donaldball20:10:26

We’ve recently tried an approach where a candidate writes a (very simple) app to satisfy (very simple) requirements and then we pair to modify the code to satisfy different requirements.

mg20:10:48

When I'm in that situation and I'm the one in the hot seat I've found that an attitude of apathy or even mild contempt towards the interviewing company is helpful to stay relaxed :rolling_on_the_floor_laughing:

3Jane21:10:30

hammock development.

💯 1
3Jane21:10:41

(the approach where you think first, and code later.)

3Jane21:10:30

which is also (if you can avoid getting lost in thought/mental bikeshedding) the approach that results in best quality code, imo

👍 1
👌 1
scriptor21:10:32

vaguely related, I’ve found that wfh and doing light chores when I get stuck helps a ton

3Jane21:10:55

I like to walk around at least, but same

scriptor21:10:27

yeah, I usually like doing something that keeps me on my feet at least, so dishes, vacuuming, etc.

3Jane21:10:29

I think it’s because something takes up your foreground thread, so to speak, so you don’t get anxiety, whereas in the background your mind works on the solution anyway

3Jane21:10:41

(anxiety = instant turning off of abstract thought)

scriptor21:10:46

yes, exactly

3Jane21:10:19

but, well. I don’t like coding interviews either since they don’t fit how I think about things (doodling and testing, interspersed with random clicks of insight and braindumping huge chunks of stuff, cleaning it up, repeat.)

👍 1
3Jane21:10:11

but then there’s this doubt that maybe if you don’t want to do them, or don’t look good at them, it’s because in reality you are shit.

💯 1
3Jane21:10:04

The people you can reasonably compare yourself to are a biased sample since they come from companies that have hired you, and therefore you were at an “average” level for those companies at least. So it’s really hard to get an objective image of own skills, and people tend to estimate either too high, or too low.

☝️ 1
seancorfield21:10:36

I'm very strongly against any type of coding interview because none of them match how a developer actually works -- they're "tests" and you can get both false positives and false negatives from them. About the only "coding interview" I can imagine working is a pairing session if that is how you expect the developer to be working once they're employed. And, IMO, you can figure out how well they'd do in a pairing environment by getting them talking about what they like/don't like about pairing (if they've done it before).

seancorfield21:10:08

If someone hasn't done pair programming before, then a session of that as part of an interview isn't going to tell you much anyway -- pair programming isn't just something you can drop someone into with no past experience and expect their very first session to be an accurate measure of future performance 🙂

3Jane21:10:29

People also have different roles within teams, which I think would be interesting to see, but I’ve not seen people be aware of this, or attempt to express it or test it

3Jane21:10:12

For example, I remember from a presentation of … two main devs involved with GraphQL at Facebook, I think, who spoke of one of them being an idea generator, and the other being an editor

3Jane21:10:07

Not only as a pair programming role, but as a team role / work style preference

rmprescott22:10:28

Divergent thinker plus a convergent thinker is often a good combo

seancorfield21:10:22

Interesting... yeah, that makes sense...

3Jane21:10:53

I wonder what a team would look like if created with real understanding of people’s mentality, and care, and having a plan to see them grow internally along with the company

3Jane21:10:11

Do managers even plan for employee growth these days? It’s something you see described in career explanations, but in practice I’ve only seen devs manage their own careers by skipping to the next job

💯 3
alexlynham22:10:09

oh man, this x1000

Conor21:10:33

Modern working does not lend itself to staying with one company for a long time

3Jane21:10:53

It doesn’t, I agree - and I wonder is that cause or effect?

Conor21:10:52

Debatable, but it's probably a cultural shift away from 'jobs for life' towards more globalisation, etc. etc.

3Jane21:10:53

With everything becoming more automated, described more like a process to facilitate anyone fulfilling the role

3Jane21:10:28

it’s easier to make management roles be about scheduling, and development roles about extruding widgets

3Jane21:10:42

but that doesn’t make for people who are satisfied with their job, given how much life satisfaction comes from community (contributing to it, and gaining status in it) and relationships. So people hop to the next job.

seancorfield21:10:32

@conor.p.farrell I think it's reasonable to stay at good companies for quite a while -- but it depends what you mean by "a long time".

Conor21:10:03

Well, I used to work with some people who had been at the same company for 25 or 30 years

seancorfield21:10:08

I was at Macromedia for six years -- and would have stayed longer if Adobe had not acquired them. I've been at World Singles Networks now for eight years full time.

Conor21:10:12

That is what I mean by 'a long time'

seancorfield21:10:04

Ah, yes, that model is unusual (but Adobe had quite a few folks who'd been there 20-25 years -- even when I quit a decade ago... so I expect they've been there 30-35 years now)

seancorfield21:10:49

A lot of companies just don't have that lineage (yet) and the growing pains of startups/SMEs are often enough to make people want to leave.

3Jane21:10:45

and there’s an inherent change of generations

3Jane21:10:16

I remember reading that the initial group of startup employees differs significantly from people who come after, and the same people tend to reoccur in early stages of startups

3Jane21:10:10

this was a diversity-focused study, so the disclosed information was that the group tends to be highly white-male, whereas employees in more established companies tend to be more diverse; and it tied the “generational” difference to whether a person can afford taking a risk such as employment in a very early stage startup

3Jane21:10:17

while I think it’s a significant factor, the other thing is that skills necessary in an employee at different stages are going to differ (mavericks vs team players, for example, or jacks of all trades vs deep specialists) and so people naturally want to hop to environments they feel valuable in

jaihindhreddy21:10:27

Adobe has that, yes. Sean Parent worked there for 15y8m, then a year at google and back to Adobe 8y2m now (thats almost 24 years!)

seancorfield21:10:37

I loved Macromedia. I did not love Adobe (hence, I quit).

seancorfield21:10:25

@lady3janepl Yes, I've seen a lot of analysis around diversity and startups. That whole culture is something I hate here in Silicon Valley and why I pretty much refuse to even consider working in a startup.

jaihindhreddy21:10:50

@seancorfield Do you mean the extremely left leaning culture that views diversity as inherently virtuous and meritocracies as ableist?

seancorfield21:10:39

@jaihindh.reddy I mean the "brogrammer" culture that permeates most Silicon Valley startups -- and VC organizations.

👍 3
seancorfield21:10:33

And I would not consider a view that considers "diversity as inherently virtuous and meritocracies as ableist" to be "extremely left leaning" -- I would consider it based on scientific research that has repeatedly shown that diverse teams outperform homogeneous teams.

👍 7
💯 3
3Jane21:10:37

If such a thing as meritocracy were possible, the percentage of women hired wouldn’t increase after conducting gender blind interviews

3Jane21:10:40

(Which they checked based on musician auditions, and on how people evaluate CVs and even github code based on the author’s perceived gender.)

3Jane21:10:50

Not that I wouldn’t love it if it did exist.

jaihindhreddy21:10:03

I am aware of that. And I agree. Bias creeps in. No matter how careful one is. But does that mean one must make diversity itself a goal, especially above capability?

3Jane21:10:20

Re diverse teams outperforming homogenous teams: I wonder how much of that is related to psychological safety.

3Jane22:10:23

Compare to what happens in Japan, where people hire actors to stand in for parents, boyfriends, etc, in order to avoid the stigma of being different

3Jane22:10:04

If you belong to a group which you’re (at least somewhat) aware values homogeneity, you’re under pressure to fit in. This increases stress, decreases safety (which has been shown to be the primary factor of team performance) and uses up valuable mental/willpower resource that could go elsewhere.

3Jane22:10:52

Contrariwise, in a diverse group a lot more upfront effort must be spent on communication and efforts of understanding each other, and negotiating each other’s needs. But the result is that you feel closer with others since you don’t need to hide, so perhaps you will also feel freer to share feedback, raise problems, and genuinely compliment and support.

1
3Jane22:10:54

A good approximation of diversity might be people working remotely. When only one person works remotely, they’re viewed as requiring special accommodation and a lot of team communication bypasses them. But when a large part of the team is remote, suddenly the remote-inclusive way of communication (for example writing good, thorough tickets) becomes default... and benefits the organisation! I don’t know a dev who doesn’t appreciate a well written ticket instead of having to chase the original author and interrogate them on what they mean by “this dun’t wurk”

jaihindhreddy22:10:02

I do appreciate a well written ticket 😂

3Jane22:10:19

Here’s to we’ll written tickets then! 🍻

🍺 4
3Jane22:10:31

It’s past 11pm though so I’ll bundle myself off to sleep. G’night guys, thanks for the interesting chat, made me think :)

jaihindhreddy22:10:22

Thank you for the detailed thoughts. 03:40 here XD. I better get some shut eye too.