Hacker News Reader

Comment by lnxg33k1 | Hacker News Reader

The amount of time and energy wasted due to recruiters and hr is so frustrating for me, Ive solved live coding exercise so fast that people thought i was cheating, solved tests in a fraction of the time, etc, overall I can easily do tech stuff in interviews, and just be dumped because I am asked if I am willing to go to friday drinks or company parties and I say I don’t really want, yes, asking if one has the will to go to company parties is so important that its part of the interview process, this system is broken

View on HN

> Ive solved live coding exercise so fast that people thought i was cheating

I've once been rejected in an interview because I found a solution that the interviewer didn't think would work, spent half an hour trying to prove me wrong rather than trying to expend the smallest effort to understand - even after I proved it was correct. I was quite glad they showed me a bit of the culture though

I've had one interview with as a PHP/Symfony developer somewhere around 6-7 years ago, where I architected the classes in the app to receive dependencies as argument rather than querying them through the container, and was suggested because it was not best practices, and a couple of years later Symfony itself re-architected dependencies management the way I did in that test, some people shouldn't really be allowed to interview, most recently I've had this tech lead telling me he was architecting an innovative health monitoring system for their app, and was running every 10-15 minutes UNIT tests in the production app, asked why UNIT test would suddenly fail in production found out his UNIT tests were not UNIT, just integration querying actual resources

"Unit" and "Integration" (and E2E) are the most bullshit "technical" terms we have to deal with on a regular basis as an industry. At best, they can only tell you that integration tests are on average more liberal in their use of system calls than unit tests, that is if the codebase in question even has both.

While this dev you encountered might have had no idea what they were doing, a most charitable explanation is that they may subscribe to the idea that the "unit" is a business usecase within a single service (often a 1:1 correspondence with an endpoint, but sometimes even more than one, e.g. a form upload with a separate signed upload step to a 3rd party service).

FWIW the concept of small/medium/large as presented in the Google testing blog is a much more useful denomination.

Isn’t it just that unit tests a component of the software, and integration tests the software as a whole?

That is one interpretation. An interpretation that, once we start thinking beyond the first concept that comes to each particular mind, ends up just as meaningless:

What is a component? A global variable, a pure function, a procedure, an endpoint, a business usecase, a microservice, a microservice fleet?

What is the whole, if not the same list of questions just asked in backwards order?

It gets worse: Once you arbitrarily come up with one definition that you stick with in your project, does the definition you chose leave little to no room for interpretation? Do all kinds of tests that are worth writing fit neatly within those definitions?

Technical terms that are so loosely defined we can do without, for only two things ultimately result from their use: Apathy, or madness.

> they showed me a bit of the culture

That’s what I see interviews as: I’ll show you my culture if you show me yours.

There’s a lot of fuzzy factors like willingness to admit lack of knowledge, eagerness to learn, ability to cooperate.

You have to be willing to game the system juuuust a little bit. "Yeah, sure, sounds fun". Then don't go. If your actual coworkers instead of the HR drone appreciate you, noone will care. If they do give you shit for "not being a team player", go find another job. But in my experience the former situation will be much more common. You just gotta get past the braindead HR stuff.

If someone in an interview basically says they just want to be left alone to program (or whatever), that's at least starting to send a red flag up the flagpole. I'm sure there are some of those at many large companies but the most influential developers I've know were pretty good at working with people and casually interacting.

I'm very active in companies chat, always step up to help when I have a solution, always step up first when I notice something can be improved, I am not sure how you went from not be willing to socialise/be drunk/be around drunk people, to "be left alone"/"not able to casually interact"

On the other hand, there are companies where devs are expected to wait for a Jira ticket to be assigned to them, code it, test it, merge it, goto 1. That's the reality of the job whatever they might claim externally.

"I just want to be left alone to program" seems like a perfect fit: will do the job, will not ask for anything.

In that case--although it won't happen--I'd expect to be told that I'll be a cog who will be dropped or replaced at any moment. Perhaps a contractor position.

Is social anxiety disorder not protected by the ADA?

I have no social anxiety, at my last company I was praised by manager because I’d be the one asking questions and keep discussions going without suffering from timidity, anxiety etc., I just don’t care

No it’s not

Programming inside a business is more about going to company parties than programming fast. And I prefer people who don’t program fast, but that program for the future of the business. You might be better suited for a different career shape like foss maintainer or small, highly technical companies

I don't have anything to say about the programming fast, because that's an assumption, I've had problem solving solutions fast, but overall I spend the time to make sure the app is tested and maintainable, but why should tech people care about company parties, what value does it add for the company? I'd like to understand that because I usually adopt ideas I agree with when I am explained, last time was "To make people connect to facilitate conflict resolution" as if when I have conflicts with people I don't know I shoot them

I dont think there is a single answer like "facilitate conflict resolution", it's more of a matter of generally fitting in the corporate world, being able to build relations in that world, and not give the interviewer confirmation about its bias against "huge nerds that ace every technical challenge but then don't shower and can't talk to people without snarky remarks". yes, the bias is alive and well, and in general programming is a communications job (we communicate with stakeholders and then communicate with machines, but instead of studying marketing we study programming languages)

but let's not derail, "no i dont want to go to company parties" = "doesnt want to socialize" - "doesnt want to submit to the company" - "will probably be a hassle to work with" - "can't communicate" - and so on.

again, think hard about a different career angle in tech if you dislike these things, you might enjoy it more

Getting to know your coworkers in more social environments eases interactions with them in the workplace. As a senior/staff level engineer working with and coordinating across teams, socializing to build repertoire and ease these interactions pays dividends quickly. HR asking if you'll go to company parties is their indirect way of probing to see if you could handle this aspect to fit a senior role, but it's not imo the best way to find out if someone can handle this. As someone who doesn't drink alcohol, I totally understand where you're coming from not wanting to go to parties or bars after work. I try to socialize before and after meetings with coworkers, during lunch breaks, etc. outside of party/drinking scenarios.

Reply on news.ycombinator.com