Hacker News Reader

I agree with you. The puzzle solver ABSOLUTELY hate it if you somehow say that the question is flawed. Ie if you think outside the box and render their hypothetical situation flawed. It’s as if they didn’t spend enough time to realize that they are missing the forest for the trees.

To be fair, almost everyone hates it when you show them they are wrong. Especially in the setting where they are supposed to be judging you, remember? And even in normal settings it pays to think about how some critique will be received by the other side. It's a slippery slope in the interview... For me it would raise red flags if the flaw was pointed out in an inappropriate manner. After all, this is the person who would be involved in code reviews where sensitivity to other people's feelings (and egos) is very important.

> they are supposed to be judging you, remember?

It's actually supposed to be mutual judgement. But I agree: be respectful if you decide to drop a remark about the relevance of the question. There are enough reasons to treat people with respect even if you can afford to turn them down.

> It's actually supposed to be mutual judgement.

Agreed, I was being sarcastic.

It didn't come across as sarcastic to me, btw

"It’s as if they didn’t spend enough time to realize that they are missing the forest for the trees."

In their eyes, they have given you a problem involving a tree from the graph theory and you are insisting on an "out of the box" solution involving woodpeckers.

Let me elaborate.

Usually hypothetical situation is just a way to talk about an abstract problem.

It's easier to visualize and to talk about an egg falling and breaking (or not) than abstract measurements.

Now what you call 'thinking outside the box' is just attacking the irrelevant details of an imaginary situation which is there purely for convinience and can be replaced with another hypothetical situation corresponding to the same abstract problem.

I like solving puzzles. I like algorithms. Every once in a while I even get to use them at my job! Solving these kinds of things is at most 5-10% of a developer’s job, and that’s probably a stretch in reality. The number of times I’ve seen things like dynamic programming come up in a real world application are vanishingly small, and rarely will you need to roll your own implementation rather than using a third party library. Even if you’re working on a library like that, considerations of good software design principles, infrastructure and the like will consume a large portion of your time.

I am like you. For me, the solution has been build something and show it off. Building a great and useful app rarely requires Herculean feats of logic and puzzle solving.

Years ago I was rejected by Google for a permanent position, then a year later employed at a much better rate as a contractor in the same building I'd interviewed in. I'd built a relatively cool app (full stack, from Linux to Tornado to JavaScript to UX), like Secret or YikYak (but a few years before either).

The people in Creative Lab were impressed with the ride range of knowledge I had, the SRE guys who rejected me got stuck into me for mixing up some VMware terminology.

My current problem is that I built an app and showed of to some gov agencies, and now that demo app is solving their business problems.

>> "What I do enjoy, however, is building up. I like modeling and being about to think at greater and greater levels of abstraction to solve problems that aren't puzzles, but instead open ended questions."

In my opinion, you will do well if you focus on building your own business sooner or later.

What an odd thing to suggest. Owning a business isn't for everyone. Not by a long shot.

No, it is not. But grand parent comment was giving this advice based on the quoted specifics and not for everyone.

And most importantly, the commenter gave one's suggestion based on representiveness, which are not facts. The rest follows from here.

But building something from scratch, even if non-profit, is the easiest way to get a job you really want. And at the same time you can find out that you like doing actual business and smoothly transition. It's a win-win IMO.

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.

Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.

Which makes sense right? Same reason a military general doesn’t start as a general. Architecture takes experience in the weeds to give a breadth you can leverage as you reason through architecture. Architecture isn’t aslways black and white decision making based on some specs which is where experience can help a ton.

Generals often start out as lieutenants though (e.g. officer academy drops you in on a higher rank).

In the U.S. military this is not true. People graduating from OCS, ROTC, or one of the academies start off at O-1 (2nd Lieutenant).

What's your disagreement? 1st Lieutenant vs 2nd Lieutenant? Lieutenant is commonly used to refer to both.

Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.

Well, I misread the comment I responded to. I thought they said that academy graduates don’t start off at lieutenant and start off at a higher rate.

It’s the best way to get into it anyway. Making architectural decisions without experience implementing them sounds like a recipe for disaster to me.

Yes it is possible.

No I wouldn’t think so. But knowing about a role and angling towards it early if that sounds more interesting is hopefully helpful information.

Not sure it would happen that way out of choice, but the role can get unexpectedly thrust upon someone, experienced or not (Think startups, desperate to make ends meet with a handful of inexperienced engineers...or even at medium sized companies, remember back when Google had "20% projects"?). At startups especially though: they don't have money to go out of their way to hire an overpriced "experienced software architect"...

It goes something like: "Hey, new Engineer, I need you to work on experimental feature X". - Then the engineer builds system Y to provide feature X, probably poorly architected and not scalable, not expecting it to go anywhere. Some months later, app containing feature X gets distributed to thousands of users, or goes viral and hits millions of users.

Congratulations, like it or not, you have now become the lead architect of the now-widely-deployed "experimental" system Y, and you are going to either crash and burn or become a damn good software architect by maintaining it out of sheer necessity. Later, you find yourself putting "Lead Software Designer" on your resume, having earned that role and title.

A lot of successful software was originally designed "by mistake" and grows far, far greater than its original purpose. And in contrast, you get the well-designed software that was properly architected, but never goes anywhere because it never saw the light of a successful deployment at scale.

I think you’ve accurately described the vast, vast majority of production code that’s hasn’t been through a second wave of engineers/management and rewritten. If it works, and requirements aren’t changing, then your MVP has become the gold standard

I like roles where I get to do both! I've found that a lot of problems come from these being different roles, and the developers not really understanding or buying into the vision of the architects (who might be able to see the big picture, but can often make decisions that make no sense due to being removed from the details of the existing implementation).

Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.

The puzzle solver obsession in SV has always confused me. Seems to me that you would only need a handful of those type of personalities at any software company. The majority of the work is just shoveling so to speak.

I'm no expert but I know a logistics company that has the 30 workers 1 puzzle guy setup. He maybe writes 20 lines of code a week but its on stuff other people cant figure out. However if he was the only type there literally nothing would ever get done.

You're better suited for research which is about working long term on open problems.

I think the opposite would be true; research might benefit from puzzle solving, and software engineering is precisely the discipline of building up and reasoning about layers of abstraction and components of a system.

Research is a grind when it's not about writing grant proposals and then it's a different grind.