Random thing you loathe right now.

Chumpy_McChump wrote:

I stand by requiring some amount of coding in a developer interview. I'm not looking for syntax perfection, I don't need something that compiles first time. I do need to know that actually know the basics of how to code. The fact that people apply for dev jobs without being able to write a six line method with a for loop or follow a simple spec is why actual live coding is important.

No experience with coding, but I got to see this type of applicant first hand while I was in cable. A network tech is responsible for the section of plant from the node to the customer. This involves some knowledge of fiber, understanding of hard line copper, and the components to make them work. It requires an understanding of AC power, DC power, and RF signal utilizing two spectrums of frequencies.

The question that knocked the most people out was "What is the downstream spectrum of the plant you work in?" This is something that is not only taught to new hires, but it's literally the downstream RF frequencies these techs should be looking at several times on even the basic jobs. A good tech will look at the downstream spectrum at least 50 times every single day, without exaggeration.

I had always known that a lot of techs sucked at Comcast, but this was eye opening even for me.

master0 wrote:

Two seperate interviews used the same site: HackerRank

Without diving into the "should there be coding interviews" question (the world has HN for that), I tried some Hackerrank challenges today and came up with some tech that you might find useful.

The tech is, after reading the question and forming a vague idea about how to proceed, type out some random nonsense that has approximately the same big-O runtime behavior as your idea. E.g. if you see a solution in O(n2) time, then type up a function that does a nested loop over the input values, counts them up, and returns 3 or whatever.

Then you hit "Submit Code". Obviously all the tests will fail, but the key is that HackerRank shows a different error response for timeouts than for wrong answers. If you see any tests timing out, then you now know that O(n2) isn't going to work, and you need to think up an algorithmically different approach.

The rationale is, for me at least so far, when I have trouble with a challenge it's always because I went through multiple rounds of typing up a correct solution and submitting it and then finding out it times out on the secret test cases that HR doesn't show locally.

Chumpy_McChump wrote:

I stand by requiring some amount of coding in a developer interview. I'm not looking for syntax perfection, I don't need something that compiles first time. I do need to know that actually know the basics of how to code. The fact that people apply for dev jobs without being able to write a six line method with a for loop or follow a simple spec is why actual live coding is important.

I honestly don't understand the "I want a job writing code, how dare you ask me to code" mentality.

EDIT: If your code interview consists of trick questions that have a very specific answer, especially ones that have nothing to do with the environment you work in, you're doing the interview wrong.

I agree that some knowledge of coding needs to be demonstrated, but I don't understand what part of that you can't tell from combining the interview, portfolio, work history and references? I find it hard to believe that people are able to fake a) a good portfolio, b) a good work history, c) good references and d) a good interview while still being unable to write a for loop. In my (albeit limited) experience, it's very obvious very quickly where a developers skills are just through talking to them about things they've made.

It also doesn't map on to similar roles. Like, I can't recall a BA ever being forced to write a spec under interview pressure, or a project manager being forced to run a mini-project as part of the interview. And that's not even including how absurd dev criteria sounds in non-dev fields.

halfwaywrong wrote:

I don't understand what part of that you can't tell from combining the interview, portfolio, work history and references?
...
how absurd dev criteria sounds in non-dev fields

Those are the two sides of the coin. If you judge people from their personal github then you exclude people who don't code in their spare time; if you judge from their references then you're trusting their past employer; if you judge by the interview then you're basically going by the interviewer's instinct, etc. etc.

I don't think most employers like coding interviews, but I think most of them consider it the least bad (or maybe second-least-bad) option.

fenomas wrote:

I'm nearing (way past really) the point where I should interview again and I'm pretty curious what the coding part will be like. I've worked in a big silicon valley company before, but entered under weird circumstances so I've never done a proper coding interview.

Part of me wants to apply to Google just to try the puzzles.

There is Google's FooBar, a silly set of tiered coding puzzles. To get an invite you used to just Google search for programmy, datastructurey queries. Complete all the FooBar questions and you get a job interview.

The interview was a tedious waste of time, but the FooBar puzzles are fun!

halfwaywrong wrote:

I agree that some knowledge of coding needs to be demonstrated, but I don't understand what part of that you can't tell from combining the interview, portfolio, work history and references? I find it hard to believe that people are able to fake a) a good portfolio, b) a good work history, c) good references and d) a good interview while still being unable to write a for loop.

If I get a portfolio (which is relatively rare), I'm not implicitly trusting it before an interview. I don't call references before a decent interview. Work history is interesting, but people lie on their resumes. The initial thing I have to work with is the interview itself, and the fact that I've seen people with dev resumes that made them seem worth interviewing crash and burn on simple coding problems had only reinforced my appreciation for posing those problems.

YMMV, of course, and different people have string opinions on both sides. I will happily remain in the "show me" camp.

I mean my current job had a little written test. Here's some tables, write a SQL statement to do X. Here's a class. Add a function to do Y. It was all first or second year college programming, nothing crazy. Just proof you know the basics. I'm pretty sure it wasn't graded on syntax. I think pseudocode was fine even. It's been a couple years so I don't remember exactly, but it was very low stress.

And it was handled like a separate part of the interview. You had 30+ minutes but the problems were simple enough to be done in 5-7 minutes. Think it was basically just a double check to make sure you weren't full of sh*t.

