Hacker News Reader

Comment by Arzh | Hacker News Reader

Then the other option is to do a small take home test. Are you ok with that?

The other option is to check references, do credential checks, and simple bullshit screens during interviews, like every other professional interview.

Literally every other profession has this challenge! Programmers are unique only in their seeming inability to realize that they are not unique.

Accountants are not asked to solve double-entry accounting whiteboard problems. Finance professionals are not given take-home banking projects. Only programmers seem to be unable to be reasonable interviewers.

Yes. I told the interviewer he could call any of my past managers, knowing they would take the call, and knowing they’d give a glowing report. He laughed!

Well...fuck that guy. There is really no better measure, assuming you have the basic social skills to see through a con job/scam. I mean yah, you could always be tricked into calling someone's buddy or something, but with any depth or tactful questions that is rarely going to fool anyone.

This is not to take away from your point, since I agree with you, but both accountants and finance professionals have stringent licensing requirements which (in theory) could provide a baseline expectation of competence.

That is the reason they get away with not testing them, because they have a universal test they can look to. Software jobs are pretty fluid, so unless we have a massive standard test that cover anything from embedded c to FE with react, it seems that kind of test is out of reach for software people.

Civil Engineering has a huge gamut in specializations and in the last century has seen quite a lot of technological change; programming isn't as special as it thinks it is here. A credential test doesn't have to cover everything, it just has to cover the foundations and get some sense that a person is capable of life-long learning and improvement.

What about jobs like "business analyst"?

I don't see how that is actually doable all the time. In my short career I have moved from embedded c / c++ game engine / full stack / DBA / backend. All at different jobs with the previous manager not knowing I actually knew how to do the next job, if they were asked anything other than generic questions I would have sounded like a fraud.

Every accountant attending an interview can produce a certificate from an accredited national group saying that they have taken an in-person, proctored exam on double-entry accounting, which is the 'credentials check' you refer to. There's nothing like it for programmers.

And? You think that a certification exam provides more evidence than a university degree? (which, let’s face it, most programmers have).

No, this is a made-up difficulty, caused by the fact that programmers think there’s a silver bullet solution to evaluating competency in an “objective” manner.

There are plenty of options. Programmers only just have to pick one, or create a new one for all that it matters. For instance, NCEES that runs the Professional Engineering accreditation that every other Engineering discipline utilizes, has a Software Engineering PE. Tomorrow we could grandfather in every Senior Dev with 5+ years experience as a PE and then start requiring it, and encouraging kids to train for it and acquire that accreditation.

One major proctored exam scales a lot better than every company for themselves reinventing an almost proctored exam.

Have you seen the Software PE? In contrast to the other PE exams, it manages to cover everything except actual programming.

https://engineers.texas.gov/downloads/ncees_PESoftware_2013....

That is because it is an actual __Engineering__ exam, not a programming one. Testing for programming skills in an SE exam is like testing a mechanical engineer's CAD skills. I would argue that the majority of "SE" jobs do not actually entail engineering but software development (or construction), which is only a small subset of SE.

The computer engineering exam has tons of the underpinnings covered, with a whole section on relevant math. Where as the software one pretty much only covers process. The one algorithms or discrete math question they have boils down to just 'what is big o complexity'.

I guess the question is what is the necessary "base set" that shows proficiency enough in learning that you could throw someone at a problem and expect them to solve it. Keep in mind that to keep a PE active there are also lifelong learning requirements.

Certainly what I see in the PE today seems like a good starting base. Having some idea of Big O complexity can be a great place to start when working with algorithms, and certainly from my perspective I'd rather have an engineer with a solid idea of Big O complexity trade-off issues than a bunch of rote memorized implementations of classic algorithms.

Also, don't forget that a lot of discrete math and algorithms bubbled up into the Fundamentals of Engineering test that is the prerequisite of the PE test:

https://ncees.org/wp-content/uploads/FE-Ele-CBT-specs.pdf

Which isn't to say that the PE can't be improved for Software Engineering to better meet industry needs, but certainly the current PE still stands as a good starting point that the industry could try to hone to a better tool if they wanted.

You mean a CPA.

My girlfriend has just graduated college with an Accounting degree.

> There's nothing like it for programmers.

What exactly is the difference between a BA (Accounting), and a BSc (Computing) in terms of validation?

Now if you want to talk CPA? Sure, but the equivalent of that would be a Software Engineering (similar to PE/CE/ME).

Apples and oranges.

The other, other option is just refuse to do either. I get all my work from friends I've worked with in the last 20 or so years. I mean if a company insists on these hiring practices, and they continue to get bad applications because of it, the probably aren't going to be around for long anyway.

Ok so you are out of the running for this, this is obviously for testing people you have never met before.

Yes. I strongly prefer an offline test, if it realistically wouldn't take more than a few hours.

Yeah we try to have a limit of 4 hours for this kinda thing. We understand that it is the interviewee's free time but when you need to screen 12 people for a job it is not worth a Senior Engineers time for a small startup.

WHAT?!?

Getting the right team is one of, if not THE key to startup success.

Yet you consider it not worth a senior engineer's time to evaluate the candidates for the next hire, and the presumably with whom they will need to work - productively?

Check your org's runway and be sure to have your resume ready when it gets close to the end. I wouldn't expect take-off.

Sorry I assumed that the word 'screen' was universal. This is the first step, it is a waste of a senior engineers time with a candidate that is not even close to ready for the job.

Yes, I suppose 'screen' is a bit ambiguous. Doesn't seem like a pool of a dozen is the first step. I'd want the Sr Devs involved at least out past the final half-dozen if not dozen -- not for 4 hours each, but at least a chat about what they've done, problem-solving approaches, etc.

I wish you luck

Reply on news.ycombinator.com