> I’ve yet to have to write the code to reverse a linked list (copy-paste anyone?) 👀

Many moons ago, I tried to get a friend hired at a company I worked for. I had no control over the interview process, unfortunately, and he was let go from the interview early, at least in part, because he didn't properly answer the following question: "In Java, reverse a string in-place." He was sure it was a trick question because a. it's a silly question and b. java string are immutable anyway.

I've been asked to reverse a string in-place several times, they usually don't care what language though

It was a java job. I'm not sure why they said "in java" or if my friend made that part up to cover his ass.

is there some weird edge case in unicode such that a reversed string might take a different number of bytes than the original?

🤷

The Javadoc for AbstractStringBuilder.reverse() mentions some wacky edge cases

i have no idea if that is possible, i just know that strings and dates get really complicated if you get deep into them

yeah, totally

yeah i was wondering if the "reverse in place" wasn't possible in the general case

Other anti-interview stuff. I remember talking to facebook recruiters a while ago and they sent me a bunch of links about how their process, including this post https://www.facebook.com/notes/facebook-engineering/get-that-job-at-facebook/10150964382448920

Includes this little gem of bullshit: "We will ask you to do a lot of coding during the interview process, because programming ability tends to correlate strongly with how well people perform as employees."

I mean, maybe. I guess I'd have to see a study that proves this. More importantly in my mind is they think "a lot of coding" at a whiteboard is a good way to judge "programming ability".

I assume most interviewers aren't looking to deep dive into Unicode stuff for string reversal, it may as well be an array of bits

oh of course. but that is the point of my question: if a string would have a different number of bytes to represent it when reversed. which would preclude reversing in place.

purely trivia. and if you could pull this kind of stuff out in an interview hopefully they wouldn't care about the answer besides just learning and enjoying

Reminds me of this classic blog post: https://aphyr.com/posts/340-reversing-the-technical-interview

I've gotten a lot of problems like: variations on fibonacci sequence stuff, lots of stuff involving modulo math, reverse linked list, build a stack/queue/list with some "non-standard" performance characteristics

one of my favorite whiteboard questions I've ever been asked was to write a function that returns the angle between the minute and hour hands of a 12-hour wall clock

that is really neat

…which angle? 😄

Oh yeah, that's a fun one.

Everyone forgets that the hour hand is between numbers

yeah that was the second pass, the first pass they just let me do simple/discrete hour angles or whatever

Has very little to do w/ "how strongly you'll perform", but fun

sometimes they give hardcore questions with heaps/dp/etc on whiteboard

dynamic programming questions are very popular

and I believe without serious prepartation it’s impossible to give right answer within 45 mins

I've had mixed experiences with disparity between "solving the problem" and "passing the interview"

I think most reasonable people will appreciate your ability to work through it even if you don't solve it, but not all interviewers are reasonable 🙂

sometimes you just need to get the idea and all process is not important

for example ‘serialize and deserilaize bin tree’

working implementation is very short, and I believe if cacndidate didn’t answer correct all step he/she went on interview doesn’t matter

it’s a sad reality but you have to allocate a ~month of spare evenings to prepare for an interview cycle so you’re not caught off-guard by something you’ve learned and forgotten 5 years ago

Very glad the interview style in the UK is not whiteboard-centric

probably because we have so few CS grads it would be largely redundant

off the top of my head from 20+ engineers we have about 5 CS grads, most of whom graduated in the 70s/80s and are now engineering mgrs. iirc one of the other seniors did CS at uni b/c she was talking to me the other day about having done some scheme at uni

at old place from 7/8 engineers it was maybe 2 who did CS and the CEO I think

I think the Google and Facebook way have infected the way tech companies (at least in the States) interview. Everyone assumes Google and Facebook know what they're doing, so they just do that.

