Live data from Hacker News

Take-home interviews

blog.triplebyte.com

11–20 of 295 posts

Re: Take-home interviews

#11
post #7

As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?

Approximately weekly, when explaining something to another engineer.

Why don't you give yourself time to think? Why don't you use documentation?

Edit: Oh, and how do you version control the white board?

Re: Take-home interviews

#12
I really hope this works. I never understood whiteboard interviews. They don't reflect how real development works or how that developer works either. I hope you post an update when you have enough info!

Re: Take-home interviews

#13
post #7

As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?

I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;) However I realize I may have a bias as I do ok on most blackboard coding interviews I have done.. maybe been stumped 1 time out of 15 or so in my life? Some of it is a skill, that the more you do the better you get at it, but…

> I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;)

In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard, sheet of paper, or bare text document. I personally do not when giving interviews.

My bigger problem, and I seem to depart from the vocal majority on this, is that my preferred normal workflow does not use whiteboards for anything besides task lists and diagrams. In 13 years[1] as an engineer I have never written actual or pseudocode on a whiteboard outside of an interview. I rarely do it on paper. I have never worked with anyone who did this very much, either.

[1] Granted, four of those were as an EE, but I still had to deal with code from time to time

Re: Take-home interviews

#14
> We expect them to spend about 3 hours on the project (or as long as they want to spend to show us that they're a good programmer).

3 hours isn't too bad. I had a friend interview with some hedge fund and he said he probably spent 30+ hours on a take-home project (he didn't get the job). I thought that was way too excessive for just 1 interview.

Re: Take-home interviews

#16
I like these great in concept. When I've been between jobs, I've been very happy to participate in them.

A couple open questions:

1 - Is it reasonable to expect a 10x programmer whom your are trying to poach to give up so much time? (Or should you give them a $250 Starbucks gift card or something similar for their time?)

2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his (non-programming) take-home homework for a job interview, and he got the job. He only lasted 6 or 7 months, but it was enough to be awful for all parties involved. I don't have a great counter-solution other than ask for someone to come in to the office to do the work, and even then you can't tell if they have remote support.

Re: Take-home interviews

#17
post #7

As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?

Approximately weekly, when explaining something to another engineer.

As I mentioned in another post here, I don't think I have ever written code on a whiteboard when explaining something. Explaining code has always happened in front of someone's computer, in an actual editor or IDE. Where I currently work, we typically pair on really hairy code.

Re: Take-home interviews

#19

Earlier quoted context omitted.

Approximately weekly, when explaining something to another engineer.

Why don't you give yourself time to think? Why don't you use documentation? Edit: Oh, and how do you version control the white board?

how do you version control the white board?

We have a magic white board that can print out a big piece of paper showing everything on it. We also take pictures of it (and lesser white boards) to record designs agreed. Those pictures generally get put into a formal design document that is reviewed, signed, approved and all the rest of it.

Re: Take-home interviews

#20

Seems good, I like the choice. In discussions on this topic I see a lot of: "Programming on the spot is hard, let people program at home"! But then other people say "Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school". I am not looking to hire devs right now, but I am thinking about…

Its good in theory, but it leaves a lot of ambiguity for the interviewee to parse through. For instance, if given a two week window would it look better for me to do it tonight? Would it show ambition? Or would it seem like I'm desperate, and lead to a lower amount of compensation being offered to me? Should I spend far longer then five hours on the assignment, and turn in superior work while making it seem like I only spent 5 hours? What is my competition doing?

As someone who's recently been through the ringer, including one six hour take-home, all I want is a clear demonstration of respect and rationality.

Bring me into your professional office. Let's talk like professionals. Allow me to demonstrate my professional skills. Call me back with a professional yes or a professional no, all within a professional time frame. That's it.

Remote or otherwise less traditional assignments / roles / jobs will deserve and benefit from their own process. But how we strayed from the straight forward formula is beyond me, my guess it was an initiative started by a handful of companies who had trouble hiring.

I don't think hiring devs is the systematic issue everyone makes it out to be. Assessing talent is always hard, be it an artist's, an athlete's or a programmers. I think rather then assume the cost of the investment in hiring, companies chose to blame the system and that's where this absurd roller coaster started.

Post reply on HN