Hacker News Reader

Comment by weego | Hacker News Reader

How often in their day job will someone be under artificial time pressure to solve a task and get it to a point where it's "good enough"?

You're actively removing the possibility of finding out who would think "meh thats good enough I guess" is the effort needed for production code and people who would go the extra step of spending time analysing and fully solving the problem.

2 people with equally average solutions...would one have done more given the chance? Both? Neither? How can we find out? You've added uncertainty to the process rather than solved any problem.

View on HN

> How often in their day job will someone be under artificial time pressure to solve a task and get it to a point where it's "good enough"?

There are quite a lot of software jobs like this. Maybe the time pressure is more 2 weeks instead of 4 hours, but deadlines are a real thing.

Two weeks is decidedly not 4 hours, no matter how you try to relate them. I could write the Falcon Heavy takeoff sequence in two weeks. (joking, of course, but the compression factor of 4 hours over two weeks is overwhelmingly and obviously higher)

> How often in their day job will someone be under artificial time pressure to solve a task and get it to a point where it's "good enough"?

In my job, pretty much every week. Many of my tasks are "implement feature X to a passable amount in 2 days", and then it goes to someone to use and get feedback on immediately. My team are mostly the same.

This sounds to me like the nature of every job. Secondly, the interview process has never, to my knowledge, reflected on the job performance, and I'd suggest it shouldn't.

Often enough someone will be under real time pressure to solve a task, right?

Many times, markets and business dictate time pressure. So yes, this is very real in startups at least. Like for instance, an inevitable market development might want you to ship code by the next week, however improbable or impossible. I know I'll get a lot of flak for saying this, but that's ok. I've experienced it first hand. In an early stage startup, when faced with the choice of losing revenue/delivering on time, you'll choose the latter. That means your shipping slot is fixed and so are your features. You'll just have to slog it out or work real smart. Even if you cut features, you'll still realize there's a lot to be accomplished in a short span of time. This is mostly a one off thing. If such events repeat endlessly, that is classic bad management. So you'll need to deliver on time, sometimes :).

So, I guess that companies which administer such time based tests foresee at least one such situation for that role. I'm just speculating.

That's more indicative of poor management and planning on the company's side than reflecting on the performance of the candidate if the time pressure is a regular occurrence.

Few people perform well under pressure. Do you want to test what is their mediocre performance under time limits like on a school test or what they are really capable of?

With this approach you will hire people able to churn out crappy but "good enough" code in the limited time. Not people who actually can do quality work.

No real company has perfect management and a lot of them have poor planning.

> Few people perform well under pressure.

Yes, but majority of jobs have some level of time pressure. That being said, there is such a thing as reasonable deadline.

> With this approach you will hire people able to churn out crappy but "good enough" code in the limited time. Not people who actually can do quality work.

Inability to perform under pressure does not imply high skill without pressure.

> Inability to perform under pressure does not imply high skill without pressure.

Ability to churn out crap in a time limit doesn't imply competence neither.

Well, it implies competence at churning out crap within a time limit, which for a lot of managers out there is precisely what they're looking for.

Well isn't that the point of these: to see that they don't churn out crap, but do a decent job.

There's never enough time or resources to do everything you want to do. Believe me; I've gone from one extreme to the other in company and team size. For any but the most mechanical of development tasks (e.g. CRUD apps), it's very common for a developer to make an estimate, realize that it was too optimistic, and then have to reduce the scope. So it's valuable for a developer to spend some time up front thinking about the design, break it down into tasks, prioritize them, and then implement the highest-priority part first. Then, even if they have to cut tasks, they can deliver something of value without having to do shoddy work.

I do think an interviewer should be completely up-front about what they want out of a candidate if they give a coding challenge that's too ambitious to implement perfectly within the time limit.

Reply on news.ycombinator.com