Live data from Hacker News

The latest trend for tech interviews: Days of unpaid homework

work.qz.com

211–220 of 1001 posts

Re: The latest trend for tech interviews: Days of unpaid homework

#211
post #117

Earlier quoted context omitted.

I wonder how much of the shortage is due to there only being a relatively small portion of jobs that developers actually want. Every time I've worked at a small company that had obvious perks (using a cool language, building a cool product), we had a bunch of applicants to pick from. We could be picky. But the few times I worked at a company on soul-sucking work like internal legacy tools in VBScript for a non-tech c…

I never see a shortage of people applying. I usually see a great shortage of people I want to hire. Mid-level position, asking for 5 years of related experience? 85% of the resumes have no related experience. Fresh out of school, that is. The virtual pile gets much shorter when minimal criteria are applied.

same here, looking for a local web developer, getting people that can't spell the difference between the various css positioning. 8 in 10 couldn't pass a javascript version of foobar test and 3 in ten even got some basic stuff from the assignment wrong (like, printing 0 to 99 instead of 1 to 100)

Re: The latest trend for tech interviews: Days of unpaid homework

#212

Earlier quoted context omitted.

> the task was to set up flask with two routes Setting up a web server is also a different skill than backend programming -- many experienced back-end programmers have never needed to spin up a new server for their job.

I'm very comfortable with never hiring a backend programmer for whom this is an insurmountable obstacle.

It's not insurmountable, but it's absolutely time consuming, especially when it's not a regular aspect of your job. I recently had to do exactly this for a prototype that I built and it took up a good 10-20% of my total project time.

Another way to look at this is, are you more concerned with testing a person's end-to-end or development skills? There's no right answer, but you have to realize that testing one comes at the expense of the other. If your company often uses brand new development stacks, it might be important to test a candidate's ability to do exactly that, but if your company has a framework in place that everyone uses, then it's probably best to focus on a candidates pure dev skills.

Re: The latest trend for tech interviews: Days of unpaid homework

#213
My response - and even how I got jobs early in my career as a developer was this:

"let me know show you some of the software I've developed on my own - I'd me happy to tell you how it works, the tech involved and the patterns used ..yada yada"

Corollary : if you apply for a job or walk into a tech interview and can't talk about these things, its a red flag for the interviewer.

PS. Now well on in my career, and having started my own software business after leaving a bigco. I'm back to a very similar thing: if I go to a meetup / conference / sales call I better have some code I'm will to show and discuss ..and highlight what I consider my talents. (fwiw : it feels great to be back in this mode)

edit: also : asking an candidate to do the kind of homework/coding is total BS. I wouldn't do it. But I would give them the line above :)

Re: The latest trend for tech interviews: Days of unpaid homework

#214

One big issue that a take home assignment is that it removes the ability for the candidate to ask questions. Interviews are two-way streets. Nowadays, I reject more companies than I interview for based on an initial phone conversation. I have requirements in what I look for in a company and position, and some simple questions help me resolve many of the primary requirements. Given a take home exam, I will have invest…

