Most active commenters
  • alkonaut(7)
  • John_Cena(5)
  • bhhaskin(3)

←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 16 comments | 15 Nov 24 15:32 UTC | HN request time: 0.208s | source | bottom
Show context
fishtoaster ◴[15 Nov 24 18:07 UTC] No.42149357[source]▶
I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice:

1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work.

2. Do an onsite pairing exercise in 2 hours. This would be a version of #1, but more of "see how far we get in 2 hours."

3. Submit a code sample of pre-existing work.

Based on the ire I've seen takehome tests get, I figured we'd get a good spread between all three, but amazingly, ~90-95% of candidates chose the takehome test. That matches my preference as a candidate as well.

I don't know if this generalizes beyond this company/role, but it was an interesting datapoint - I was very surprised to find that most people preferred it!

replies(7): >>42149441 #>>42149536 #>>42149571 #>>42149636 #>>42150136 #>>42150254 #>>42151318 #
bhhaskin ◴[15 Nov 24 18:17 UTC] No.42149441[source]▶
Why would you even do any of that for a senior role? I wouldn't waste my time with it, and it shows you don't know how to interview/evaluate for a senior position.
replies(6): >>42149512 #>>42149515 #>>42149540 #>>42149560 #>>42150471 #>>42151698 #
alkonaut ◴[15 Nov 24 18:32 UTC] No.42149560[source]▶
Because for a senior role you need to hire a person with senior role skills, I suppose. Just N years of experience at X company doesn't provide that. I'd rather look at someone's github repo than talk to their reference tbh.
replies(1): >>42149651 #
1. John_Cena ◴[15 Nov 24 18:44 UTC] No.42149651[source]▶
I've never worked at a company with a public repo. I never understood this. I have a life outside of work
replies(1): >>42149692 #
2. alkonaut ◴[15 Nov 24 18:49 UTC] No.42149692[source]▶
Neither did I. But I'd rather just "smuggle" out some past work and "rewrite it" to make it inconspicuous, if I didn't have my own personal work to show. The company I work for isn't well known so saying "I worked there in a senior role for 10 years" isn't going to get me the next job. If I didn't have anything to show for that I either made for fun or could display from a past job, I'd not apply for another until I had tbh.

People say "No I don't have any past hobby work, never contributed to OSS, and all my professional work is verboten to show" that's not unusual, but it's also not an encouraging sign to me when interviewing.

replies(2): >>42149804 #>>42149966 #
3. bhhaskin ◴[15 Nov 24 19:02 UTC] No.42149804[source]▶
Wouldn't that be a red flag if they don't have any public code at all as a senior developer? They aren't fresh out of school or just starting their careers. They should have something.
replies(3): >>42149929 #>>42149936 #>>42150087 #
4. John_Cena ◴[15 Nov 24 19:17 UTC] No.42149929{3}[source]▶
I'm a senior developer and my github is half guitar tabs. I'm not interested in peacocking. Maybe it's because Hackaday refused to put my name on the article with my senior design project years ago and I just don't want to play the game.
replies(2): >>42149977 #>>42151037 #
5. alkonaut ◴[15 Nov 24 19:17 UTC] No.42149936{3}[source]▶
Yes exactly. The code IS the cv of a developer.
6. John_Cena ◴[15 Nov 24 19:21 UTC] No.42149966[source]▶
The elitism is rampant. As an embedded sector guy everyone thinks every other RTOS isn't a real RTOS and the knowledge and wisdom don't translate.

Every time I find some open source I would contribute to, what I wanted to implement is already there or is already in the works. I'm not going to change shit just to change it. I'll buy them a coffee tip and leave.

replies(1): >>42150814 #
7. bhhaskin ◴[15 Nov 24 19:23 UTC] No.42149977{4}[source]▶
And that might be hurting you in the long run. ¯ \ _ ( ツ ) _ / ¯
8. tayo42 ◴[15 Nov 24 19:34 UTC] No.42150087{3}[source]▶
All of the meaningful code I write is private for the company I work for. This is how most code is stored.
replies(1): >>42150620 #
9. alkonaut ◴[15 Nov 24 20:30 UTC] No.42150620{4}[source]▶
Mine too. Or 99.99% of it at least. But if I were to apply for a job, I'd focus more on having at least a little repo of something to show, than on polishing my CV or doing leetcode excercises. That 0.01% code I wrote which is my github is my CV. That 99.99% I wrote for my last employer won't be seen by my next employer.
10. alkonaut ◴[15 Nov 24 20:46 UTC] No.42150814{3}[source]▶
If I'm interviewing for people to work in some specific tech stack or business, it's just as good to see completely different things they can show. Could be a php site for their book club or whatever. But the key is to have some code to discuss that is their code. Because I want to see them describe and reason about code they know, and it works 10x better if it's code they know, rather than some code I present and say "here, let's reason about this code".
replies(1): >>42151272 #
11. alkonaut ◴[15 Nov 24 21:05 UTC] No.42151037{4}[source]▶
That's a great signal (that you have a hobby playing guitar). If the other half is also interesting, it sounds like a great portfolio.
replies(1): >>42153390 #
12. skydhash ◴[15 Nov 24 21:24 UTC] No.42151272{4}[source]▶
Why not discuss a problem you have? You're obviously hiring for someone to solve your problem. Looking to check if they can code (in a specific language) seems like the XY problem.
replies(1): >>42151585 #
13. alkonaut ◴[15 Nov 24 21:52 UTC] No.42151585{5}[source]▶
Because they aren't familiar with or enthusiastic about the code I give them, they could be about code they have written. It's the classic "describe one time you did something poorly/well"-question, but with code. I want to see them critique some code, or explain what's so great, or why it ended up the way it is.

Reasoning about a problem i have (even showing some code) is also a good part of an interview. But it's my side of the field. I just found it's much better to move the interview to the interviewee's side of the turf, because they are more comfortable there.

replies(1): >>42153357 #
14. John_Cena ◴[16 Nov 24 01:31 UTC] No.42153357{6}[source]▶
I would like to just be asked. I can't post my code on github but I can talk about my projects at length.
replies(1): >>42155809 #
15. John_Cena ◴[16 Nov 24 01:38 UTC] No.42153390{5}[source]▶
I appreciate it. After thinking about this I think I just need to get over my hangups about duplicating things already done or things that aren't really important.

I just take tabs and rearrange them for personal use. Learn from my mistake and just post whatever to your github, if you fret over its usefulness or purpose you might just never grow your portfolio at all. This was a mistake. You don't have to have some gnu front-page exploratory project.

If you want to shred guitar look up Troy Grady to grok efficient mechanics that won't break your wrist (we type alot for work as well)

16. ozim ◴[16 Nov 24 11:06 UTC] No.42155809{7}[source]▶
For all this thread solution is simple. Small take home assignment where you write the code to discuss during the interview.

I know people are vocal about not wanting to do take homes. But if take home is reasonable and used as a talking piece it checks all the boxes for good tool.

I think in reality I had single person that outright refused and of course bunch of people who didn’t bother to deliver - great candidates delivered it the same day, busy great candidates delivered it over the weekend.