Live data from Hacker News

Hiring Without Whiteboards

github.com

131–140 of 471 posts

Re: Hiring Without Whiteboards

#131
post #120
post #91

Earlier quoted context omitted.

Small price to pay to get more and more absurdly high paying jobs every 3-5 years. Being a productive, valuable member of a software development team is teaching you things that will set you up for success in higher level roles. You won’t be taken for those roles on Leetcode interview performance alone.

>You won’t be taken for those roles on Leetcode interview performance alone. I think the problem is that for some teams the entire process is some combination of leetcode-style "technical" interviews and then some "culture fit" interviews, without any chance to talk about actual dev work.

Large tech companies will have system design and project oriented behavioral interview which will somewhat cover actual dev work. Other than that it pays to build up your network during your career. You can basically bypass interviews at smaller companies with the right referral.

Re: Hiring Without Whiteboards

#132

One of the most telling questions I ask when interviewing is “what was your favorite or most complicated project you’ve worked on and how did you solve the problems you encountered?” I don’t need the interviewee to show me a perfect implementation of a red/black tree. Hell, I don’t remember it. But I want to know what they found challenging and how they went about solving it. Often times they will give me all the tec…

I'm not sure why you're being downvoted for asking about their previous work and watching how they treat people.

Re: Hiring Without Whiteboards

#133
It's definitely important to prove you understand the core concepts required to be a successful developer, such as using efficient & scalable approaches to solve a problem, but writing quality code from scratch simply doesn't mix with high anxiety. And it's not representative of how programming work is done in the real world.

I think a good middle-ground is pair programming where the interviewer writes the code based on the pseudo-code provided by the interviewee. This way, the interviewee displays their thought process and communication skills without being bogged down by programming language nuances.

Re: Hiring Without Whiteboards

#134

The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews. Pair progr…

Depends how the pair programming is done. Last time I did pairing I was told I could use any language I wanted to solve the problem regardless of whether or not the interviewer knew it. You just need an interviewer who is curious and asks questions about the language you're using to make sure they understand your approach.

Re: Hiring Without Whiteboards

#135

The issue with LeetCode style interview is that almost EVERYONE can solve those questions after studying a couple weeks/months. The only thing that LeetCode questions predict is if the candidate has been training for LeetCode questions. The fact that Google, Facebook etc still use it as a gatekeeping mechanism makes me believe they want to find cogs that will specifically spend hours studying for it. Making sure that…

The reason companies like Google can and do it is because their funnel of incoming candidates is large enough that they can decide to choose the 'intersection' of many factors combined. Meaning they will filter down to people who trained for LeetCode questions AND they are also otherwise skilled.

Re: Hiring Without Whiteboards

#136

The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews. Pair progr…

My worst experience so far were pair-programming interviews. This requires so much training on the interviewee side of things that most companies just completely tank this one. They have some fixed expectations in their head and they have not a single clue how to objectively evaluate candidates.

Re: Hiring Without Whiteboards

#137

Earlier quoted context omitted.

What if you get a 1099 from another state? Multiple states? Don't you need to file taxes with those states now? (Genuinely curious, I am not a CPA so I really don't know). What if you don't have any other 1099s (so you have to pay self-employment tax just because of that one interview, at least I had once when my moving expenses were paid with a 1099). Not even getting into possible illegal work for the candidates on…

My city considers 1099s as businesses due to some shady contractors in the past. So my local government would try to collect a chunk of any contractor earnings (with that chunk getting huge if you didn't register with them first).

What city do you live in? I've never heard of 1099 tax collection on a city level before, is that common?

Re: Hiring Without Whiteboards

#138
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?

We do this at String and Key (and I adopted the process from my prior teams at Digitally Imported. I've posted jobs from both here on HN in the past).

Its a one-hour hands-on programing lab via screenshare - a pretty straightforward task of consuming some data from an API, processing it a little, and displaying it. We use Ruby for our work, and ask the same of our candidates in the lab. No handwritten syntax, exotic/tricky algorithms, or gotchas. Just a task to see how a candidate approaches a problem, deals with requirements, and implements them in our language of choice.

Happy to go into more detail if anyone is trying to implement something similar in their own hiring processes.

Re: Hiring Without Whiteboards

#139

Another tech interview thread. For the side that supports these types of interviews, I've never gotten a good answer to a simple question: in the year 2020, why are we expecting people to write compilable code on a whiteboard? It's just stupid at this point. Even a laptop that boots into some micro linux distro and has nothing but nano open would be better. Or just a fresh install windows laptop with nothing but note…

As somebody who has sadly had to make hundreds of candidates write on a whiteboard, here are problems I’ve run into getting the candidate a laptop: * IT just fails: they’re unwilling to supply it, there aren’t enough, the current laptops on hand are junk, or the default password is wrong. These all happen with HR buy-in and funding. * Recruiting just fails: they “have to move the candidate fast because of a competing…

Whiteboarding can fail. The pens might be dry. The room might be double-booked. The interviewer might be late or unavailable. Any interview setup can fail.

Re: Hiring Without Whiteboards

#140
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…

Was this a timed take home project or something with a flexible timeline? That is, was it "You have to respond within 3 hours of receiving this email with your solution" or something more flexible?

I mostly understand why some companies do the x hours routine, and when I've done interviews this way I've historically performed well, but it just felt like it added unnecessary stress. For instance, anyone on the job doesn't have to worry about issues like, "What if I couldn't get the app up and running because I had the wrong version of X installed?" longer than maybe their first day on the job. And if you plan on hiring an engineer for a few years, one day is irrelevant. At best this felt like it favored contractors who were more experienced at jumping into new projects frequently.

Post reply on HN