Hacker Newsnew | past | comments | ask | show | jobs | submit | rnovak's commentslogin

I'm sorry but why do you think you know more about this guys' experience than him? This is like when I'd get calls from a delivery driver telling me I didn't know my own address... Plenty of companies will do custom setups for big clients.


nmjenkins and brongondwana are both directors of FastMail.


> Software engineers have a NEGATIVE UNEMPLOYMENT RATE.

> land a job within a year of actively seeking

A year lead time is what a negative rate looks like?


If you keep applying for jobs you're not a fit for? Yes.

I'd say 1 year is a high upper bound though. Specifics really depend.

But here's some general stats: https://fivethirtyeight.com/features/the-biggest-predictor-o...

That link says that with a bachelor's degree or more, 17% are unemployed for 6 months or less, and 19% for a year or more. That gives a really big percent for people between 6 months and a year.

The reason I brought up the 1 year number was more to point out that there's a big difference between "I can't get a job [at all]" and "I can't get a job I really love as quickly as I want".

I mean, it doesn't matter what the unemployment rate for software engineers is, if you want a job as an AI expert at Google and all you've ever done is building simple Wordpress sites for your buddies.


Not everyone believes that romantic relationships are "one of the best things about being a human." Just because you believe it, doesn't mean everyone else does, or that you should imply that people are somehow "less than" for feeling otherwise.

As to your other comment, have you considered people who have mental illnesses/disorders? Their lifestyle (in every sense of the word) would not permit a romantic relationship, too bad they can't just "find another one".


What happens when you're asked to solve a problem that hasn't been solved before? By definition something you CANNOT google for

That's what I was looking for as a hiring manager.


Generally you end up doing a review of relevant literature and a few days/weeks/months of research and development. I'm not sure answering a question under pressure that has just been asked is that relevant to making ground in new areas of research.


The point is that solving problems, either by inventing new computer science, or more likely formulating a hybrid of known algorithms requires some semblance of problem solving.

A genuine interviewer (and I realize several/many may not be genuine) is solely trying to figure out if the candidate has these types of reasoning skills.

Let me phrase it this way: By asking a common CS question, you'll get people who simply memorize answers/algorithms. By asking something obscure that is rarely known, you can try to get a glimpse into someone's thought process, which is infinitely more valuable than rote memorization.


Right but there are lots of ways to test problem solving skills that don't involve asking people to both solve a surprise (and obscure) problem and come up with code at the same time whilst under stress. The latter three things are probably clouding your results in a way it's not really possible to account for. It seems like a lot of people setting interviews lack a bit of empathy.

The grandparent seems like the problem solving equivalent of yelling "think fast" whilst tossing a basketball at someone's face to test reflexes.


Okay, give us a generalized example? everyone who (appears) to care about being empathetic while at the same testing for these skills is continually asking for better options.

If you're hiring a point guard, isn't testing their reflexes by tossing them a basketball a reasonable approach?


Ask a simple, standard question that the candidate could reasonably answer in 10 or so minutes, confirm it works with them, and then change the parameters to invalidate their solution?

This is the closest I can get to actual project work in 45 minutes.


The second the interviewer changed the parameters people would start complaining that they were "Setup to fail." These threads commonly illuminate that interviewers simply cannot win, regardless of how genuine they are.


That's why I recommend confirming that the candidate's first solution was right. Use lots of positive feedback: ok, looks good, that's right, that's how I would do it; I see where you're going with this; etc. Then introduce the change, with a justification e.g. the team providing the input data changed their format/guarantees/technology, and we have to blah blah blah.


Why bother? You still fail to detect candidates who memorized the answer.

My standard coding question is a funny-looking prime sieve. If someone isn't familiar with one, we can work it through together and I'll have a much better idea of their learning potential & what they'll be like to work with than the intern straight out of their Algorithms final.


Personally, I don't bother. I went the route of requesting candidates go through a work sample project that I spent a considerable amount of time trying to standardize across all the languages relevant to the role. In the end though, management wasn't for me, and so I ended changing roles for something non-managerial


> What is the employer putting up? Generally nothing.

Unless you've been in the shoes of a hiring manager, I'm unsure as to where this idea is coming from?

Having been a hiring manager, it is a horrible experience. Unless it's extremely naive, homework sets generally take time to come up with and formalize, and certainly take time to review the results for.

I suppose I can understand conflating the motivations of an interviewer with their employer, but it's not generally true to say that interviewers are just trying to exploit those they interview.


>homework sets generally take time to come up with and formalize, and certainly take time to review the results for

It's a one-off effort to come up with an assignment. So the cost per application can be extremely low. As far as evaluating them, the bad ones can usually be tossed out in minutes or less. Comparatively, the cost per applicant is basically nothing.