But I've been in hell interviews where some "smartest guy in the room" jackass asks brainteasers and if you don't know the exact answer too bad. Even if you come up with a solution that works but isn't the most efficient logarithmic answer too bad. And some intern interview way back with coding on a whiteboard that was hell. Interviews like that area just for making the candidate sweat. They're akin to fraternity hazing. Screw that.

I've been in the interviewer's chair for a couple coding interviews, and I think they still serve a valuable purpose.
On a basic level they help weed out any applicants who don't actually know how to code, but those seem pretty rare. For the most part, it's more about seeing how they approach a problem.

What kind of questions do they ask? Do they clarify requirements beforehand or just dive in and figure it out as they go? Do they identify edge cases early on or do they catch those later after they cover the more common workflows? How would they test their code to make sure it works as expected?

Seeing someone's portfolio tells you they know how to code, but it doesn't really tell you anything about what they'd be like to work with.

I've also asked simple coding problems when doing interviews, but I take pains to make clear I don't much care about the actual code on the whiteboard. Write pseudocode, handwave i/o, assume libraries for ancillary stuff, whatever. I want to see how the person addresses the problem, what questions they ask, and what they think is important to address in their solution. I underspecify the problem so there have to be questions to get it right. I also want to hear which frameworks and tools the person uses, and the process they'd go through- i.e. do they mention test frameworks or TDD?

My stinger question is "What do you not like, or want to change, about ${language}?" I just want to hear something indicating understanding of the language and interest outside the bare parameters of monkeying code.

My current place also had me design a DB schema for one of the company's products, and code-review some artfully modified real code and I think both of those were good practices.

Stele wrote:

But I've been in hell interviews where some "smartest guy in the room" jackass asks brainteasers and if you don't know the exact answer too bad. Even if you come up with a solution that works but isn't the most efficient logarithmic answer too bad. And some intern interview way back with coding on a whiteboard that was hell. Interviews like that area just for making the candidate sweat. They're akin to fraternity hazing. Screw that.

I'm not in dev, but I am in science, and That Guy is an much of a nightmare to work for as he is to interview with. That's not a too bad situation, that's a dodged bullet situation.

I've had the sample coding problem that verified I knew the basics. It took a few seconds, after some clarifying questions, and did the job. Seemed like a valid filter/time ratio to me.

I've also had interviews that were a series of challenging, neat questions, clearly authored with an eye towards getting a peek into how the interviewee thinks. But those questions were administered by people who had no insight themselves into the questions or what an interview process would even be for.

One guy just gave away 'the answer' in under five minutes of an hour long question. Great. /s

Another round, the interviewer restated the question such that the hard part was now 'done for you beforehand and passed along to you as input' I'm pretty sure that was not the intended solution, because then you're basically asking me to write a function that returns the input. High five! /s

Interviewing is a skill, and most people don't have it. The best interviews I've been a part of have included a people person and a tech person that trusted each other, and knew when to bow to the other's strengths.

thrawn82 wrote:
Stele wrote:

But I've been in hell interviews where some "smartest guy in the room" jackass asks brainteasers and if you don't know the exact answer too bad. Even if you come up with a solution that works but isn't the most efficient logarithmic answer too bad. And some intern interview way back with coding on a whiteboard that was hell. Interviews like that area just for making the candidate sweat. They're akin to fraternity hazing. Screw that.

I'm not in dev, but I am in science, and That Guy is an much of a nightmare to work for as he is to interview with. That's not a too bad situation, that's a dodged bullet situation.

Oh come on, I'm not that bad

ThatGuy42 wrote:
thrawn82 wrote:
Stele wrote:

But I've been in hell interviews where some "smartest guy in the room" jackass asks brainteasers and if you don't know the exact answer too bad. Even if you come up with a solution that works but isn't the most efficient logarithmic answer too bad. And some intern interview way back with coding on a whiteboard that was hell. Interviews like that area just for making the candidate sweat. They're akin to fraternity hazing. Screw that.

I'm not in dev, but I am in science, and That Guy is an much of a nightmare to work for as he is to interview with. That's not a too bad situation, that's a dodged bullet situation.

Oh come on, I'm not that bad ;)

I saw this coming...

ThatGuy42 wrote:
thrawn82 wrote:
Stele wrote:

But I've been in hell interviews where some "smartest guy in the room" jackass asks brainteasers and if you don't know the exact answer too bad. Even if you come up with a solution that works but isn't the most efficient logarithmic answer too bad. And some intern interview way back with coding on a whiteboard that was hell. Interviews like that area just for making the candidate sweat. They're akin to fraternity hazing. Screw that.

I'm not in dev, but I am in science, and That Guy is an much of a nightmare to work for as he is to interview with. That's not a too bad situation, that's a dodged bullet situation.

Oh come on, I'm not that bad ;)

lol! To be clear, i absolutely was not referring to ThatGuy42. Although I do bet the type of dude I'm talking about might go by XxX420ThatGuy69XxX

You forgot the WTFBBQ

thrawn82 wrote:

XxX420ThatGuy69BlazeMaster420XxX

FTFY

RawkGWJ wrote:
thrawn82 wrote:

XxX420ThatGuy69BlazeMaster420XxX

FTFY

Brett Kavanaugh?

Mixolyde wrote:
RawkGWJ wrote:
thrawn82 wrote:

XxX420ThatGuy69BlazeMaster420XxX

FTFY

Brett Kavanaugh?

what kind of beer do you like senator? do you like beer?! DO YOU?!?!??!?!?!