This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (2)
- # announcements (3)
- # beginners (95)
- # bitcoin (1)
- # cider (18)
- # cljdoc (9)
- # cljs-dev (8)
- # clojure (55)
- # clojure-austin (1)
- # clojure-berlin (4)
- # clojure-italy (21)
- # clojure-nl (1)
- # clojure-russia (2)
- # clojure-spec (47)
- # clojure-uk (31)
- # clojurescript (19)
- # component (8)
- # cursive (5)
- # data-science (2)
- # datomic (33)
- # emacs (7)
- # events (1)
- # figwheel (8)
- # fulcro (16)
- # graphql (27)
- # hyperfiddle (5)
- # jobs (1)
- # jobs-discuss (85)
- # keechma (7)
- # luminus (11)
- # mount (6)
- # off-topic (23)
- # onyx (1)
- # re-frame (4)
- # shadow-cljs (29)
- # specter (19)
- # tools-deps (11)
- # uncomplicate (3)
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
Unfortunately I've seen so many candidates fail very basic tasks. It's really hard to get even moderately competent people.
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.
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 :)
@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
my biggest issue with coding exercises is that they’re often reliant on some sort of “pivot” halfway through
this becomes evident at some point, and usually the candidate tries to figure out a new approach while the interviewer tries to coach them
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
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, 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...
> 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
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)
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
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
it's very strange. I run quite a few interviews now and I really feel odd being over the other side of the desk
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.
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:
which is also (if you can avoid getting lost in thought/mental bikeshedding) the approach that results in best quality code, imo
vaguely related, I’ve found that wfh and doing light chores when I get stuck helps a ton
yeah, I usually like doing something that keeps me on my feet at least, so dishes, vacuuming, etc.
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
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.)
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.
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.
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).
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 🙂
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
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
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
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
Debatable, but it's probably a cultural shift away from 'jobs for life' towards more globalisation, etc. etc.
With everything becoming more automated, described more like a process to facilitate anyone fulfilling the role
it’s easier to make management roles be about scheduling, and development roles about extruding widgets
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.
@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".
Well, I used to work with some people who had been at the same company for 25 or 30 years
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.
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)
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.
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
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
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
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!)
@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.
@seancorfield Do you mean the extremely left leaning culture that views diversity as inherently virtuous and meritocracies as ableist?
@jaihindh.reddy I mean the "brogrammer" culture that permeates most Silicon Valley startups -- and VC organizations.
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.
If such a thing as meritocracy were possible, the percentage of women hired wouldn’t increase after conducting gender blind interviews
(Which they checked based on musician auditions, and on how people evaluate CVs and even github code based on the author’s perceived gender.)
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?
Re diverse teams outperforming homogenous teams: I wonder how much of that is related to psychological safety.
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
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.
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.
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”
It’s past 11pm though so I’ll bundle myself off to sleep. G’night guys, thanks for the interesting chat, made me think :)