Comment by floren | Hacker News Reader

Comment by floren | Hacker News Reader

Parent Full thread

> We've landed on a hybrid approach of reviewing a small homework exercise they were sent prior in an interview and find it a lot more useful to ask them to explain their approach and use it as a jumping off point for other questions. When's the right and wrong place to use arr.reduce()? Why did they need event.preventDefault() in that form submit handler?

I applied this approach recently and it was... depressingly useful. Sent out 3 short tasks which should take an experienced programmer less than 30 minutes to solve in total: one "find, fix, and explain the problem in this code" and two "write the ~50 LOC to implement these exact specifications". These went out only to those whose resumes looked like a potential fit.

Something like half of the responses we got back didn't even compile/run. Mostly due to hallucinated library functions.

One candidate had decent responses, so we went on to the full interview, asking (as you mentioned) if he could explain his approach. He was having some trouble so I just asked him to explain how a sync.WaitGroup (which he'd used in his code) actually functions, and we got treated to an intensely painful few minutes as he desperately tried to spin some BS about how important concurrency is, and how Go's so powerful at concurrency, etc etc etc. but nothing about what a WaitGroup actually does.

I don't really know how to solve this shit going forward.

Just need to keep interviewing more people. Ironically, AI might make (competent) devs more valuable, not less, as lots of them will simply be filtered out because they use AI as a crutch, thus the overall pool of software engineers decreases (and supply is constantly increasing). It's akin to the COBOL situation at banks, they don't have enough competent COBOL devs (as new devs don't learn the language and older ones die off) so they need to pay out the ass to get them to work on their systems.

This is s side comment, but banks don't actually pay out the ass to get people to work on COBOL. That's a myth. They actually just pay people (sometimes programmers, sometimes not) to learn COBOL. (And pay them fairly unconpetetive salaries, because COBOL is not really all that useful.)

They do pay a lot of money to the people who program COBOL and maintain their archaic IBM mainframes. But that's mostly because it's basically a giant proprietary stack (hardware-OS-softare).

> They do pay a lot of money to the people who program COBOL and maintain their archaic IBM mainframes. But that's mostly because it's basically a giant proprietary stack (hardware-OS-softare).

I meant more so this.

I actually think you've found the answer on how to move forward:

    > He was having some trouble so I just asked him to explain how a sync.WaitGroup

If understanding of concurrency is a key selection criteria, introduce some obviously broken code in a code review and see if they can find it and explain why it's broken.

The reason I asked him to explain sync.WaitGroup was because we were trying to discuss the homework problem which was intended to demonstrate knowledge of concurrency. "His" code used WaitGroup correctly throughout! But he wasn't able to explain how the code worked... like at all... so after 5 minutes of getting nowhere I tried to narrow down the problem space a bit and asked about WaitGroup specifically.

When I interview for C# candidates, I have a series of questions that I like to ask 1) what are `Func<T>` and `Action<T>` 2) write a function that takes a `Func<T>` or an `Action<T>` (any function; can be trivial), 3) write a function that returns one of `Func<T>` or `Action<T>`.

The reason is that over various interviews, I've noticed that candidates that can answer and write the code are going to be able to read, understand, and write the level/type of code that I expect.

I bring this up because I think when teams use projects for assessments, there are clearly certain things that you look for or you would see and be able to tell that this candidate knows what they are doing.

Rather than doing all the extra work, to me it seems like you can short circuit that process by just directly focusing on the 4-5 things that -- if you saw them while reviewing the code -- would tick the right boxes. My point here isn't necessarily `WaitGroup`, but that maybe there are some topics that the process could be reduced down to that would yield the same learnings.

It looks like you are doing a pretty good job of filtering with this approach.

Yeah, I'd say it's working, but if I can use an analogy: it's always taken some care and inspection to pick out the un-bruised apples, but now half of the bin is also made up of pretty damn convincing plastic replica apples too, and even though I'm getting good at spotting the plastic ones it's an annoying additional hurdle to the task.

Reply on news.ycombinator.com