Hacker News Reader

Comment by fillskills | Hacker News Reader

We don't have a typical white boarding interview. Based on your experience, we might send you a take home coding challenge.

View on HN

I kind of hate that as well, given that I maintain multiple popular libraries, have a ton of code on Github (of actual web apps that you can use right now), etc. What can a take-home coding challenge tell you that you won't learn from actually looking at my production code?

But, but, looking at your code requires effort on their part.

As a former tech recruiter, I can say there's a good chance interviewing team won't bother reviewing your coding exercise. It's easy to ask you to complete an exercise, but reviewing the exercise, let alone giving meaningful feedback, requires work. Teams aren't always willing/interested/able to put in the work review N take home projects.

Here's an example:

- apply to job

- recruiter does phone screen

- you're asked you to complete exercise before an interviewer has reviewed your profile/resume/application

- you put a bunch of work into doing exercise well and return it

- your exercise is not reviewed at all because: the job has been filled, the job has been closed, an interviewer didn't like your resume/CV/application, the recruiter misplaces your exercise, the team is too busy to review any exercises, etc.

I should explain what our coding exercise is. Its a decent size project on bitbucket that we ask developers to install. Yes, just install. No real coding required. Usually takes between 30 minutes to 8 hours. What we are looking for are specific things: a) Can you read and follow the installation instructions AND are you familiar with Git and NPM? b) If you face some installation issue, are you willing to spend the effort to solve it? c) Can you read code? Because sometimes a library wont work for you. So you might have to change the version or find a workaround. d) For more mid to senior engineers, we expect them to ask detailed questions on our choices of architecture, libraries and suggest alternatives and reasoning behind their choices.

So its not really a coding exercise where we ask someone to fix a bug or write code and then evaluate their coding style. Its a little different in that we are looking for problem solving skills in a startup environment. I don't think this approach will work for a large company where every developer has a specific role. But it works well for us.

If you're going to ask me to do a project that takes n hours, either I'm going to reciprocate and require the same of you, or you're going to pay my consulting rate to do it.

I suspect every good candidate had the same approach. If you're getting people to do this for free, you're not getting very good applicants.

In this market, the people you're interviewing are far more desirable than you are.

One of the best interviews I ever went on was a pair coding exercise. The interviewer asked me to come in for a couple hours, and we worked through a problem together. The "my time is your time" vibe was really nice. An interviewer wouldn't he able to scale that kind of interviewing technique unless they were upfront with candidates about what they'd he asked to do, and had a reasonable level of confidence that a candidate would have a reasonable shot at getting the job. I really liked it, and it demonstrated that the interviewer had thought about the interview in advance.

I'm willing to do take home projects when I know how they'll be evaluated. If you are willing to ask me to commit my time to something, and let me know what I'm getting for my investment of time, that goes a long way.

As an interviewer, I tend to avoid paying applicants. It just feels odd. Instead, I try to make the opportunity (interview plus potential job) as enticing as I can. Once it gets out that an that an interviewee pays interviewees, I'd be concerned that I'd attract "professional" interviewees who just want the money. As a blood bank, I wouldn't pay people to donate blood either for reasons that feel similar.

Seems like it's a decent way to verify spurious claims that are not well confirmed in a spoken portion of the job interview. It feels like a FizzBuzz version of environment knowledge and tools skills.

The kind of coding tests I don't like are the ones that seem too onerous and involved for the given role. I have recently phone interviewed with a company, which they don't make their own software as a revenue source but build software for other clients. I talked over the phone with one of the lead programmers, discussed my skills, situations related to my work experience, etc.

Afterwards, he issued me a coding exercise with a VERY DETAILED .pdf document that felt uncomfortably close to a request for proposal and summaries of requirements. I hesitated and replied back about this. They assured me that this is not unpaid work and that everyone has to take this same test, in the language of their choosing. The test was intended to produce code for a MVC web app that they can evaluate. So I guess they really wanted sample code, despite having already produced other samples from Github, and discussed my real-world MVC work projects from my perspective as a mid-level developer (including one where I had architectural control).

I think the most disappointing thing, though, is that this long test is mandatory for everyone that they interview. So, the responses and decisions you make in the phone interview portion don't seem to have any real impact on the next step in the process. Someone could have a highly popular library on Github and they could still say, okay you gotta take this test. Non-trivial tests should be tailor made to a person's own experience.

>I should explain what our coding exercise is. Its a decent size project on bitbucket that we ask developers to install. Yes, just install. No real coding required. Usually takes between 30 minutes to 8 hours. What we are looking for are specific things: a) Can you read and follow the installation instructions AND are you familiar with Git and NPM? b) If you face some installation issue, are you willing to spend the effort to solve it? c) Can you read code? Because sometimes a library wont work for you.

Interesting. I think that is one good approach. Because I've come across many people (aspiring to be software workers) who 1) cannot even follow clearly specified instructions to the letter (a basic skill for a software person), and/or 2) cannot figure out ways to deviate from those instructions in meaningful ways, if they do not work.

How you go about solving boring day-to-day business-relevant problems in a way that can be directly compared across candidates.

So interview for that. I have yet to interview at a tech company that does so. And yet, 100% believe that whiteboard coding and/or "take-home projects" are necessary for experienced candidates.

They know that what you wrote on the whiteboard was definitely your work.

Nearly all "good" whiteboard coders are regurgitating what they've memorized from a book or a website. It's an industry-wide joke.

And even the whiteboard questions themselves are often taken straight from a site like Leetcode or TopCoder. Unless you're interviewing at a big five company, you're essentially performing a standardized test.

Yes, exactly. Companies treat this stuff exactly the way universities treat the SAT/ACT. But I'd alter your statement: the big players are the worst with this stuff. They care about nothing more than your ability to regurgitate CTCI answers at a whiteboard. One mistake on a six-hour loop, and you're toast.

>CTCI

https://www.google.co.in/search?q=ctci+coding+full+form

for those who don't know the acronym.

Yes, and that's why sites/books like Cracking the Coding Interview exist. While I don't deny that they have some merit, they don't cover the full picture of what is needed.

I've had a few people (beginners looking for a job) ask me for help on just those sorts of interview questions - and not being interested in spending time on learning the underlying fundamentals, though I had mentored them (on mentoring sites like Codementor) some on those areas earlier (at their request). Misguided, to say the least. Told them that that (just doing the interview prep) is not a good approach, because, even if they manage to clear/pass the interview, with or without my or others' help, they will likely get found out soon for their lack of fundamental knowledge, soon after getting a job.

I can't speak for OPs company, but we did have a candidate recently with extensive GitHub material, so in his case we did not bother with our take home.

This is awesome and to answer your question probably not much. But also you're in the minority of applicants — most don't have as much available open source.

Agreed to a certain extent. Like I said its based on how senior we think the developer is. If going through your Github shows us that we dont have to evaluate on certain skills, then we wont. Also our coding homework is not typical. See my answer to @amorphid below.

What's your company? Are you ok with remote work? Thanks in advance!

How long would it take?

Reply on news.ycombinator.com