How many companies waive the coding requirement or postpone it towards the end, if you already have open sourced a bunch of code. It is also possible that the HR managers are just happy taking a route, where they can offload most work to the other party. The can instead act as better intermediaries, aligning the hiring goals of the company and the experience for the applicant. Whats wrong with asking them to create better value or understand the domain better so as to be able to create better value?


> if you already have open sourced a bunch of code

How do I know you wrote it and didn't merely paste your name over some project I've never heard of?


Thats quite easy.

1) How many forks and stars do you have? 2) How often have you opensourced? 3) Have you blogged about them or created a documentation? 4) Why did they build each of those repos? 5) Commit logs... etc..

Very easy to develop such a framework.

One or two repos can be copied, but there is ample signature on a genuine open source contributors.


Unless they have a gun to your head, they aren't making you do anything. Applying/Interviewing is your choice.


He is saying that the company needs to tell their people to fix the process and do what they are paid for. Not offload it entirely to the applicant.

Maybe just open separate channels for people who have an open source portfolio. I have about 30 repos in my OSS, but still have to take these assignments. Its such an utter waste of my time.


Yes.... And I would choose NOT to apply to such a company, because F them.


I'm confused as to why anyone would think facebook's security is good? Their entire profit model is based entirely on sharing information that most people would consider private (and have no clue is being sold to third parties).

Furthermore, however, how would you design a Content Delivery system that was performant that also had the level of security/privacy that you'd consider appropriate? keep in mind that cookie/session based security requires extra network traffic and coordination, whereas a simple GET request is pretty simple.

Considering the massive amount of traffic they deal with (nearly 1B people, right?), I think their use of UUID type strings (though I don't think they're specifically UUIDs) is pretty appropriate.

I guess let me ask it this way: what threat do you feel they've left you open to?


Many people who are actually on the autism spectrum (such as myself, though technically I was diagnosed with Aspergers a long time ago) don't want your help.

I'm continually annoyed that I actually have to say "autism spectrum disorder" to describe MYSELF, lest I be called politically incorrect.

Many just want to live a normal life, and having other people (with no vested interest whatsoever) rushing to our "defense", is quite honestly more condescending than OP's original comment.


> Many people who are actually on the autism spectrum ... don't want your help.

Many, sure. But all? And even regardless of the answer to that question, I don't think that's a good reason to not call someone a jerk for being a jerk about it.


Having been on the hiring side of this, I'll note that it does require a bit of start-up cost (i.e. work) on the employer's part, if you want to standardize the process (i.e. to make sure you're giving the same exercise to every candidate, the expectations are clear and consistent, etc).

For example, I set up the project for my team in 7 different languages (Ruby, C, Python, Perl, C++, Java, Go), with the appropriate project structure, etc, for each. This took considerable work on my part, but the end result is that I can judge the output based on whatever the candidate is most comfortable in.

Granted, that's all assuming my skills in each language doesn't completely suck (hopefully).


Do you not use frameworks or anything?

CoC (Convention Over Configuration) solves most of the problem for you, since it's basically CRUD, and that is boilerplate stuff in pretty much any language.


Of course the task should be a test of the stuff you'll be doing on the job. If the job is to create quick websites without a whole lot of complexity for lots of clients, this would be an apt test. I'd fail that miserably and probably not like the job anyway. If the job involves working on more complex backend systems, then have the candidate write an async messaging system or DB storage system from scratch. I'd ace that. If the company has a large product, give multiple projects and let the candidate self-select.


Maybe we're just very different. It would only take me minutes to whip up a few Django models, a few CRUD views and a Bootstrap frontend, but I've never needed to write a messaging system or DB storage from scratch (there are dozens of these off-the-shelf).

That having been said, most of my value is writing sane, readable, cohesive code that can easily be extended years later, with a minimum of refactoring. That's what has been most valuable to the businesses I've worked with, and employers love the fact that my team is the one with the lowest implementation times for new features.


Yup, everybody's different, nothing wrong with that! I appreciate people who do the work you do, but not every software company does websites at all. And even of those who do, plenty have grown to the point that off-the-shelf doesn't work anymore and some specialization is of greater value. (Think Uber, Slack, etc)

I agree with your second paragraph completely.


Yeah, exactly. You'd need to go to one of the big companies to need those skills, so you usually get companies who want some sort of API glued together with off-the-shelf components, mainly because smaller companies are much more numerous than larger companies and off-the-shelf is good enough at small scale.

This wouldn't cut it at the companies you mention, I agree. I think the main thing is that the actually valuable skills (being able to figure things out on your own, having an intuitive sense for when a solution is suboptimal even when you don't know the optimal solution, knowing design patterns, etc) are transferrable, so a good developer could work on either thing.

It probably wouldn't take two hours to become acclimated, but after a short ramp-up period, they'd be pretty good at it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: