The three skills with a lot less overlap than you’d expect:

1. Ability to code.
2. Ability to perform well in a coding interview.
3. Ability to validate code.

@norootcause

I hate live-coding interviews. If someone is watching me, I forget how to even type. Obviously my 30+ years of writing code, all my open source stuff, my extensive resume, all those papers and conference presentations were just me faking it.

@rk @norootcause ever since Google made me write code (not pseudo code, not math) on a fucking white board during an staff engineer interview, I have seen them as an indication of pompous douchebags hazing people.

Nobody writes code like that.

I honestly thought people were exaggerating how stupid they were.

@petrillic @rk @norootcause The only interview I almost just walked out on was some dumb "write this in C++ on the whiteboard" which is already monumentally stupid -- but then one of the interviewers was like "you missed some braces here, and here".

That was the last part I really heard ;) since I at least _mentally_ left the interview at that point

@meejah @petrillic @norootcause

Years ago I interviewed at a place.

The interview was ostensibly for C programming on QNX or something, I don’t remember. But when I got there they were like “oh that position has been filled, so we’re going to interview you for…” some Windows-position or something. Something I had no experience with.

At one point the interviewer was like “I don’t feel like you really have a lot of experience with this” and I was like “I don’t!” I then excused myself and left.

@rk @meejah @petrillic @norootcause I had this happen at a corporate library. There was an IT support position, and a secretarial / administration position. They started with interviewing me for the admin job. The interviewer seemed really frustrated that I had no clerical experience. I asked if there was going to be a technical portion to the interview, and they asked me if I was familiar with their (admittedly very modern) copier. Just when I thought I was wasting my time, she looked at my academic transcript - and apologized for wasting my time interviewing me for the wrong position…

We had a laugh, and the rest of the interview was smooth, and I got the job.

@JustinDerrick @rk @meejah @norootcause Weirdly something similar... in the very early 1990s, I worked on a research project (post doc) at UT-Austin as the developer. I had to go through the hiring process for that, and it included a ... typing test. I scored something like 130wpm, and they tried to convince me I should be an admin rather than a programmer.
@petrillic @rk @meejah @norootcause So weird that they wouldn’t get you into technical writing to produce documentation - that’s a far more valuable skill than being a good typist. :)
@JustinDerrick @rk @meejah @norootcause instead I got to write well-log analysis code on NeXT that used a Connection Machine to do the heavy lifting (partnership with Schlumberger). It was a learning experience! I was quite in over my head, if I'm honest.

@petrillic @JustinDerrick @meejah @norootcause

NeXT and a Connection Machine, my god.

@rk @JustinDerrick @meejah @norootcause the blackness was overwhelming! I mostly got hired because I knew Lisp and we used *Lisp for the heavy lifting... yeah.

It was a wild time in 1992 :)

@meejah @rk @norootcause I literally looked at them and asked "Can you all not afford computers here?"

@meejah @rk @norootcause and given I was interviewing for a staff security engineer, asking me to write A* on the board for graph search seemed... like have you all not heard of libraries before? Maybe write it once and optimize the hell out of it, rather than having every engineer write their own.

"I didn't know I was interviewing for a foundation algorithm libraries job"

@meejah @rk @norootcause "Your whiteboard seems to be missing a code profiler."
@petrillic @meejah @rk @norootcause I got rejected because I use gdb.
@petrillic @rk @norootcause draw out "meta-x lsp-mode" in cursive...

@petrillic @meejah @rk @norootcause I joked about it but these days I probably would bring my copy of Sedgewick's "Algorithms" along in my shoulder bag and toss it on the table if faced with that BS again. "Learn to read."

At this point I will never interview with another pure software organization due to their hazing practices and other social and organizational pathologies. I have enough engineering safety analysis background that I can work with subject matter experts and still write code. Regulated spaces like nuclear have not yet succumbed to the onslaught of AI and that's unlikely to change anytime soon.

@meejah @petrillic @rk @norootcause
Yes, there are bad interviewers at Google. And at other companies. (I turned down a Microsoft job offer because I thought the interviews were too easy - and I had another job offer that ended up being a better financial choice as well)

