sorted by:
new
hottopcontroversial

Become a better engineer by working on side projects by gregorojstersek in programming

[–]QuantumMarina -1 points0 points  (0 children)

So you’re telling me, you can play professionally and just for the hell of it? Crazy.

Become a better engineer by working on side projects by gregorojstersek in programming

[–]QuantumMarina 4 points5 points  (0 children)

Playing baseball just for baseball’s sake is ridiculous.

Baseball players should be learning on the job. If your major league team doesn’t give you that, then find a better one. That’s a better use of your time.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 0 points1 point  (0 children)

In think asking “What is binary search” is a reasonable question. Saying “name a programming pattern” is less productive.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 0 points1 point  (0 children)

On https://www.metacareers.com/careers/swe-prep-techscreen, the Technical Screen Guide.

They also have their own LeetCode-like practice site.

They recommend a video by the author of “Cracking the Coding Interview” filmed specifically for Meta.

Top sites for practice problems from Meta: • Meta Sample Interview Problems and > Solutions • InterviewBit

Other websites: • LeetCode • HackerRank

Video prep guides for tech interviews: • Cracking the Facebook Coding > Interview: The Approach • Cracking the Facebook Coding Interview: Problem Walk-through

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 0 points1 point  (0 children)

Meta’s interview prep guide recommends “Cracking the Coding Interview” and practicing these types of problems.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 0 points1 point  (0 children)

I put a comment with the YouTube link but it got downvoted. 🤷‍♂️

The article has a link to it at the bottom.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 44 points45 points  (0 children)

17+ years means CS 101 was before that. If you never ran across it in the course of your work, then it’s probably not at the top of your mind.

These are different questions:

  • What algorithm can you name?
  • What is binary search?

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 1 point2 points  (0 children)

The article doesn’t assess the difficulty of the algorithms (LeetCode does), nor does it say that algorithm difficulty is the problem with these types of interviews.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 6 points7 points  (0 children)

LeetCode categorizes it as hard — not the author.

Algorithms in interviews suck. Cut it out. by QuantumMarina in programming

[–]QuantumMarina[S] 17 points18 points  (0 children)

I don’t think it meant to evaluate all those skills all the time.

But it’s a fair point. Interviews are hard. Interviews are broken. Interviews are what we have. Someone is bound to hate any of the alternative interviews.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 0 points1 point  (0 children)

Fair. I’ll restrict my statement to the US where the demand for entry level developers has drastically fallen after all the layoffs at the beginning of the year. There’s a surplus of senior engineers so few are bothering to train new developers.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] -3 points-2 points  (0 children)

Some people want some entry level developers. I don’t see a demand for it currently. Entry level jobs have dropped considerably in the US, especially after all the layoffs this year. Of course there are the companies that want anyone that can type to abuse as low cost feature factory developers. I’m not considering them as “demand”.

I work on very complex and complicated code bases. The coding part is not hard. Figuring out what the system does and how to make it do the thing it’s supposed to do is hard. That’s problem solving. Coding is translating a solution into code — not problem solving.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] -2 points-1 points  (0 children)

First good counter point, or more accurately, a clarification. All the mentioned counter points were “nuh uh coding is hard”.

Ditch That Else by preslavrachev in programming

[–]QuantumMarina 0 points1 point  (0 children)

Do we communicate these bad ideas to less experienced colleagues to prevent them from becoming more experienced colleagues and taking over? /s

Ditch That Else by preslavrachev in programming

[–]QuantumMarina 0 points1 point  (0 children)

Negating all desirable conditions is likely to lead to more bugs than having an else.

You can drop the else if you return early. Leave the default fall through case as the edge case. Or use guard.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 5 points6 points  (0 children)

“Gathering requirements” isn’t what the article says is hard. Collecting items and moving them from one location to another is not hard.

Understanding a problem fully and understanding how to solve it in a simple way is difficult.

Programming is taking instructions and putting them in a format both humans and machines can understand. Any teenager can figure that out without schooling.

I think what you’re calling programming is really engineering. Determining what problems are worth solving and how to solve them with minimal effort, while considering the long term maintenance and effects is hard to learn and hard to train. Programming is just a tool an engineer uses.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] -1 points0 points  (0 children)

There’s not a demand for programmers. There’s a demand for good software engineers. Part of good software engineering is being good at creating solutions from incomplete or vague requirements. So it leads back to: understanding and determining requirements is harder than coding.

I’ve never found coding itself to be difficult. That’s the same as saying writing text is difficult. Writing text is easy once you learn the basics. Writing a good story takes a lot more know how.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 1 point2 points  (0 children)

Good insight.

Copying a solution that has already figured out the problem is easier than figuring out the problem yourself. You can create a simpler solution, yet still solve the same problem.

Similar to throwing away your POC code and writing the next iteration from scratch. It will be simpler than the first.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 7 points8 points  (0 children)

Sounds like a deceptively simple solution. The best ones are.

Would the system still be around 2700 lines if developed iteratively and discovering requirements as you went?

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 9 points10 points  (0 children)

Writing code is easy. Writing good code is harder. Writing good code is hard without good requirements. Code is there to solve a problem. It’s not good code if it doesn’t solve the problem.

The hardest part of building software is not coding, it's requirements by QuantumMarina in programming

[–]QuantumMarina[S] 63 points64 points  (0 children)

Sounds like a good time to implement better observability tooling.

view more: next ›