And Facebook hires a lot of very smart and talented people. It works, at some level. But at some level, it doesn't -- I would suggest that a company that has more balance among its ranks--has people who are more than just technically talented--doesn't have the issues w/ corruption, secrecy, and distain for individual privacy that FB has.

well, it's more that most people build web stuff, within frameworks and within company politics... for me, I'd much rather somebody who has practical skills in dealing with servers, who's not worried about picking up some JS, who's conscientious about their code and who can pair... if there's something hard that's a bit more than the day-to-day, I'd hope they would look it up or ask for help

and if you can get a distributed system out the door then you're obviously technically talented, but you might do it in python and not even know what a linked list is... so it's all what our names for things are at the end of the day

So, how do you find that person?

Or, how do you know that a candidate sitting in front of you is or is not that person?

To answer my own question: It's not on a whiteboard, or even on a computer. I think you find out who that person is by talking to them about their experiences and really digging into what they've done. Have they gotten a distributed system out the door? What was the architecture? What went well? What failed?

I (vaguely) remember reading that the best predictor of job performance was agreeableness (of the big five, OCEAN, personality traits)

imagine the riots if you ran psychotests to hire engineers 😄

(makes deep sense to me, as we transition from discovery/pioneer/mad-genius mode to team-of-average/factory-worker mode)

(not that I personally have used it, or would use it; apart from everything else, psychotests are intensely gameable)

I remember my Dad telling me something similar when I was a kid, getting good grades in everything but Home-ec.

"The sign of success, son, is someone who does well at things they don't like"

I could totally get behind that sort of interview 😉

> So, how do you find that person? I wish I knew. Mainly working with people and meetups to find good people, but if you're hiring you need to proactively seek people out, ask friends for recommendations from their friends... > Or, how do you know that a candidate sitting in front of you is or is not that person? Personally I look for attitude when I'm hiring, whether it's juniors or seniors. The tech will change, their approach to problem solving will help them deal with that - and you can work that out by getting them to talk through things, pair on some code etc. Like, even if you are at the keyboard and they're suggesting what to do, you get a feel for how they proceed and talk through ideas. but even then, the system isn't perfect, at all. I'm sure we get false negatives. > To answer my own question: It's not on a whiteboard, or even on a computer. I think you find out who that person is by talking to them about their experiences and really digging into what they've done. Have they gotten a distributed system out the door? What was the architecture? What went well? What failed? So basically this, in other words 🙂

Given that I can talk for hours in depth about all the cool stuff I've done, but can't name a design pattern to save my life

You must be terrible at your job, how did you ever get past the interview? /sarcasm

I used to feel like I had to "tech someone out" when giving an interview. Now I'm completely against it.

I mean, ask a tough technical question and see how much they sweat

I love asking system design questions

Now I'm all about deep diving into experiences

not looking for design patterns, but give an abstract problem, and see how people approach analysing it

Yeah, but I think it's best if those system design questions are related to the person's experience.

/nod

interviewing seems to be one of those things where people are eager to talk about how others are doing it wrong, and how they themselves have figured it out better

I wonder how much of it all (whether it’s deep conversations or whiteboarding) is, in the end, for show to give everyone the impression that they’ve been vetted

Not sure what you're saying w/ your first point. So what?

This is the jobs-discuss channel, after all, and I'm personally interested in hiring good people, but also trying to help correct course for the industry as a whole. I think hiring methodologies are a big contributor to the lack of diversity and equality in the industry.

Re your 2nd point, I've always taken the process seriously, even when I was doing it wrong. I've never known a hiring team not to take it seriously. Never was it to create an "impression" that someone had been vetted.

So, at least in my experience, I can't get behind the 2nd statement.

a few of my favorite developers I've worked with transitioned into a dev role from some non-dev role at the same company, and would've never gotten the job if they had to tech interview for it

it probably helped that their first programming experience was Clojure 🙂