(I did design interviews at Google until I got tired of a thankless job ... I didn't care what answers the candidate gave; I wanted to see their thought process)

@petrillic @rk @norootcause I walked on a similar interview. I really did look at them like the rca dog, and then said, I’m sorry boys, I didn’t realize this was a hazing interview. Thank you for the coffee, I can see myself out.”

Fuck all of that. I’d rather sling drinks in a gentleman’s club than be asked to perform on command. I’m not a show pony, I’m an experienced professional with a resume that existed before those tech bros were born, and I will be goddamned if I’m gonna be bullied by people that don’t wear long pants.

@petrillic @rk @norootcause I'm a UX designer and feel the same about "whiteboard design challenges." They are utter bullshit and I do not subject candidates to them. If I can't look at your portfolio and figure out what you can do then I probably shouldn't be doing this job.
@petrillic @rk @norootcause But that's why everyone does it now. Same reason we're all expected to concentrate in huge, noisy rooms.

@petrillic @rk @norootcause

I had one of those at Google and it wasn’t that bad, because the interviewer understood it was unrealistic. It was ‘write some C code, this isn’t an IDE so there will obviously be mistakes’, they ignored obvious ones like missing semicolons (I don’t type semicolons in C, my fingers hit the key when my brain sends and end-of-statement signal to my spine) and discussed the others. The interviewer was using it mostly as a ‘how do you respond to code review’ thing, which is a very useful thing to know (and why I like to look at PRs that job applicants have opened on projects other people run). If you get defensive or try to justify why your mistakes are actually correct, you’re probably going to be a pain to work with. Writing on a whiteboard pretty much guarantees that there will be bugs that a reviewer can point at.

@david_chisnall @petrillic @rk @norootcause I had a similar interview process at Microsoft over 20 years ago. Personally, I found it kind of fun. They only expected pseudocode on the board, and it was honestly a conversation to see what I knew about algorithms and whether I could think on my feet. This was especially important because I was coming from the physical sciences, and my comp sci minor was 10 years in the rear view mirror. It was a different time. One could still land a coding job with a graduate degree in almost anything.
@rk @norootcause
But do you remember how to vibe? I'm told that's all that matters any more!
@shriramk @rk Is vibe-verification a thing yet?
@norootcause @shriramk @rk isn't that what a prototype or say, a log visualizer or other tooling is for? I vibe so much "peripheral" things that are there mostly to help me play and understand the main problem, at which point I can hopefully do a fairly reliable review. Example from today, learning cozodb/cozoscript. full vibe, incredibly useful.
@rk @norootcause I feel the same way. If the paper I wrote which you claim was the reason you contacted me isn't sufficient, why did you bother contacting me at the conference in the first place?
@rk @norootcause
I once was interviewed and asked to write a C function on a provided blank sheet of paper. The interviewer left the room for fifteen minutes. It took me less than five. He came back, said the code looked good, and was astounded: "You even wrote comments!" I had included comments on input parameter requirements and boundary conditions.
The other interviews at that company went well, but the company made me a ridiculously low-ball offer.

@rk
With all due respect, I've had to work with code written by well-respected researchers and afterwards I concluded that it would have been easier to have rewritten from scratch - in one case, someone, who I think was "reviewer 2" on one of my papers, had written code so buggy as to be useless for anything except the specific examples in the research paper.
(To be fair, I've also had similarly painful experiences with code written by programmers with a good reputation)

Having said that, the whiteboard coding exercise isn't a good way to evaluate programming ability.

@norootcause

@rk

I once pushed back on this at a big tech firm.

Interview bro: hey false negatives are OK.

Me: but didn’t this process give us the zune, google wave, and the metaverse? I can guarantee reliable shipped product (see resume) you will immolate billions on obviously bad ideas. My downside risk is comparatively 0.

@norootcause - Ability to ship code to production in a bureaucracy.
- Ability to ship code to production in a 3-person shop with no help from no one.
@mistersql @norootcause wait, are the other two people computer-literate? Once it was owners and a coder (trust me, run the other direction if approached thusly). Once it was a sales / clerical and two nerds; that was a pretty kickass gig

@norootcause

3a: actual willingness/ inclination to validate code or check-ins.

@norootcause They never seem to test me on the classic "can you duct tape something together that will come in under budget and somehow wheeze along without maintenance for 20 years?" question in those interviews.

@norootcause Imagine it this way, they're saying: "Hello, please fit yourself into this spreadsheet for me."

If you can't do that (most people can't, we're not numbers), then they don't know what to do with you. Their inexperience and inability to deviate from a formal standard developed by an idiot forms the set of admissible results in which you may get hired by.

@[email protected] @[email protected]

1. Ability to write books well.
2. Ability to retort and debate around ideas from books.
3. Ability to read books with good comprehension.

Just like with code, they do correlate, but people think that if they correlate they must be one thing; "literacy level" they call it. But I guess we had enough time (thousands of years) with writing to start developing separate words for those separate concepts; there's some understanding that they are not the same thing, but the programming crafts are still yet too young. We would probably skip a whole world of pain if we took more lessons from the actual disciplines of writing & engineering as we develop our collective understanding of software, but alas, an almost opposite problem occurs; software has some differences from writing and engineering, so we'll throw all of that accumulated human knowledge away, and go through measureless pains developing it from scratch.

Spoiler: A coding interview isn't: can you write perfect code.
Well, maybe sometimes it is.
But IME it is at least as much about things like: how do you respond to being corrected when you (inevitably) make a mistake.
@norootcause

@BenAveling @norootcause the sane version of all this I've been through was being handed a broken program in a language I didn't know, and told to figure it out.

"Well, the error looks like an HTTP 500, so it reached the server, and I think the request is invalid here, but there should also be a better error from the API, I think the MIME type is wrong but I'd need the API docs"

apparently I nailed that part despite barely knowing js, and its ACTUALLY what responding to incidents is like.

Similar to my experience - the boss wasn't looking for 'did I know everything', but 'how did I react when I didn't know'.

@unlofl @norootcause

@norootcause Three more:

1. Ability to do arithmetic.
2. Ability to do algebra.
3. Ability to do analysis.

@norootcause I’m so glad I’ve never had to do a ”coding interview”, from either side.

@norootcause yeah, i wish more people really understood that programming *is* communication.

1- knows how to write.
2- knows how to speak in public.
3- knows how to do editing.

3 different skills that we --way more easily-- accept are work on different domains.

@norootcause
As programmers, we should refuse any interview that includes one.

I'm a good programmer, 20+ years doing this work. But I blew it last week because I couldn't convert comprehension of the requirements into code. My brain just locked up.

@norootcause

A code review is primarily providing feedback to a person, so naturally that requires people skills for it to be effective in the long term. So.. it's not at all surprising imho.