At my current job (where i've interviewed candidates) we give out a take home assignment, but we explicitly enforce a 2 hour time limit to do it. We felt this was reasonable because combined with an onsite interview and a phone screen, the total amount of time a candidate would spend interviewing for a position is about 8 hours (a typical workday). I'm not against take home assignments per se - but 3 day assignments seems crazy. I can't imagine myself doing that as long as there are other decent jobs out there that don't require it.

Re: The latest trend for tech interviews: Days of unpaid homework

#215
post #171

Earlier quoted context omitted.

Have you tried developing your junior talent instead of driving them away so you need to fill a gap at mid-level?

Are there companies where people don't periodically move on? The culture right now is to hop between companies. It's not necessarily a bad thing. People get tired of their work and need novelty.

[deleted]

Re: The latest trend for tech interviews: Days of unpaid homework

#216

Earlier quoted context omitted.

Developers have a similar attitude, despite currently being one of the most privileged segments of the workforce save perhaps investment bankers. We have a straightforward professional path that does not require massive debt and burning half of our youth doing academic busywork and entry level drudgery - like it happens in almost any other professional field with similar compensation. The industry requirement to prov…

I might assert that what developers have is not a privilege. A privilege is something granted out of generosity or grace by another party, perhaps even undue (and hence the grace). What developers have is some "game", which makes them a "player". As soon as they lose their game, they cease to be players. Their relation to the game is exactly their value and nothing less. Tech employers are higher level players who kn…

A thousand times this. Although I still write code, and I would be comfortable being a tech lead forever, after 20 years I decided to focus my career on management for my own job security. It was either that or specialize in some hot field, but that's not where my heart is. So as a generalist I would be perpetually competing with the ever widening cohort of "senior" devs who have the SV-standard 5-years experience that represents the capping out of their signalable value.

The picture gets worse when you look at typical interview panels at hot SV companies: median-age 26, went to Stanford/MIT, interned at AmaGooFace, base their hiring process on established "rigorous" stack ranking of candidates based on their performance on fixed algo/whiteboard questions. While I can generally do pretty well at these, variance is high and it does nothing to differentiate me from smart but inexperienced people.

I think it's ridiculous that SV treats programmers like sports players with a limited shelf life. Code bases would probably be a lot better, and workplaces more pleasant to work in if experience were more valued. However I hold no illusions about the way VCs work: they require a steady influx of impressionable young blood to exploit with visions "changing the world", so it makes sense that older jaded devs don't fit into that picture. I do think there is an arbitrage opportunity for older talent though.

Re: The latest trend for tech interviews: Days of unpaid homework

#217

Earlier quoted context omitted.

Came here to say almost exactly this. I can't speak to the bias issue. I do know that spending three days doing a little chat app last time around landed me one of the best gigs I've had. The process was painless, I would have spent that time coding and refreshing skills anyway, and the project was actually fun. I also know 100% that if the company I work for encountered a candidate who needed more time to work on th…

>I undertook this project after two 30 minute conversations had convinced both parties that there was a fit, and the project was a next step. In this case, I don't see it as unreasonable, because you didn't have to do the project just to have a shot at someone talking to you in person. I would never do a homework project as the first step in an application process. I would do one as the last step, after I had learned…

I'm rethinking what I did on my last hiring position. I sent a take-home test that should take about 2-3 hours to those who sent in a decent resume. It filtered out a little over half of the applicants I responded to, as in half didn't respond. It further filtered out a small segment who didn't do very well on the test. A filter is definitely needed to weed out those who are simply casting a wide net, are looking for contract work instead of a FTE and to those whose skills simply do not match what they've purported in their resume.

I really can't call everyone who has a decent resume, its way too time consuming. If we had a recruiter then maybe it would be worth it, but not personally. Maybe a take-home quiz that takes like 20-30 minutes would be a good filter instead?

Re: The latest trend for tech interviews: Days of unpaid homework

#218
Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly.

Yet, we do. Ok, then what about open source contributions (if they have them)? Well, sure, but we don't really know, for sure, if that code is their own or if they indeed truly wrote it, can we? So we can't count on it. It helps but it can't be an automatic "this person passes the technical" signaler.

So maybe the person shares actual code and walks us through it that they wrote, even if not open source? Again, we can't know for certain it is their own code and not some friend who wrote it for them 2 years ago that they claim is their own. Or was a teammate's, or what-have-you. So we can't count on that either.

Apart from getting a candidate to actually pump out some code, even trivially, we don't really have a way to de-facto verify that the person says they can do what they say they can do, short of a personal reference from someone, say, in the company already that knows and has worked with the person in the past.

I absolutely hate this practice of having to constantly "re-prove" to the next employer that someone knows how to write software. It's extremely redundant and yet we keep on doing it, with no real hope of actually making it better.

Re: The latest trend for tech interviews: Days of unpaid homework

#219

Earlier quoted context omitted.

Companies don't do this because it will wildly cut down their candidate pool. There is _literally no chance_ that I am going to leave an existing job for a "week or two" contract with a company. If that's part of their hiring process, I will simply look elsewhere.

We don't do this, but we do have people work for us on a contract basis for a period of time while they still have another job. We have a lot of people who are looking for extra cash or maybe they like to just do a bunch of contract projects. But one thing can lead to another and then you decide you both want to work full time with each other.

Which is flat out gross misconduct for 99.9 % of all full time employees in the engineering field.

Re: The latest trend for tech interviews: Days of unpaid homework

#220

Earlier quoted context omitted.

Companies don't do this because it will wildly cut down their candidate pool. There is _literally no chance_ that I am going to leave an existing job for a "week or two" contract with a company. If that's part of their hiring process, I will simply look elsewhere.

We don't do this, but we do have people work for us on a contract basis for a period of time while they still have another job. We have a lot of people who are looking for extra cash or maybe they like to just do a bunch of contract projects. But one thing can lead to another and then you decide you both want to work full time with each other.

I agree with your general stance on CTH - but this seems a little sketch. If you're already a contractor and are used to trying to keep multiple projects going, or have some idle time, then by all means. From the candidate side its nice to sign up with eyes open to the bad as well as the good.

But if you're working someplace salaried, it seems fairly dishonest to spin up a short contract. especially when most of the attention is consumed in the process of getting started (environment, implicit policies, platform, etc).

plus on your side, you don't really know how much of that person you're getting. if the work is great, thats fine, but if it seems slow or misguided, is that a fundamental reflection of ability, or because they tried to cram it in between 8pm and 11pm every night?

Post reply on HN