The pinned item in this channel is a PDF of a mind map I use to guide an interview process. I don't do tech tests/whiteboarding -- it just doesn't represent how an engineer actually gets their job done. I use the mind map as a guide to get the candidate talking about things (I ask what I hope are "leading questions" from the topics in the map). I want to hear how they feel about certain types of projects, processes, technologies... what excites them, what puts them off, what they want to do/learn/contribute, what they'd rather avoid. Most of the right side of the map is "people" stuff, most of the left side is "process/tech". I typically start near the top right and go down that side, then switch to the left and go down that side.

Interesting, some of the qs on there are like ours, but there's some ace ones we don't have

the language stuff is ace, and the conflict resolution

I thought this was a really great talk (from perspective of underrepresented person in the industry) https://www.youtube.com/watch?v=iRNnK5Yx4QU

He kind of hits on some points in that mind map

asking people to analyse a failure I think is a really interesting thing to do that we don't - but that I would like to

@seancorfield That looks great. Imma save a copy. But I feel like it's missing something about problem solving or engineering work. Like, I would dig into something on a candidate's resume in technical detail.

Also, it seems too big for a single-person interview. If a candidate meets w/ 3 or 4 people, I would take that map and break it up or whatever so that each of the interviews is complimentary, if that makes sense.

@brianballantine Yeah, I'll usually drill into something about a bad or good project (that crops up in discussion on right side) and get the candidate to talk in more detail about some good or bad problem in that context. But I usually let the candidate go in that direction first. If they haven't mentioned anything related to problem solving/engineering by the time I'm at the bottom of the right hand side, I'll pull something off their resume and dig in.

You can get a really good sense of their attitude to problems (and engineering in general) just by letting them talk about one of their favorite projects 🙂

word

As for size, I can generally get through it solo in an hour or less. Some candidates have talked themselves out of the running within 15-20 minutes, at which point I'll just wind up the interview.

> Some candidates have talked themselves out of the running within 15-20 minutes if you don't mind me asking, what are some common red flags you see that would cause you to wind up after that length of time?

@alex.lynham If they are unable to describe the specifics of something I believe they should know well, based on their resume and what they've already disclosed in the interview is the main one. And, by that, I don't mean "not permitted to", I mean "incapable of". Also, if they show that they are disinterested in anything that is key to the role I'm hiring for -- I've had candidates happily admit to not ever wanting to do maintenance work(!), hating writing tests(!), being dead set against code reviews(!)...

(I also had one candidate who seemed to have only ever had "terrible managers" that "interfered" with their work... and the likelihood that every single manager they have ever had actually being "terrible" is... vanishingly small... so that was a big red flag too -- in general, speaking ill of past colleagues as a whole is a warning sign for me)

I think it's possible to diplomatically and positively hint at problems you've had at prev. jobs, but yeah most interviewers really don't want to hear that. That's a well-known footgun for interviewees. I personally don't mind hearing about things they didn't like at previous jobs, as long as they come across as valid criticisms and not "the world can't accommodate my genius"

yeah, and like Sean mentioned, it’s more of a red flag when they make it sound like every manager was terrible

> in general, speaking ill of past colleagues as a whole is a warning sign for me Exactly. Your time with a company will always come to an end eventually. I like to stay in touch with past employers and colleagues and... well I don't think it's a requirement that you go to that length for me to hire you, it's still odd if you trash them.

That said, I can think of a case where a candidate described being missold a job in quite a personal way, and I felt they had been hard done by so didn't think ill of them

surprisingly, I've had an interviewer speak badly of past candidates and *mutual acquaintances* during an on-site interview

Huh

I wondered later if he was baiting me into doing the same. I didn’t get an offer :man-shrugging:

I've made it a general rule not to discuss specific people I've worked with in the context of an interview, no matter the side of it I'm on.

when asked I've cited a professional code (the same I did for salary history before it became illegal to talk about that in my state)

I've only ever broken this with "I really enjoyed working with them and would love the opportunity to do so again"