Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hiring Without Whiteboards

github.com

Post reply on HN
Print view View original

291–300 of 471 posts

Re: Hiring Without Whiteboards

#291

Post by SuoDuanDao »

b112 wrote: post #278
unishark wrote: post #192

Earlier quoted context omitted.

Or just offer both options. I certainly wouldn't eliminate the opportunity for unemployed people to get a little cash, just because of contract issues that gainfully employed people might have.

Yes, but... Now one worries, is this itself a test? Are they judging my desire to donate.

Well, honestly - if I wanted to donate, I could do so myself after they pay me.

Then I'd be worried... are they watching to see whether I engage in hollow virtue-signalling?

Re: Hiring Without Whiteboards

#292

Post by bob1029 »

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process.

One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal was that I basically had 6 months to prove myself, and if everyone felt like it was working out (myself included) this would be bumped into full-time with benefits. The crazy thing is, I was actually the one who decided I did not want to continue after the 6 months was out while they wanted me to stay very badly. I think this can be a really useful checkpoint tool for both sides.

Anyone can misrepresent themselves in an interview and dupe a room full of people for a day or 2. No one can keep up an act for 3-6 months continuously when working with complex code tasks. You will get found out before the term is up, assuming everyone is using this process as an evaluation tool and following up on it regularly.

Re: Hiring Without Whiteboards

#293

Post by lowwave »

bob1029 wrote: post #292

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

Yeah, there are so many times where I'm asked to solve some sudoku puzzle in an interview. It is really sign of a big interview question.

Re: Hiring Without Whiteboards

#294

Post by drglitch »

bob1029 wrote: post #292

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

Arrangements like this are much harder in US because 1) by default there is no health insurance if you’re a contractor, and obtaining your own is incredibly expensive and 2) there are also pretty complex tax implications of being a contractor; there are many other factors as well.

It also puts a candidate at a disadvantage, because looking for a job is heavily one-sided burden.

On a personal level, as both (occasionally) a candidate and a senior hiring manager, I always wonder about white boarding - i believe it works when the interviewer is looking for your thought process, and not code specifically. For example, something as simple as saying “I don’t expect this code to compile” at beginning of interview immediately puts candidate at ease and let’s you understand their logic and not the ability to recall specific function signatures on the fly.

Re: Hiring Without Whiteboards

#295

Post by bhntr3 »

leonidasv wrote: post #123
mbil wrote: post #45

This is a great list. Thanks for sharing it. I actually had the pleasure of interviewing at one of these companies before. They had a take-home project, which was to choose and implement and couple enhancements to a toy app. In the subsequent conversations, we discussed how I approached the problem, details of my design, technical tradeoffs, etc -- all the sorts of things you would expect a professional sw engineer t…

I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?

> I think the best approach would be giving the candidate a broken app and have they debug it live

I had a company do this and it went really poorly for me. It was a python app and at the time I wasn't very expert in python. They told me to use my laptop and all I had for python was a vim environment. I knew enough python to do white-boarding problems. But debugging a complex app exercises a whole different set of skills I just hadn't developed in the language. I was also learning vim on the side. I looked like an incompetent amateur.

So there's a language and tooling issue. The bigger problem is that debugging an unfamiliar code base under time pressure is almost as niche as doing algorithm problems under time pressure. I've been on enough company wide on calls that I actually think I'm pretty good at debugging unfamiliar code under time pressure. But if I have someone who understands the code looking over my shoulder, they're usually at least trying to help.

It's still time pressure. It's still a somewhat contrived problem and code base. The interviewer is still comfortably omniscient. And it introduces some more complexity due to unfamiliarity of the language, tooling, code base or problem space.

Ultimately, I'm not sure it's any better than white-boarding.

A lot of these problems are solved with a take home question but then all the problems with take homes rise in their place.

Re: Hiring Without Whiteboards

#296

Post by _qulr »

Programmers change jobs very frequently. They come and go. So why are we so obsessed with "getting it right", as if hiring a programmer were like signing a 30 year mortgage?

Hiring is a crapshoot. You'll make bad hires. That's an unavoidable fact of life. Professional sports teams spend millions of dollars on talent evaluation and still get it completely wrong all the time.

No, a bad programming hire is _not_ devastating to your company. You'll live. A bad CEO hire could be devastating, but you can't do a whiteboard or a take-home test for that.

"The perfect hiring process" is classic premature optimization.

Re: Hiring Without Whiteboards

#297

Post by caymanjim »

collyw wrote: post #239
justinlloyd wrote: post #229

Earlier quoted context omitted.

This past week one of the companies on "who's hiring" sent me three challenges that "would only take 2 hours" before I ever got to talk to a human being or even got a human being responding with an email. This was a fully automated system apparently. "Take this programming test, we'll let you know if you're good enough to talk with a human." Whilst the challenges were not particularly complex, you also had to ensure…

We (the whole developer community) really need to stop responding to such companies. I did one recently after the initial HR person chat. I spent a morning on it as they suggested 2 or 3 hours. But then I was rejected for the most pedantic reasons (2 white space PEP violations), not setting up mocks for testing (that would have doubled the scope of the project). Providing an HTML response rather than JSON when the sp…

It sounds like your submission was unrefined, maybe amateur. That's what tests like this are for. Referring to "the HR girls" isn't winning you any points either, and makes me wonder what kind of attitude you displayed to the people involved.

Re: Hiring Without Whiteboards

#298

Post by non-entity »

joaomagalhaes wrote: post #282

We use a simple 2 step process that allows both the company and the candidate to have more certainty about the opportunity. This only applies to technical jobs. 1 - First interview. Does the candidate know about the company? Does he know anything about the business domain? Conversation about problems he has encountered in his past experiences. it works like a knowledge sharing conversation, you really get to know how…

Are all your candidates students or unemployed at the time of interviewing? How do people find that 20h/week?

Re: Hiring Without Whiteboards

#299

Post by biql »

Apocryphon wrote: post #148

This is yet another tech interview discussion, so I'd like to highlight a subthread from the one earlier this month: > I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. >> I'm in a similar position - a tech lead role at a Big N -…

> I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career.

Makes you question if this is the precise point of it.

Re: Hiring Without Whiteboards

#300

Post by non-entity »

malechimp wrote: post #266
Trias11 wrote: post #185

Best way to avoid this BS is to be introduced by an established insider to help bypass this.

There. That's it. All this is a far-from-optimal filter for the total strangers. Get a foot in the door with an established insider and you get right to the last interview(s). No WBs, no take-home projects.

Does this actually work in practice? From my understanding knowing someone might get you past the initial HR / ATS hell to a first round, but you mostly have to follow typical processes after that.
Post reply on HN