Comment by andy_ppp | Hacker News Reader

Comment by andy_ppp | Hacker News Reader

Parent Full thread

For a recent interview I was asked to build an IOC dependency injection library in 2h and the task was made “deliberately” unclear according to the interviewer. So I spent 2 days researching IOC libraries, building some nice examples of how it should work to get a feel for the API, writing tests up front, writing the library and adding docs. Then I got an interview! Fantastic I thought, I passed the technical with my 100% tested IOC container that had a nice interface for injecting dependencies and even options for injecting singletons or new class instances with configurations passed into the constructor.

Now I went through with them some extra things in the interview and fixed some things about the code and handled some things a bit better. After this investment of time I was told I didn’t handle errors well enough in this 100% coverage tested example code of a library. This in my opinion was not true or even discussed in the interview, error handling was certainly not specifically mentioned in the assignment.

Anyway to address your point, I don’t think you should necessarily believe what other people say about you in job interviews; there are various types of interviewer but mostly the feedback is post rationalisation of “that’s not how I would have done it” even if your solution solves the problem perfectly. For this reason I’ve decided unless I can’t afford to feed myself I will avoid doing at home coding exercises that are deliberately vague in the future.

If you want to get better at in person/under pressure coding exercises I highly recommend taking on Advent of Code [1] one year, these are the opposite of the vague problem specified above as there is an exact and clear right answer to collect each star.

[1] https://adventofcode.com/

"Build a custom IoC for an interview"

Are you kidding me? The IoC research was probably good experience if you've never seen them before, but yeah you ran into the "easier to criticize than do".

I almost guarantee none of the people involved went through the same interview process where they had to code something for two days. This is how the hazing cycle begins, because everyone thinks "man I had it hard, and my hard experiences forged me, so I'll be really hard on the next round of people".

Dumb idea. That is a conscious thought bubbling up from subconscious "trauma" and humans for whatever reason replay / reinflict their repressed emotional damage on others. I believe this is because trauma makes you feel alone, and it makes a person feel less alone.

But anyway, so the organization hazes people, who then haze the next round even worse, who then haze the next round even more really bad worse.

This basically is what IT interviewing is after 20 years of collective downward spiral hazing.

The military generally has this figured out with basic training. Basic training is basically hazing to toughen up and desensitive normal humans into becoming soldiers. But the military seems to have a policy / training feedback loop that prevents the hazing from getting worse, and staying at the level of psychological impact that they get the desired result from.

Interview gauntlets have a desired result: filter out the chaff, get good candidates. As google itself shows, one of the progenitors (along with MIcrosoft) of the great interview hazing feedback loop, that it doesn't work. The end goal of "good employee/developer" isn't enhanced by the gauntlet/hazing. And yet everyone does worse and worse variants (look at Amazon: people hate working there, and the reputation of a horrible workplace IN IT, not just on the warehouse floor, is now ubiquitous in the industry).

Anyway, fuck our industry interviewing hazing. What a stupid bunch of apes we all are, interviewing in ostensibly a purely mathematical/technical domain has been reduced to a bunch of Lord of the Flies level dystopian human psychology.

I start a new gig Monday… my best interviews were with two big tech companies… one hired me and the other said I lacked “code fluency”, which I had never heard of in those words.

Some of these places expect your first draft of a weird abstract problem to be perfectly readable in a live coding environment. Without any pressure my first draft is feeling out the problem and then trimming everything up.

In any case I landed at my preferred company, which is very exciting.

This reminded me about obe interview I had a year ago related to environments management in IaC.

The Senior Architect that interviewed me asked a question about correct infrastructure state management giving as an example their current infrastructure, giving me a hint that number of environments will grow expenentionally.

Ive shortly explained to him that the architecture they chose will be really hard to maintain when the numbers of environments grow past single digit numbers and a better approach would be to store the state per part of environment.

He got really mad at me for pointing that out (on the meeting were also other ppl) and tried to force me to chose the same approach as he did. I refused and proposed IMHO a better solution.

Long story short - did not get this job. So yes, sometimes ppl will dump you because you are overqualified and not only underqualified.

Happens more often that you might think. Score high on tech, but very low on diplomacy / political awareness. Managers want staff to make them look good -- at all cost.

Similar experience last week

The company added a take home project into the interview process retroactively

Said the task would take 2-4 hours

It took me days of research and development

And then I re-did the project in a few hours, simulating github commits to a new repo so they could see the time it took

They graded unknown things

At a certain level we all should ditch companies for giving these monstrous coding challenges or they'll probably never learn. E.g. I think it's ridiculous to let people write code when applying to Senior Developer or even worse Software Architect positions. If you can't find out otherwise if the person is a fit or not you're doing it wrong.

Geez. Half our our candidates wouldn't even know what an DI libary is.

For better or worse, when I was interviewing developers I would give specifically vague requirements, since requirement gathering is a skill that I think (senior) developers must have. I don't think that's a useful thing to do in a take-home assignment, though, since you can't clarify requirements with your client in that situation. That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose.

Interviewing is a nightmare on both sides of the fence, though. There's a reason why it's a good idea to build up and leverage your network of coworkers.

>That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose.

I always view assignments and live coding in interviews as a startup that has runway of an hour or two. Would error handling help this startup survive another day? No. But properly covering the main use case - may in fact be.

It's fair to want the candidate to mention the edge cases and tests for it in the end verbally, there I agree. But expecting 120% performance giving out vaguely formulated problems with extreme time constraints and the pressure of an interview to me seems almost delusional.

> when I was interviewing developers I would give specifically vague requirements

I did this for a while and realized that it typically panicked the people we were interviewing, especially if they were on the junior/mid side of things and as a result, gave lower-quality answers.

> I would also expect error handling to be addressed in any piece of software written for any purpose

I guess it depends on what people are hiring for but in the long list of things I need out of that person, this ends up lower on the list

The code had tests checking if errors threw under certain conditions... like I say it had error handling but we changed the way it worked during the interview so we needed to add some extra error conditions which we did and test coverage remained 100% so all paths in the code were tested.

Reply on news.ycombinator.com