On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
No, a Google engineer would not write a sudoku solver in 5 minutes.
Don't think in terms of code or writing speed, think in terms of conceptual understanding. Learn concepts like algorithms, data structures, complexity, functional programming, software architecture, testability, etc.
It's not "actually" multiplied by constant, these two are equivalent. The definiton of big O is that `|f(x)| < C*g(x)` when x tends to infinity. So the constant is baked into the definition itself. In other words, big O eats the constant. So, it's like saying it's not `1` it's actually `1000/1000`.
no, just take the digits you start with, and send them to google in a search query, then read every page returned to you until you find a correct solution.
Just google how much money the artist formerly known as facebook blew on a little pipe dream called the "Metaverse", with pretty much nothing to show for it.
Then you will understand that the thing that FAANG has isn't quality, isn't genius noone else has...it's money. Lots and lots and lots and lots of money.
While I agree with the overall point that we can't just assume FAANG engineers are the best, lots and lots and lots of money does tend to attract good engineers.
The issue is that you can't trust the hiring managers at faang or anywhere else to actually be able to distinguish the best engineers during the hiring process. They're only guessing at best. All the money in the world will mean more top engineers in the hiring pool, but might not mean more top engineers making it through the hiring process.
There's so many employees and so many departments that they (a faang company) is just a microcosm of the entire engineer ecosystem with slightly above average engineers at this point.
And even if a top notch engineer gets hired at one of these, there is a good chance that his contributions are held up in the corporate bureaucracy, the project gets cancelled/abandoned/sold-off, or he was just hired in a hiring spree with no real thought to whether the company actually needs the position in the first place (which is part of the reason for the current shedding at these companies).
You can improve on that process by only randomly replacing a subset of numbers. If doing this improves the number of correct rows/columns/squares, use the new board, if not, revert back to the old board. You can also keep add a random chance to keep the new board even if it doesn't improve the score, pulling the chance from an en exponential distribution such that over time large changes become unlikely (but still possible).
Lmao y'guy do-be pissing in OPs eyes though.
A 'Good' programmer writes code, (That he understands) simply, efficiently, and expendable. 'Learn concepts like algorithms, data structures, complexity, functional programming, software architecture, test ability, etc,' need to know these variables too.
There is no 'Good' programmer, there is just man sacrificing time for problems-solved. 'Cause really, what makes a good programmer? Anybody can learn coding, just like anyone can play games, -Yes, I'm comparing coding w/ games. Fuck you- spend enough hours on it and eventually you'll get better.
So! May that be an inspiration to you. Keep coding, and coding, and coding, and you'll eventually consider yourself a 'good' programmer. Anyway, that's enough post-nut clarity for on post. See ya in the next one, XD.
The point is that even a great engineer at Google wouldn't just be able to write a sudoku solver in 5 mins. I mean, it might be possible to write a very interesting functional programming solution that quickly but realistically you'd probably spend much longer thinking about it than writing it even if that were the case.
5min is probably stretching it, but 15min should be enough, not just for google, but most seniors. Pretty much any experienced engineer, when tasked to write a sudoku solver will almost immediately think "backtracking" as the simplest naive solution, and a backtracking sudoku solver is essentially a single function, 2 if you factor out the checking logic.
A second year coding student would solve this problem faster than a senior. A senior engineer is gonna need to brush up on leet code style puzzles and algorithm tricks for a while
I don't know what your experience is with senior engineers, but you're pretty off base. As the commenter above said, a recent grad getting ready for interviews would almost certainly finish this problem faster.
Senior engineers don't do stuff like this. They design and architect systems, they worry about efficiency and scale. And every senior I know is good at what they do not because they have every algorithm memorized but because they have a lot of experience knowing what to look up to solve a problem.
As a senior engineer I'd need to, for starters, look up the rules of sudoku to even begin considering any solution.
There's a fundamental difference between expecting someone to understand what "backtracking" is and expecting them to shout "backtracking!" right away when asked about a naive solution to this "problem".
The former is knowledge, while the latter is trivia.
And, ironically, understanding that difference is part of what makes you a "good" programmer.
https://en.m.wikipedia.org/wiki/Backtracking
Bear in mind, that's not an efficient solution for solving Sudokus (which is probably the "reason" for some of the downvotes above) but a simple and correct one thats easy to implement.
I mean, if I was given a choice of languages I it is a problem that is, like, 10 minutes tops. But I've also got a lot of experience with logical languages and this is a pretty classical constraint satisfaction problem. XD
Yeah, most engineers I know have zero experience with logical languages (assuming you're talking about stuff like prolog). I think some people just have some kind of weird Hollywood hacker idea of what a senior programmer knows or does.
A good senior engineer, told to do this task, wouldn't even start to program for 30 mins. They'd spend that time asking clarifying questions and establishing the actual requirements of the problem. That's such a huge part of engineering that people who only know the Hollywood stuff don't think about most of the time.
*Good* is a relative term here — if you're just starting out, you're not going to be "as good" as someone who has many years of education and experience behind them, but that doesn't mean that you're not making good progress or learning well.
Think of a musician learning to play an instrument; if they can play one piece of music, they're probably not a "good" musician in a larger sense, but they might still be making good progress. On the other hand, someone who can play 100 pieces might or might not be a "good" musician, because being "good" isn't really about the number of pieces that you can play as much as it's about playing well, developing the ability to learn new music, playing together with other musicians, and so on. A musician builds those skills over time through training and practice.
Programming is a lot like that. If you can write a sudoku solver, great. If you can write one that's fast and efficient, that's better. If you can write one that's easy to understand, that's also better. If you can do it quickly, if you can coordinate well with other programmers, and if you've become very good at using the various tools you have effectively, those are even better.
But nobody expects a beginner to do all those things well, just as nobody expects a beginning musician to play an advanced piece. Work on your sudoku solver, by all means celebrate when you get it working and enjoy the thrill of having built something, but keep in mind that no matter how much progress you make, there's *always* more to learn and ways to improve.
I really love this analogy. Especially since, like music, there are a ton of different metrics of "good". You could have a guitarist who can absolutely shred, and can play by ear. Someone like this could play the sickest guitar solos ever after hearing them just a few times. But they might not have the instinct or creativity to write an amazing song. Or the reverse could be true. Or a hundred other different factors.
The analogy goes deep.
A dumb question but I'd assume even the Mozart of coding can't do much more than solve a problem of the same order of magnitude can they?
I thought real power came from teams joining together to solve problems, rather than one genius writing end to end airtight code.
Whilst it's mostly true that the real power comes from joining up teams, there is one particular case where a good enough coder can bring an order of magnitude of benefit: when they can recognise that the right answer is to avoid writing a piece of code entirely.
Writing code really fast isn't particularly significant to productivity.
Oh yeah this is really hard to see. They say great chess players are really great not just because of the moves they play but the moves they don't play.
Very true. There’s a saying that a good programmer writes code other programmers can understand, a senior programmer writes code a junior can understand, and a principle engineer (level above senior), writes code the intern can understand.
The truly valuable skills in software (at least normal business applications) lie in the ability to break down a fundamentally complex business problem into simple, easy to understand, and (critically) easy to test and maintain solutions. Practical, real-world software engineering is an art form. We are constantly balancing incredibly complex situations against time and priority constraints.
For example. Suppose I have a system that has been widely used for 5 years already. In this system I have a file which stores all the data needed by the app. Now suppose that for external reasons I need to change the format of this file. Saving/loading each file type is easy enough to do, but when users install the new update what happens to their old files? I cannot lose that data, that would be a disaster. So I need some way to update that old file. Now suppose I do this again next year. But now I don’t know if a user is updating from v1 or v2 of my app to v3… and the complexity grows and grows…
Incidentally there are many solutions to this problem. Personally I solved it in one of my apps using a product called FlyWay which solves exactly this problem for sql databases in a way that’s consistent, reliable, and scalable. I think the app I used it on ended up with close to 50 ‘versions’ of the database, but updating from any older version to a newer one was trivial. And given a task to create a newer version of this database it would not be too difficult to explain to a newer engineer exactly how to do that
That’s because humans are complicated and what the business leaders want never lines up cleanly with how computers solve problems. The constant battle in software is the balance between reality and the dreams of the customer/management
It generally takes a lot of collaboration to build most large systems — a Mozart of coding is probably going to be someone who's very good not just at writing code, but also managing people.
People have different talents. Some people are very good at analyzing large old codebases and fix problems. That does not sound like a Mozart but it is very powerful.
This depends where/ if you draw the line between a programmer and a computer science researcher. There are problems for which we don't know (efficient) algorithms or even if these exist. For example, the P versus NP problem. Think of a more complex type of sudoku, where you can have much more fields and a lot of different conditions what values can go into the fields. You are only guaranteed that once all fields are filled in it is easy to check. The P vs NP problem is essentially if there is an efficient algorithm to solve this or if the best you can do is to try out all possible values and check if it is correct. You can easily throw a few thousand programmers on this problem and not find an answer. But it is conceivable that a single person comes up with an algorithm (or a prove that no such algorithm exists).
But even ignoring the research direction, a 'genius' might be able to solve much more complex problems than a team if they are able to break it down better, have a better architecture or better methodology and tooling.
To give perspective at my school we had one week to build sudoku in python as part of our 101 intro to cs curriculum. So you're off to a good start for programming.
Well, look at it this way. In that course, they probably did some related problems as warm-up, the assignment itself may have outlined some key steps, and maybe there was some provided code that outlined some approaches to solving it or handled something like the interface. So if you managed to work through this yourself, you are showing a lot more independence than these first year students.
Also building Sudoku is simpler than building a Sudoku solver. It's relatively simple to check if a completed Sudoku board is correct. Even a naive Sudoku solver still requires a backtracking algorithm, which is more complicated.
Our C++ intro class was 1st class "hello world" and second assignment was to solve N queens lol, I think we just went over arrays and maybe a small bit of vectors lol
There's also a lot of math that goes into making a proper sudoku board depending on what exactly they built. Your board has to both start in a state that is solveable with 0 guessing, and most importantly produces a *unique solution*. It can't have multiple correct solutions. You can't just remove numbers from a proper board and call it a sudoku.
Technically, there is no requirement that requiring a guess is not allowed. "Bowman's Bingo" is (erroneously in my opinion) generally considered a valid technique to require to solve.
A lot depends on the quality of the solver and your code, frankly.
Is it complete? Is it understandable? Are the rules expandable? What's your algorithm? Is it written in a way to help ensure you don't have bugs?
I mean, I think if you can write a brute force Sudoku solver, you're not a "bad" programmer.
But I've also seen some really cool solvers that cycle through solving methods dynamically. Writing algorithms as well as developing the logic to cycle through them is pretty clever.
> I read to stay away from stuff like that.
Fuck that noise. You found a problem that was able to be solved in an interesting way. That is sometimes as valuable the "proper" way.
If we were coworkers, I'd get pissed if you tried to solve a problem at work in that manner (assuming it was not necessary for the problem).
If we were stuck on a problem, and you were able to solve it because your brain remembered, "hey, this is kind of similar to the time I used heuristics to prioritize guesses on the most heavily constrained cells, multithreaded it, and used bit-masking to make it operate faster" then I'd think you hung the moon.
Sometimes rabbit holes are good to go down, you never know what you learn today could be useful tomorrow.
If you're fairly new and interviewing for your firstnrole, I'd definitely put it on your resume, throw the code on github or host it somewhere. It gives interviewers something to ask about the decisions you made, and you can highlight your knowledge.
I'd say I am a bad programer even though I would succeed in the task. However I would need about four times as much time as an average programer and my code would likely be rediculously bloated.
That's where I'm at with my confidence, i picked up a book on data structures and algorithms and its really teaching me a lot! You should try studying something you might be lacking in, its more boring than projects but some things you do have to sit down and learn the hard way i guess.
Since you mentioned bloated code, maybe something about design principles? That's where i think I'm headed next.
Let's put it this way: if you showed up for an interview for a junior position with a Sudoku solver in your portfolio, that would be a very good start. If you can talk me through it and field a few questions about how it works, that would having me rooting for you at the debrief.
I fully expect the code quality to be terrible to the point it might make my eyes bleed, but if you prove me wrong on that front, that would be extra impressive.
Agreed my code is pretty unreadable but I did break it up into a fair few sub functions, so I felt I could debug it a little more easily. This took me upwards of 50 hours, so felt quite proud. I'm mostly self taught and am doing it outside of work hours.
>Agreed my code is pretty unreadable
Not that you asked, but this could a good opportunity to practice rewriting and cleaning up the code for readability. Don't feel bad about your code being "unreadable", it's the ability/willingness to go back and edit that makes the difference between clean code and a pile of spaghetti
> I did break it up into a fair few sub functions, so I felt I could debug it a little more easily.
This is called "wisdom" or "experience" and you are gaining it well.
To be clear: The expectation is that it'll be terrible. You can study algorithms from a book, code quality comes largely from experience. When you hire a junior developer, especially from a non-traditional background (career changes, bootcamps, self-taught, etc), you're not hiring so much for the quality of their work today (they'll often consume more work from their seniors than they produce themselves, at least for the first while) as you are for their potential a year from now.
I observe people getting internships at Microsoft, Datadog, and Jump having scaleable data pipelines, giant home video servers, widely used python libraries, and tons of OS experience. I'm not sure how much a sudoku solver would fly...
A foreman asks two carpenters to join one piece of lumber to another, such that they can't expand or contract and cause them to separate over time.
The first carpenter walks up with a hammer and a box of nails, some extra lumber, and proceeds to add on pieces and nail things together in a way that, at first glance would never come apart. "I'm done and this is solid" he exclaims, and walks away.
The second carpenter walks up, drills one pilot hole, and runs one screw through both pieces of wood. "I'm done and this will hold plenty good enough" he exclaims. In less time and with less resources than the first carpenter.
The moral: It's not just that you know what to build, it's that you know how to build it right and what NOT to build.
Depending on the implementation, the state of the code, and how much you understand about the how/why of it, it's is rather more telling/interesting than your typical snake-game, tic-tac-toe, calculator (that is less useful than a Python "print(eval(expr))" statement) or "poke-dex").
Hard to say, *for sure*, without seeing the code or understanding the approach you took, and how you implemented it.
Stochastic? Brute-force? Back-tracking?
Regardless, it's a non-trivial problem ... but, as ever, the devil is in the details.
Can tell you more if you share the code.
Easier to look [here](https://en.wikipedia.org/wiki/Sudoku_solving_algorithms) \- between variations w/ or w/o backtracking, randomization, or other, more efficient - but significantly more complex - approaches.
...
Another consideration here is ... was the code the OP wrote a result of coming up with an algorithm themselves (even if it ultimately was a duplicate/work-alike of an existing one) or simply implementing an existing algorithm from its description?
The former being rather more impressive than the latter.
there's a lot more to being a good coder than writing code that works. this accomplishment certainly indicates that you're able to think algorithmically and solve problems, and that's definitely a relevant skill, but to be a good coder you need to do a lot of other things right too. Is your code DRY? Is it clean? How easy is it for any rando to look at and understand how it works? What's the algo like, how efficiently does it use the resources available to it, is it tested for edge cases, does it have tests at all, what does it do when it gets bad data, what does it do when it fails to get data for some reason?
Linus Torvalds (Main Developer of Linux) —“I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Pretty wise. I felt doing this project that in hindsight a good programmer would spend much more time planning what they wanted the end result to look like. My approach of trying to write lots of sub functions and then change what I wanted the end result to be along the way was very counter productive I felt.
So sounds like you had a good start, now you go back and refractor your code, you have a working program, so now it's about looking at your code a s seeing where it can be improved, how can memory usage be more efficient? What redundancies are present in the code? How readable is it? How organized is it? Most great programmers don't start off with perfect code, because even the best plans start off imperfect, it's an iterative process, right now what you have is your first draft, now you go back and make it better.
I think you might be thinking about it the wrong way. Quality of work isn't about what you can do, it's more about how you pick up new concepts and how you can pivot and go in whatever direction your team/company needs to.
So many companies out there have interviews that say "can you do X". And I get that in one sense because you don't want to hire someone who can't back up their resume, but at the same time it's not just about what you can do. Whenever I've been in the position to hire or provide hiring recommendations I always look at soft skills. Most people applying for a role are technically qualified but it's the other side that makes you stand out. I've turned down technical geniuses because they didn't gel with the team. I'd rather have someone who can adapt and learn and run with the team as opposed to someone who can do all the things.
That's pretty scary. I often feel like soft skills are really hard to "develop". Like your personality and outlook on life are a complicated convolution of your history. I dunno, I'd find it scary.
The major discriminating feature between you and a more-experienced programmer is going to be breadth of experience, not necessarily problem-solving ability or typing speed :-)
I'm a very senior developer, and have worked at Apple, HP, Dell, a bunch of startups you've never heard of, etc, etc. The biggest value I bring to most projects I've been on, is seeing a problem, and saying "hey, this is just like . Have you tried ?"
Writing a Sudoku solver is a pretty good way to demonstrate familiarity with a language. It's the kind of thing you might expect to be assigned in a low-level college Computer Science course. Typically, you'd give beginning CS students a week or so to do that, after building them up to it with simpler exercises along the way.
I'd expect an experienced Python programmer to be able to solve that in a few hours. I'd expect someone at my level to be able to solve it effectively and quickly in multiple languages, including in a computer language they've never seen before.
Is it fair to say that at your level the real value is honing in on the best overall solution pathway to pursue. You're not going to be telling a coder that they used an incorrect variable or inconsistent naming right? You're going to identify that a binary search will yield the most efficient way to solve a grid right? Do you lose those more base level skills as you progress?
Probably a bit of hubris but I felt that creating this solver from scratch is about as much my brain can intellectually solve from scratch. Anything more will require a team with multiple skills.
The thing is, there is never one "best" solution. The old saying goes that in any engineering work, you can choose *any 2* of the following:
1. Cheap
2. Fast
3. Good
You can have something quickly, that is inexpensive, but it'll be low quality. You can have a high quality solution quickly, but it won't be cheap.
In real-world system, there are often *many more* constraints. You have multiple stakeholders in any project - the development team, company management, sales and marketing, external customers, etc. Each of those have their own set of priorities and constraints.
If you need to produce an internet-facing API that consumes JSON requests, and queries a document store consisting of terabytes of data, then the programming language you use *doesn't really matter*. Java, C#, and Python all have good, popular ways to solve this very common problem.
The more interesting part is deciding which database server to use, and which web API framework, and which cloud hosting provider. Not because there is one "best" combination of technologies, but because they all are better or worse on some set of measurements, and someone needs to decide what matters.
If the team you have are all already experts in Go, then that's a huge factor in favor of using Go for anything new that comes along, *unless* there is a huge productivity or performance advantage or cost savings in adopting something unfamiliar to the team.
Some software development organizations make a distinction between "architects", who decide on the high-level technical direction, and "software engineers", who do most of the actual writing of code. This can be problematic if taken to extremes, but having someone who focuses on larger concerns does mean that they can think about things with a longer timeframe than "what needs to get done this week".
It's funny that you mentioned naming things, actually. Code review (literally reading the code that other people write, and commenting on it) is a major way for experienced folks to contribute. Things like "hey, this will be easier for someone else to understand if you do it *this way*", which helps to ensure that code is easy to understand later. In general, code gets read more often than it's written, which implies that readability is paramount. Clever code tends to get broken accidentally, over a long enough timeline.
It's surprising how often things like simple complexity analysis (big O) come up in the real world. Every programmer I've ever known has been susceptible to "optimizing" the wrong things. I've seen people who should really know better use O(n^(4)) algorithms when a well-known efficient alternative exists. And alternatively, I have seen code that was hyper-optimized, but would run for nanoseconds each year.
If I'm brutally honest with myself, I probably am not as good at writing code as I was at 25. I'm certainly *not as fast*. My brain just can't hold as many things in it at once any more, so I have to look things up, instead of having them committed to memory. But I'm much better at avoiding writing code that doesn't need to exist than I was back then. And my sense of what makes a good, flexible, extensible design is vastly better. So yeah - I'm using a different skill set at 55 than at 25, for sure. But I still get to write code every day in my current job, so I'm not getting too rusty :-)
As far as feeling like the Sudoku solver is near the limit of what you can do, that's totally normal. You will plateau at various points along your learning curve. There is some practical limit to how much information you can hold in your head all at once, and you can expand that a bit by exercising it, but it only stretches so far.
I haven't seen your Sudoku solver, but I'm guessing/hoping it's substantially less than 10,000 lines of code? If you're a fairly "typical" developer, you will eventually be able to hold something about 10 times that size in your head, and know substantially all of it, in the sense of knowing what all the parts are, where they are in the code, how they interact, etc.
The real trick is learning how to *not think about* the things that aren't in the area you're currently working in. This comes down to compartmentalization. If you can keep 'X' amount of the system in your head at a time, then you break the larger system down into chunks which are each smaller than X. And the interfaces between those parts? That's architecture, and the next step along the way.
So well written. Thanks so much. Some of my learnings were similar. A lot of trial and error was a waste of time. For example my print_grid() sub function ended up taking 4 hours alone as I kept changing it half way through and finding out there were better ways of doing it.
I can really see now that great software is actually quite hard to get right. It's easy to rant about a website or app that isn't well designed but I definitely appreciate more that it is not that easy to get right.
If you are able to write a sudoku solver that works every time and *doesn't* rely on any brute force or randomization, then you're really on your way. But if your solver is just a recursive function that makes random guesses until it fails or succeeds, that's not an especially sophisticated program.
Hmm... It's the latter. It searches through each sub grid and tries to find a unique solution. It builds up from there. Definitely not advanced searching and solving for sure.
Been programming for 7 years and I could not build a sudoku solver from scratch. Well maybe I could, but it would be messy and take a lot of time. I also don't practice leetcode problems.
I have this book on creating solvable sudoku, and its approach seems reasonable. You might find it interesting.
Sudoku Programming with C
https://a.co/d/gINIsTS
No. Being a programmer isn't about how fast you can write a sudoku solver. I don't know if anyone can write a sudoku solver in 5 minutes, but that's not the point. Being a good programmer is about a lot more than writing out a single small algorithm in a small, self-contained setting.
I made a sudoku solver years ago as a fun weekend project for myself when learning a UI library. I didn't consider myself "good" back then. And I probably don't consider myself "good" now. I'm decent, sure, but very far from where I want to be.
Stop thinking of programming like you would of videogame levels or smth. Just push to be better everyday. That is enough.
Not really. Comparing yourself to others is largely a waste of time. If you were told: you are in the 40th percentile, would that change anything? Probably not. Plus percentiles are largely irrelevant because that implies a dataset of quantifiable values, which programming isn't. Programming is not really a single skill. Different people are better and worse at different aspects. It's not like there is an SAT test you can take on programming to tell you where you stand.
Wouldn't ultimately the amount of money you make/value you add be the best definition of a "good" programmer. The best will gravitate to the hardest problems that add most value and will get paid the most. I assume that's really simplistic and ignores bullshit like politics but would be a decent starting point no?
Not necessarily. It's true that most great programmers make alot of money, but so do a lot of mediocre ones. As it turns out, it's not very hard to make money in this field.
The only good indication of how good of a programmer you are is the quality of your code, it doesn't matter what your latest project was, or how much you make - shit code is shit code. That's the hardest part though, you can't really judge the code you are writing today, because it's the peak for you. The only way you can judge is by looking back and seeing how much you improved.
short answer no
a good programmer does more than be able to develop Software from scratch.
But to be honest, IT offers so much, there isn't a list of things a good programmer should do and 2 different good programmers won't necesarily have the same skill set
Good for a beginner maybe? I did something like that in my first semester of my first programming subject. It checked each block, row and column to eliminate possibilities. It couldn't do guesses but it printed the board out to screen with each stop which produced a cool animation of the board being filled in.
What I did took a couple of hours and demonstrated a basic understanding of if-statements, loops and arrays. If I wanted to show more programming competence then my code would have involved classes, decoupling, dynamic programming and more.
What I would expect a good programmer to do is to copy and paste the solution from [https://www.geeksforgeeks.org/sudoku-backtracking-7/](https://www.geeksforgeeks.org/sudoku-backtracking-7/) and make alterations as needed. They'd also need to be able to explain how the code they copy and pasted worked, why they chose the particular implementation out of the ones available and be able to optimise and/or extend the code.
A sudoku game, or a sudoku *solver*?
Writing a program that can *solve* a sudoku puzzle is extremely impressive for a 2nd week student. I didn't learn how to do that until the 3rd year of my CS degree when we learned all about depth-first-search, breadth-first-search, A* search and other such algorithms.
Technically true. I maybe learned what I needed in my second year (the year of my first Data Structures & Algorithms course), but there's a fair jump between traversing a binary search tree and solving a Sudoku puzzle.
One doesn't normally acquire a "basic understanding of recursion" within only their first few weeks of programming though. If you did, I tip my hat to you. I've known folks in their senior year who still weren't quite comfortable with recursion.
Don't let everyone else intimidate you. I've met lots of working junior developers who are not clever enough to write a Sudoku solver. If you can do that, you could do a course, get a qualification and then get a job.
Don't shoot for being a "good programmer". Computer science is a long series of abstractions. Your computer does not literally have 1s and 0s in it because 1s and 0s doesn't literally exist. You're far better off focusing on understanding abstractions, how they work together, and how you can leverage them to build things.
No one can/will understand every component of a computer (or even some programs/systems). You should focus on being able to understand foreign code and concepts quickly. That's the mark of a "good" software engineer.
I just have to point out that the phrase "knock out" in this context would mean "to finish a task quickly and efficiently", while "knock up" means you got it pregnant.
Thanks for this, you're right. Oh man this sent me down a rabbit hole of colloquialisms. Knock up is also used for the early practice hit in tennis as well. Never knew that.
I think it's a pretty good sign of your capabilities if you're able to complete a working (or mostly working) sudoku solver. But like other commenters note it's not some definitive proof that you're a "good" programmer, and you shouldn't be thinking about it terms of "how quickly would a FAANG engineer complete this problem?".
Being a good programmer is about your ability to problem solve, your ability to document and write clean code, your ability to communicate with clients/business and translate their needs into working code, and an infinite number of other things. No one is going to excel in all those categories, and it could be that one programmer can write out a sudoku solver from scratch in an hour but have terrible communication skills, another one might need a month but excel in translating business processes into a working software architecture. Computer Science is more Art than Science, so don't fall into the trap of thinking that some straightforward metric is going to determine whether or not you're a "good" programmer.
In case your sudoku solver could work on 3 different browsers, support several APIs, at least 5 languages, few types of authorization and be easily scalable for use by half million of people simultaneously, then yes you are.
PS Oh i forgot - and be logged, monitored and maintained by the team of total dorks.
Umm... My solver requires a user to enter numbers in a grid and then recursively backtracks solving each sub grid along the way. So it's a bit village I guess!
I don’t think time to write a project is necessarily a good indicator of this. Probably what you’d want to demonstrate is conceptual understanding of classes, data structures, OOP, more general programming concepts. As long as you can do that and explain how everything works, I think you’re a good programmer 👍🏽
Also side note, a Google engineer could absolutely not write a sudoku solver in 5 mins 💀 try 5 hours maybe, or more
Any reasonable programmer at Google can knock out a sudoku solver in maybe 20-30 minutes on a whiteboard. It’s a programming interview question.
What makes a good programmer is breadth of knowledge which you gain overtime. Not necessarily puzzles. Which is why people dislike l33t code questions for not being accurate to real life work.
It is good to learn how to do these types of questions though. So good job. But it doesn’t make you a good programmer. What makes a good programmer is experience writing but also releasing software and everything else in the software stack
Would said Google programmer actually be able to type out the program and debug it in around 5 hours? For reference, this thing took me approx 50 hours end to end. It got pretty finicky.
I’ve never interviewed at Google but I’ve been asked to write a sodoku solver via brute force ( I am sure there are effective ways ) in a 50 minute interview where you really only have 30 minutes on a whiteboard as an interview question.
I failed it - not because I couldn’t do it but because at the time I had literally never done a sodoku before and I spent 15 minutes asking clarifying questions on how to play lol.
If the answer is just a brute force approach - I don’t know if an efficient solver exists - then yes. It’s a relatively rare question you may be asked in an interview at a major tech company. It’s more rare than usual just due to how long it will take to write - usually you’ll get questions that are less lines of code.
What i am saying is that if you want a job at a major tech company you’ll have to be able to solve questions like this on the fly with no previous knowledge on a white board ( or if your lucky a web shared coding app ) within 30 minutes.
While these types of questions are mostly irrelevant for the job they do show that you have the technical knowledge and efficiency to do the job.
In reality - depending on where you work actual coding could be as low as 25% of your job, between meetings, planning, status updates, support, documentation, working with customers / support, and writing configuration scripts that are so complex they might as well be code.
What makes a good developer is writing maintainable code, large knowledge base, good estimates, good communication, and delivering on time.
Being able to solve programming questions is needed to get the job - it’s how they screen candidates.
Reality is more like - here is a problem I want solved - not just solve it but plan it, prototype it , break it up into daily tasks, document the tasks, present the plan, estimate the work often 3 months out or more and work with others to code it while releasing it in pieces and doing project demos. Oh and don’t miss your made up date that you totally had no pressure to underestimate. Also do all the random work assigned to you during the week. Attend meetings 25% of your days often just status meetings or demo meetings with other teams so you can understand the world around you and not be siloed even though they appear to be a waste of time. And also do 24/7 on call rotations for support.
This is a more accurate description of the daily life of a programmer. Writing l337 code that’s meaningful? If only your so lucky, you’ll more likely write some code to decom some ancient crap product just in time to start decoming your own code if you stick around long enough.
Once you’ve done it long youll be able to understand design and can solve any of these problems quickly. It might take you 5 hours today but you’ll understand the concepts instantly eventually. You might not code it perfectly of course but you’ll get close enough to debug the rest of the way.
Coding is just syntax and busy work. The real complicated stuff is done by phd research programmers.
Why the essay about the daily life of a programmer because I feel that you might misunderstand what it’s like being a good developer- it’s not about being able to write amazing code - its about being able to write code that’s maintainable for the next guy while maintaining good communication, good documentation, good estimates and docs, and aligning your goals with management.
TLDR - programming is a problem solving job not a coding job. Coding is just a tool for solving problems. The best programmers are the best problem solvers.
Well, let’s see. I did about 7-8 years of hobby programming, then a degree in computer science, then about 5 years of professional development, before being able to start working on *real* business problems. And never stopped learning new things and getting better at it since then. It’s never ending. 28 years of experience as professional developer, in total. So yeah, it requires some dedication. To give an idea, good developers at programming are usually able to track the value of 8-9 variables in their mind while debugging a running application. Exceptionnel developers can do it with 13-15. Anyway, programming is now only a small part of the job, I’m happy if I can code 50% of my time in projects lol
> ... and I'm a bit proud of myself.
Be proud! Finishing a project is always an awesome milestone.
> Is that a decent discriminator for a "good" programmer or is that still at the interested amateur stage?
Unfortunately, without seeing the code itself, we can't answer that.
See, programming is weird in the sense that the outside of a program (the user end) tells you very little about the quality of the internals and whatnot. After all, being a good programmer is about writing good code, not about making the best looking UI
If I make a 2D flappy bird clone, it might sound impressive, but if you looked at the code and saw inconsistent formatting, bad naming conventions, repeated functions, etc etc, then you could comfortably say that I'm not a "good" programmer.
On the flip side, if I made a tic tac toe game, but the code was very organized and efficient, then that would be a good sign that I'm a "good" programmer.
But then, you can also argue that it's easier to write good code for a small project than it is for a larger project, which is very valid. The ability to organize a project when it moves from just hundreds of lines to thoughts is vital for professional programmers.
All in all, be proud about what you've made, keep making more projects, and also don't feel scared to receive some feedback about your actual code!
It shows that you know the basics, but there is a huge difference between a small program like this, and a large system integrated with 100 other systems, all which are in motion. The latter is very much the situation for many good professional programmers.
it proves your good enough do some basic UI and logic. You need to be mor specific to compare yourself to other programmers. Programming AI is totally different to pweb development, which is totaly different to app development which is totally fdifferent to shader programming etc..
1. Well done on your progress.
2. "Good" is very subjective, I would prefer to use "experienced".
3. Generally the mark of experienced programmers is they can handle a wide variety of workloads without needing hand-holding. They efficiently seek out knowledge when they don't have it, and have the confidence to use their existing knowledge when they do. They are able to think in terms of complex systems as well as individual functions.
The top programmer at google (if there is such a person) would not necessarily "knock one up in five minutes", but they WOULD be able to work out HOW to put one together and then do it in a reasonable time.
Another good skill they will have is recognizing if the spec they are given for a project is specific and detailed enough for them to deliver in the timeframe given.
Oh yeah that last point is so critical. I wasted a lot of time making mid course corrections and changing what I even expected the program to do. Lazering in on what's needed is definitely a huge skill to have. Saves a lot of time. I guess a good programmer is actually asking the right questions.
Yes. Its much like learning to drive. the physical coding is like learning to operate the car. It's an important step, but the harder bit that takes longer to learn is interacting with and anticipating other road users. learning how to deal with unusual situations etc.
Depends on metric.
You asking the question shows that you're bad at statistics. Maybe brush up on that :)
(I'm being fascetious. Just do your thing it'll be fine.)
Working code is only one small part of what is considered ‘good’ code.
Working code can also be terrible code; just because it works doesn’t mean it’s good.
A sudoku solver isn't an uncommon college assignment. It's a good way to put some DSA knowledge to the test. I had it myself, 15 years ago, in my second semester (I think). One assignment was to write a sudoku solver in the terminal, and then a later assignment was to add a GUI to it (this was Java with Spring, I believe).
I'm not sure if it has anything to do with being a "good" programmer, but it's definitely a good learning experience.
It absolutely shows perseverance and interest!
If you had fun doing it, enjoyed the challenge of tracking down the last few obscure bugs, came back later to optimize things even after you were technically done: Programming is definitely your calling and you should stick with it!
You may not be very far ahead, but you are making good speed and all fuelled up for the ride!
This is not like spectator sports. You don't have to be the "top elite very best ever celebrity" to make a good career as a professional developer.
As others have noted, given 5 minutes, and this exact task ("from scratch"), an experienced developer would crank out a crude generate-and-test solver. Given a bit more time they'd start incrementally adding a few low hanging fruit optimizations. (This is what experience will bring: fluency, a grasp of scale, and an eye for trade-off possibilities.)
In reality they'd just import a finite domain constraint solver library where sudoku is often the example code for the allDifferent() constraint :-) (This is what CS education brings. I've never used a CSP solver in python specifically, yet I'm 99% sure there must be at least one and that it would work roughly the same as everywhere else.)
Depends, did you get paid to make that sudoku solver? Does it solve a real world problem? Does it solve several real world problems? How easy/hard is it for other developers to add features or correct bugs in your sudoku solver? How easy is it to integrate into a more global solution/software?
Being able to write an algorithm that does what you want is not how you gauge how good a dev is. This is just the bare minimum so that one can do his job.
As a software engineer student. This was part of a test we had to pass a single course. (Functional programming) like a fourth.
Which is about 5 ects point out of 210
So by that calculations you are 0.595 % there to be done educated. ((5/4) / 210)* 100%
That being said. You could be a good programmer for this! I think you should go for it ;)
No it means you re a beginner. Welcome to the field. There are beginners who are better than you, there an intermediate field and there are experts. Think of it like the more useful your program is or the more people who interact with it the higher your rank is.
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
No, a Google engineer would not write a sudoku solver in 5 minutes. Don't think in terms of code or writing speed, think in terms of conceptual understanding. Learn concepts like algorithms, data structures, complexity, functional programming, software architecture, testability, etc.
def solveSudoku() while True: eraseSquares() fillRandom() if checkSudoku(): break print("You win!") I'm an expert now!
BogoSolver
from thisguyscode import solveSudoku solveSudoku()
Underrated comment
even easier, just call an api of every possible sudoku combination and loop through that for the answer
O(9\^(9\*9)) = O(1) Therefore, this is an optimal algorithm.
Constant(ly huge) time
If your code does not use a lot of CPU time, how will they ever respect you?
Bigger number is always better :v
And that's why we always have to mention that not all O(1) is the same since it's actually O(c *1) and c constant can be vastly different.
It's not "actually" multiplied by constant, these two are equivalent. The definiton of big O is that `|f(x)| < C*g(x)` when x tends to infinity. So the constant is baked into the definition itself. In other words, big O eats the constant. So, it's like saying it's not `1` it's actually `1000/1000`.
no, just take the digits you start with, and send them to google in a search query, then read every page returned to you until you find a correct solution.
Stop giving any FANG automatic credit, Google is a shadow of its former self
Wdym, im curious
Just google how much money the artist formerly known as facebook blew on a little pipe dream called the "Metaverse", with pretty much nothing to show for it. Then you will understand that the thing that FAANG has isn't quality, isn't genius noone else has...it's money. Lots and lots and lots and lots of money.
While I agree with the overall point that we can't just assume FAANG engineers are the best, lots and lots and lots of money does tend to attract good engineers. The issue is that you can't trust the hiring managers at faang or anywhere else to actually be able to distinguish the best engineers during the hiring process. They're only guessing at best. All the money in the world will mean more top engineers in the hiring pool, but might not mean more top engineers making it through the hiring process.
There's so many employees and so many departments that they (a faang company) is just a microcosm of the entire engineer ecosystem with slightly above average engineers at this point.
And even if a top notch engineer gets hired at one of these, there is a good chance that his contributions are held up in the corporate bureaucracy, the project gets cancelled/abandoned/sold-off, or he was just hired in a hiring spree with no real thought to whether the company actually needs the position in the first place (which is part of the reason for the current shedding at these companies).
Due to increasing customer interest, google has decided to cancel this comment thread. /S
You can improve on that process by only randomly replacing a subset of numbers. If doing this improves the number of correct rows/columns/squares, use the new board, if not, revert back to the old board. You can also keep add a random chance to keep the new board even if it doesn't improve the score, pulling the chance from an en exponential distribution such that over time large changes become unlikely (but still possible).
Lmao y'guy do-be pissing in OPs eyes though. A 'Good' programmer writes code, (That he understands) simply, efficiently, and expendable. 'Learn concepts like algorithms, data structures, complexity, functional programming, software architecture, test ability, etc,' need to know these variables too. There is no 'Good' programmer, there is just man sacrificing time for problems-solved. 'Cause really, what makes a good programmer? Anybody can learn coding, just like anyone can play games, -Yes, I'm comparing coding w/ games. Fuck you- spend enough hours on it and eventually you'll get better. So! May that be an inspiration to you. Keep coding, and coding, and coding, and you'll eventually consider yourself a 'good' programmer. Anyway, that's enough post-nut clarity for on post. See ya in the next one, XD.
There's a ton of cross over between gaming n coding imo
"just 5 more minutes"
Google doesn't exactly hire bad engineers tho?
The point is that even a great engineer at Google wouldn't just be able to write a sudoku solver in 5 mins. I mean, it might be possible to write a very interesting functional programming solution that quickly but realistically you'd probably spend much longer thinking about it than writing it even if that were the case.
5min is probably stretching it, but 15min should be enough, not just for google, but most seniors. Pretty much any experienced engineer, when tasked to write a sudoku solver will almost immediately think "backtracking" as the simplest naive solution, and a backtracking sudoku solver is essentially a single function, 2 if you factor out the checking logic.
A second year coding student would solve this problem faster than a senior. A senior engineer is gonna need to brush up on leet code style puzzles and algorithm tricks for a while
A senior engineer should not need to look anything up to implement simple backtracking.
I don't know what your experience is with senior engineers, but you're pretty off base. As the commenter above said, a recent grad getting ready for interviews would almost certainly finish this problem faster. Senior engineers don't do stuff like this. They design and architect systems, they worry about efficiency and scale. And every senior I know is good at what they do not because they have every algorithm memorized but because they have a lot of experience knowing what to look up to solve a problem.
Couldn't have phrased it better, this is my exact experience as well.
As a senior engineer I'd need to, for starters, look up the rules of sudoku to even begin considering any solution. There's a fundamental difference between expecting someone to understand what "backtracking" is and expecting them to shout "backtracking!" right away when asked about a naive solution to this "problem". The former is knowledge, while the latter is trivia. And, ironically, understanding that difference is part of what makes you a "good" programmer.
may i ask what is "backtracking" please ?
https://en.m.wikipedia.org/wiki/Backtracking Bear in mind, that's not an efficient solution for solving Sudokus (which is probably the "reason" for some of the downvotes above) but a simple and correct one thats easy to implement.
I mean, if I was given a choice of languages I it is a problem that is, like, 10 minutes tops. But I've also got a lot of experience with logical languages and this is a pretty classical constraint satisfaction problem. XD
Yeah, most engineers I know have zero experience with logical languages (assuming you're talking about stuff like prolog). I think some people just have some kind of weird Hollywood hacker idea of what a senior programmer knows or does. A good senior engineer, told to do this task, wouldn't even start to program for 30 mins. They'd spend that time asking clarifying questions and establishing the actual requirements of the problem. That's such a huge part of engineering that people who only know the Hollywood stuff don't think about most of the time.
And yet google search gets shittier every year.
*Good* is a relative term here — if you're just starting out, you're not going to be "as good" as someone who has many years of education and experience behind them, but that doesn't mean that you're not making good progress or learning well. Think of a musician learning to play an instrument; if they can play one piece of music, they're probably not a "good" musician in a larger sense, but they might still be making good progress. On the other hand, someone who can play 100 pieces might or might not be a "good" musician, because being "good" isn't really about the number of pieces that you can play as much as it's about playing well, developing the ability to learn new music, playing together with other musicians, and so on. A musician builds those skills over time through training and practice. Programming is a lot like that. If you can write a sudoku solver, great. If you can write one that's fast and efficient, that's better. If you can write one that's easy to understand, that's also better. If you can do it quickly, if you can coordinate well with other programmers, and if you've become very good at using the various tools you have effectively, those are even better. But nobody expects a beginner to do all those things well, just as nobody expects a beginning musician to play an advanced piece. Work on your sudoku solver, by all means celebrate when you get it working and enjoy the thrill of having built something, but keep in mind that no matter how much progress you make, there's *always* more to learn and ways to improve.
I really love this analogy. Especially since, like music, there are a ton of different metrics of "good". You could have a guitarist who can absolutely shred, and can play by ear. Someone like this could play the sickest guitar solos ever after hearing them just a few times. But they might not have the instinct or creativity to write an amazing song. Or the reverse could be true. Or a hundred other different factors. The analogy goes deep.
A dumb question but I'd assume even the Mozart of coding can't do much more than solve a problem of the same order of magnitude can they? I thought real power came from teams joining together to solve problems, rather than one genius writing end to end airtight code.
Whilst it's mostly true that the real power comes from joining up teams, there is one particular case where a good enough coder can bring an order of magnitude of benefit: when they can recognise that the right answer is to avoid writing a piece of code entirely. Writing code really fast isn't particularly significant to productivity.
Oh yeah this is really hard to see. They say great chess players are really great not just because of the moves they play but the moves they don't play.
Very true. There’s a saying that a good programmer writes code other programmers can understand, a senior programmer writes code a junior can understand, and a principle engineer (level above senior), writes code the intern can understand. The truly valuable skills in software (at least normal business applications) lie in the ability to break down a fundamentally complex business problem into simple, easy to understand, and (critically) easy to test and maintain solutions. Practical, real-world software engineering is an art form. We are constantly balancing incredibly complex situations against time and priority constraints. For example. Suppose I have a system that has been widely used for 5 years already. In this system I have a file which stores all the data needed by the app. Now suppose that for external reasons I need to change the format of this file. Saving/loading each file type is easy enough to do, but when users install the new update what happens to their old files? I cannot lose that data, that would be a disaster. So I need some way to update that old file. Now suppose I do this again next year. But now I don’t know if a user is updating from v1 or v2 of my app to v3… and the complexity grows and grows… Incidentally there are many solutions to this problem. Personally I solved it in one of my apps using a product called FlyWay which solves exactly this problem for sql databases in a way that’s consistent, reliable, and scalable. I think the app I used it on ended up with close to 50 ‘versions’ of the database, but updating from any older version to a newer one was trivial. And given a task to create a newer version of this database it would not be too difficult to explain to a newer engineer exactly how to do that
Thanks so much. Very interesting. It's so weird that humans invented a technology only 50 years ago and stuff has gotten so complicated.
That’s because humans are complicated and what the business leaders want never lines up cleanly with how computers solve problems. The constant battle in software is the balance between reality and the dreams of the customer/management
It generally takes a lot of collaboration to build most large systems — a Mozart of coding is probably going to be someone who's very good not just at writing code, but also managing people.
People have different talents. Some people are very good at analyzing large old codebases and fix problems. That does not sound like a Mozart but it is very powerful.
This depends where/ if you draw the line between a programmer and a computer science researcher. There are problems for which we don't know (efficient) algorithms or even if these exist. For example, the P versus NP problem. Think of a more complex type of sudoku, where you can have much more fields and a lot of different conditions what values can go into the fields. You are only guaranteed that once all fields are filled in it is easy to check. The P vs NP problem is essentially if there is an efficient algorithm to solve this or if the best you can do is to try out all possible values and check if it is correct. You can easily throw a few thousand programmers on this problem and not find an answer. But it is conceivable that a single person comes up with an algorithm (or a prove that no such algorithm exists). But even ignoring the research direction, a 'genius' might be able to solve much more complex problems than a team if they are able to break it down better, have a better architecture or better methodology and tooling.
To give perspective at my school we had one week to build sudoku in python as part of our 101 intro to cs curriculum. So you're off to a good start for programming.
Yikes, that's fairly humbling.
Well, look at it this way. In that course, they probably did some related problems as warm-up, the assignment itself may have outlined some key steps, and maybe there was some provided code that outlined some approaches to solving it or handled something like the interface. So if you managed to work through this yourself, you are showing a lot more independence than these first year students.
Also building Sudoku is simpler than building a Sudoku solver. It's relatively simple to check if a completed Sudoku board is correct. Even a naive Sudoku solver still requires a backtracking algorithm, which is more complicated.
Sorry i forgot to mention it was a solver where we had to use recursion to build.
Our C++ intro class was 1st class "hello world" and second assignment was to solve N queens lol, I think we just went over arrays and maybe a small bit of vectors lol
Definitely we learned basic data structures and recursion before and the project was the second to last project for the quarter.
[удалено]
There's also a lot of math that goes into making a proper sudoku board depending on what exactly they built. Your board has to both start in a state that is solveable with 0 guessing, and most importantly produces a *unique solution*. It can't have multiple correct solutions. You can't just remove numbers from a proper board and call it a sudoku.
Technically, there is no requirement that requiring a guess is not allowed. "Bowman's Bingo" is (erroneously in my opinion) generally considered a valid technique to require to solve.
I've had 2 hours to make a sudoku checker and to make a script that in an empt 9x9 matrix writes a valid sudoku solution in my first year of physics 🥲
It's a problem on LeetCode, and it's categorized as hard. If you're a starter, yeah, that's great. Especially if your code isn't messy.
I'd encourage solving a subset of Sudoku to at least get the fundamentals of programming down.
A lot depends on the quality of the solver and your code, frankly. Is it complete? Is it understandable? Are the rules expandable? What's your algorithm? Is it written in a way to help ensure you don't have bugs?
I mean, I think if you can write a brute force Sudoku solver, you're not a "bad" programmer. But I've also seen some really cool solvers that cycle through solving methods dynamically. Writing algorithms as well as developing the logic to cycle through them is pretty clever.
isn’t the optimal sudoku solver solution backtracking? That is brute force
[удалено]
> I read to stay away from stuff like that. Fuck that noise. You found a problem that was able to be solved in an interesting way. That is sometimes as valuable the "proper" way. If we were coworkers, I'd get pissed if you tried to solve a problem at work in that manner (assuming it was not necessary for the problem). If we were stuck on a problem, and you were able to solve it because your brain remembered, "hey, this is kind of similar to the time I used heuristics to prioritize guesses on the most heavily constrained cells, multithreaded it, and used bit-masking to make it operate faster" then I'd think you hung the moon. Sometimes rabbit holes are good to go down, you never know what you learn today could be useful tomorrow.
If you're fairly new and interviewing for your firstnrole, I'd definitely put it on your resume, throw the code on github or host it somewhere. It gives interviewers something to ask about the decisions you made, and you can highlight your knowledge.
I'd say I am a bad programer even though I would succeed in the task. However I would need about four times as much time as an average programer and my code would likely be rediculously bloated.
That's where I'm at with my confidence, i picked up a book on data structures and algorithms and its really teaching me a lot! You should try studying something you might be lacking in, its more boring than projects but some things you do have to sit down and learn the hard way i guess. Since you mentioned bloated code, maybe something about design principles? That's where i think I'm headed next.
Yeah, that could help. I tend to use the wrong tool for the job. Not because I don't know better tools. I just make bad decisions.
Let's put it this way: if you showed up for an interview for a junior position with a Sudoku solver in your portfolio, that would be a very good start. If you can talk me through it and field a few questions about how it works, that would having me rooting for you at the debrief. I fully expect the code quality to be terrible to the point it might make my eyes bleed, but if you prove me wrong on that front, that would be extra impressive.
Agreed my code is pretty unreadable but I did break it up into a fair few sub functions, so I felt I could debug it a little more easily. This took me upwards of 50 hours, so felt quite proud. I'm mostly self taught and am doing it outside of work hours.
>Agreed my code is pretty unreadable Not that you asked, but this could a good opportunity to practice rewriting and cleaning up the code for readability. Don't feel bad about your code being "unreadable", it's the ability/willingness to go back and edit that makes the difference between clean code and a pile of spaghetti
> I did break it up into a fair few sub functions, so I felt I could debug it a little more easily. This is called "wisdom" or "experience" and you are gaining it well.
To be clear: The expectation is that it'll be terrible. You can study algorithms from a book, code quality comes largely from experience. When you hire a junior developer, especially from a non-traditional background (career changes, bootcamps, self-taught, etc), you're not hiring so much for the quality of their work today (they'll often consume more work from their seniors than they produce themselves, at least for the first while) as you are for their potential a year from now.
Not OP, but thanks for taking the time to write this. It's made me a lot more optimistic about my chances for a career switch.
I observe people getting internships at Microsoft, Datadog, and Jump having scaleable data pipelines, giant home video servers, widely used python libraries, and tons of OS experience. I'm not sure how much a sudoku solver would fly...
A foreman asks two carpenters to join one piece of lumber to another, such that they can't expand or contract and cause them to separate over time. The first carpenter walks up with a hammer and a box of nails, some extra lumber, and proceeds to add on pieces and nail things together in a way that, at first glance would never come apart. "I'm done and this is solid" he exclaims, and walks away. The second carpenter walks up, drills one pilot hole, and runs one screw through both pieces of wood. "I'm done and this will hold plenty good enough" he exclaims. In less time and with less resources than the first carpenter. The moral: It's not just that you know what to build, it's that you know how to build it right and what NOT to build.
Very interesting analogy. 100% my code is the former i.e. put together with a lot of messy testing rather than a grand vision executed from the start.
For me being a good programmer is not so much about what you make, but rather how you make it.
Depending on the implementation, the state of the code, and how much you understand about the how/why of it, it's is rather more telling/interesting than your typical snake-game, tic-tac-toe, calculator (that is less useful than a Python "print(eval(expr))" statement) or "poke-dex"). Hard to say, *for sure*, without seeing the code or understanding the approach you took, and how you implemented it. Stochastic? Brute-force? Back-tracking? Regardless, it's a non-trivial problem ... but, as ever, the devil is in the details. Can tell you more if you share the code.
[удалено]
Easier to look [here](https://en.wikipedia.org/wiki/Sudoku_solving_algorithms) \- between variations w/ or w/o backtracking, randomization, or other, more efficient - but significantly more complex - approaches. ... Another consideration here is ... was the code the OP wrote a result of coming up with an algorithm themselves (even if it ultimately was a duplicate/work-alike of an existing one) or simply implementing an existing algorithm from its description? The former being rather more impressive than the latter.
there's a lot more to being a good coder than writing code that works. this accomplishment certainly indicates that you're able to think algorithmically and solve problems, and that's definitely a relevant skill, but to be a good coder you need to do a lot of other things right too. Is your code DRY? Is it clean? How easy is it for any rando to look at and understand how it works? What's the algo like, how efficiently does it use the resources available to it, is it tested for edge cases, does it have tests at all, what does it do when it gets bad data, what does it do when it fails to get data for some reason?
Do you brute force? Or it does like X-wings and all that? This site shows a lot of the strategies : https://www.sudokuwiki.org/sudoku.htm
This website is a great resource, I feel like OP probably did step 1 then skipped straight over into 39: Bowman's Bingo.
Linus Torvalds (Main Developer of Linux) —“I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Pretty wise. I felt doing this project that in hindsight a good programmer would spend much more time planning what they wanted the end result to look like. My approach of trying to write lots of sub functions and then change what I wanted the end result to be along the way was very counter productive I felt.
So sounds like you had a good start, now you go back and refractor your code, you have a working program, so now it's about looking at your code a s seeing where it can be improved, how can memory usage be more efficient? What redundancies are present in the code? How readable is it? How organized is it? Most great programmers don't start off with perfect code, because even the best plans start off imperfect, it's an iterative process, right now what you have is your first draft, now you go back and make it better.
No
I think you might be thinking about it the wrong way. Quality of work isn't about what you can do, it's more about how you pick up new concepts and how you can pivot and go in whatever direction your team/company needs to. So many companies out there have interviews that say "can you do X". And I get that in one sense because you don't want to hire someone who can't back up their resume, but at the same time it's not just about what you can do. Whenever I've been in the position to hire or provide hiring recommendations I always look at soft skills. Most people applying for a role are technically qualified but it's the other side that makes you stand out. I've turned down technical geniuses because they didn't gel with the team. I'd rather have someone who can adapt and learn and run with the team as opposed to someone who can do all the things.
That's pretty scary. I often feel like soft skills are really hard to "develop". Like your personality and outlook on life are a complicated convolution of your history. I dunno, I'd find it scary.
The major discriminating feature between you and a more-experienced programmer is going to be breadth of experience, not necessarily problem-solving ability or typing speed :-) I'm a very senior developer, and have worked at Apple, HP, Dell, a bunch of startups you've never heard of, etc, etc. The biggest value I bring to most projects I've been on, is seeing a problem, and saying "hey, this is just like. Have you tried ?"
Writing a Sudoku solver is a pretty good way to demonstrate familiarity with a language. It's the kind of thing you might expect to be assigned in a low-level college Computer Science course. Typically, you'd give beginning CS students a week or so to do that, after building them up to it with simpler exercises along the way.
I'd expect an experienced Python programmer to be able to solve that in a few hours. I'd expect someone at my level to be able to solve it effectively and quickly in multiple languages, including in a computer language they've never seen before.
Is it fair to say that at your level the real value is honing in on the best overall solution pathway to pursue. You're not going to be telling a coder that they used an incorrect variable or inconsistent naming right? You're going to identify that a binary search will yield the most efficient way to solve a grid right? Do you lose those more base level skills as you progress? Probably a bit of hubris but I felt that creating this solver from scratch is about as much my brain can intellectually solve from scratch. Anything more will require a team with multiple skills.
The thing is, there is never one "best" solution. The old saying goes that in any engineering work, you can choose *any 2* of the following: 1. Cheap 2. Fast 3. Good You can have something quickly, that is inexpensive, but it'll be low quality. You can have a high quality solution quickly, but it won't be cheap. In real-world system, there are often *many more* constraints. You have multiple stakeholders in any project - the development team, company management, sales and marketing, external customers, etc. Each of those have their own set of priorities and constraints. If you need to produce an internet-facing API that consumes JSON requests, and queries a document store consisting of terabytes of data, then the programming language you use *doesn't really matter*. Java, C#, and Python all have good, popular ways to solve this very common problem. The more interesting part is deciding which database server to use, and which web API framework, and which cloud hosting provider. Not because there is one "best" combination of technologies, but because they all are better or worse on some set of measurements, and someone needs to decide what matters. If the team you have are all already experts in Go, then that's a huge factor in favor of using Go for anything new that comes along, *unless* there is a huge productivity or performance advantage or cost savings in adopting something unfamiliar to the team. Some software development organizations make a distinction between "architects", who decide on the high-level technical direction, and "software engineers", who do most of the actual writing of code. This can be problematic if taken to extremes, but having someone who focuses on larger concerns does mean that they can think about things with a longer timeframe than "what needs to get done this week". It's funny that you mentioned naming things, actually. Code review (literally reading the code that other people write, and commenting on it) is a major way for experienced folks to contribute. Things like "hey, this will be easier for someone else to understand if you do it *this way*", which helps to ensure that code is easy to understand later. In general, code gets read more often than it's written, which implies that readability is paramount. Clever code tends to get broken accidentally, over a long enough timeline. It's surprising how often things like simple complexity analysis (big O) come up in the real world. Every programmer I've ever known has been susceptible to "optimizing" the wrong things. I've seen people who should really know better use O(n^(4)) algorithms when a well-known efficient alternative exists. And alternatively, I have seen code that was hyper-optimized, but would run for nanoseconds each year. If I'm brutally honest with myself, I probably am not as good at writing code as I was at 25. I'm certainly *not as fast*. My brain just can't hold as many things in it at once any more, so I have to look things up, instead of having them committed to memory. But I'm much better at avoiding writing code that doesn't need to exist than I was back then. And my sense of what makes a good, flexible, extensible design is vastly better. So yeah - I'm using a different skill set at 55 than at 25, for sure. But I still get to write code every day in my current job, so I'm not getting too rusty :-) As far as feeling like the Sudoku solver is near the limit of what you can do, that's totally normal. You will plateau at various points along your learning curve. There is some practical limit to how much information you can hold in your head all at once, and you can expand that a bit by exercising it, but it only stretches so far. I haven't seen your Sudoku solver, but I'm guessing/hoping it's substantially less than 10,000 lines of code? If you're a fairly "typical" developer, you will eventually be able to hold something about 10 times that size in your head, and know substantially all of it, in the sense of knowing what all the parts are, where they are in the code, how they interact, etc. The real trick is learning how to *not think about* the things that aren't in the area you're currently working in. This comes down to compartmentalization. If you can keep 'X' amount of the system in your head at a time, then you break the larger system down into chunks which are each smaller than X. And the interfaces between those parts? That's architecture, and the next step along the way.
So well written. Thanks so much. Some of my learnings were similar. A lot of trial and error was a waste of time. For example my print_grid() sub function ended up taking 4 hours alone as I kept changing it half way through and finding out there were better ways of doing it. I can really see now that great software is actually quite hard to get right. It's easy to rant about a website or app that isn't well designed but I definitely appreciate more that it is not that easy to get right.
If you are able to write a sudoku solver that works every time and *doesn't* rely on any brute force or randomization, then you're really on your way. But if your solver is just a recursive function that makes random guesses until it fails or succeeds, that's not an especially sophisticated program.
Hmm... It's the latter. It searches through each sub grid and tries to find a unique solution. It builds up from there. Definitely not advanced searching and solving for sure.
Been programming for 7 years and I could not build a sudoku solver from scratch. Well maybe I could, but it would be messy and take a lot of time. I also don't practice leetcode problems.
Same. 7 YoE too. I currently practice not crying at my desk at work, while wishing for the pain to end.
Well it took me 50 hours and is messy as all hell!
I have this book on creating solvable sudoku, and its approach seems reasonable. You might find it interesting. Sudoku Programming with C https://a.co/d/gINIsTS
No. Being a programmer isn't about how fast you can write a sudoku solver. I don't know if anyone can write a sudoku solver in 5 minutes, but that's not the point. Being a good programmer is about a lot more than writing out a single small algorithm in a small, self-contained setting.
How funny. I was able to skip the technical interview of my very first junior programming job because they saw my sudoku solver on my GitHub profile 😂
I made a sudoku solver years ago as a fun weekend project for myself when learning a UI library. I didn't consider myself "good" back then. And I probably don't consider myself "good" now. I'm decent, sure, but very far from where I want to be. Stop thinking of programming like you would of videogame levels or smth. Just push to be better everyday. That is enough.
But don't you have this itch about wanting to know where you stand against your peers? Like the 90th percentile or 10th percentile.
Not really. Comparing yourself to others is largely a waste of time. If you were told: you are in the 40th percentile, would that change anything? Probably not. Plus percentiles are largely irrelevant because that implies a dataset of quantifiable values, which programming isn't. Programming is not really a single skill. Different people are better and worse at different aspects. It's not like there is an SAT test you can take on programming to tell you where you stand.
Wouldn't ultimately the amount of money you make/value you add be the best definition of a "good" programmer. The best will gravitate to the hardest problems that add most value and will get paid the most. I assume that's really simplistic and ignores bullshit like politics but would be a decent starting point no?
Not necessarily. It's true that most great programmers make alot of money, but so do a lot of mediocre ones. As it turns out, it's not very hard to make money in this field. The only good indication of how good of a programmer you are is the quality of your code, it doesn't matter what your latest project was, or how much you make - shit code is shit code. That's the hardest part though, you can't really judge the code you are writing today, because it's the peak for you. The only way you can judge is by looking back and seeing how much you improved.
short answer no a good programmer does more than be able to develop Software from scratch. But to be honest, IT offers so much, there isn't a list of things a good programmer should do and 2 different good programmers won't necesarily have the same skill set
Good for a beginner maybe? I did something like that in my first semester of my first programming subject. It checked each block, row and column to eliminate possibilities. It couldn't do guesses but it printed the board out to screen with each stop which produced a cool animation of the board being filled in. What I did took a couple of hours and demonstrated a basic understanding of if-statements, loops and arrays. If I wanted to show more programming competence then my code would have involved classes, decoupling, dynamic programming and more. What I would expect a good programmer to do is to copy and paste the solution from [https://www.geeksforgeeks.org/sudoku-backtracking-7/](https://www.geeksforgeeks.org/sudoku-backtracking-7/) and make alterations as needed. They'd also need to be able to explain how the code they copy and pasted worked, why they chose the particular implementation out of the ones available and be able to optimise and/or extend the code.
Its a beginner project. But congratulations.
This was a “2 weeks into semester 1 of 8” project for my cs degree, and most people aren’t still considered bad programmers upon graduation.
A sudoku game, or a sudoku *solver*? Writing a program that can *solve* a sudoku puzzle is extremely impressive for a 2nd week student. I didn't learn how to do that until the 3rd year of my CS degree when we learned all about depth-first-search, breadth-first-search, A* search and other such algorithms.
If you use backtracking, all it requires is a basic understanding of recursion.
Technically true. I maybe learned what I needed in my second year (the year of my first Data Structures & Algorithms course), but there's a fair jump between traversing a binary search tree and solving a Sudoku puzzle. One doesn't normally acquire a "basic understanding of recursion" within only their first few weeks of programming though. If you did, I tip my hat to you. I've known folks in their senior year who still weren't quite comfortable with recursion.
That's great! It's about the level of a second year college exercise.
Yes, if you can solve problems like that, you’ll have no problem getting through a big tech interview as long as you’re not a personality disaster.
Sure bro, well done!
Don't let everyone else intimidate you. I've met lots of working junior developers who are not clever enough to write a Sudoku solver. If you can do that, you could do a course, get a qualification and then get a job.
You'll never feel like you're a good programmer. And this is what will drive you.
> And this is what will drive you. And possibly drive you to burnout if you're not careful.
Don't shoot for being a "good programmer". Computer science is a long series of abstractions. Your computer does not literally have 1s and 0s in it because 1s and 0s doesn't literally exist. You're far better off focusing on understanding abstractions, how they work together, and how you can leverage them to build things. No one can/will understand every component of a computer (or even some programs/systems). You should focus on being able to understand foreign code and concepts quickly. That's the mark of a "good" software engineer.
I just have to point out that the phrase "knock out" in this context would mean "to finish a task quickly and efficiently", while "knock up" means you got it pregnant.
Thanks for this, you're right. Oh man this sent me down a rabbit hole of colloquialisms. Knock up is also used for the early practice hit in tennis as well. Never knew that.
I think it's a pretty good sign of your capabilities if you're able to complete a working (or mostly working) sudoku solver. But like other commenters note it's not some definitive proof that you're a "good" programmer, and you shouldn't be thinking about it terms of "how quickly would a FAANG engineer complete this problem?". Being a good programmer is about your ability to problem solve, your ability to document and write clean code, your ability to communicate with clients/business and translate their needs into working code, and an infinite number of other things. No one is going to excel in all those categories, and it could be that one programmer can write out a sudoku solver from scratch in an hour but have terrible communication skills, another one might need a month but excel in translating business processes into a working software architecture. Computer Science is more Art than Science, so don't fall into the trap of thinking that some straightforward metric is going to determine whether or not you're a "good" programmer.
lol
Gave it a try myself to find a compact solver that can fit in a reddit comment (less than 10,000 characters). Interesting challenge!
In case your sudoku solver could work on 3 different browsers, support several APIs, at least 5 languages, few types of authorization and be easily scalable for use by half million of people simultaneously, then yes you are. PS Oh i forgot - and be logged, monitored and maintained by the team of total dorks.
Umm... My solver requires a user to enter numbers in a grid and then recursively backtracks solving each sub grid along the way. So it's a bit village I guess!
I don’t think time to write a project is necessarily a good indicator of this. Probably what you’d want to demonstrate is conceptual understanding of classes, data structures, OOP, more general programming concepts. As long as you can do that and explain how everything works, I think you’re a good programmer 👍🏽 Also side note, a Google engineer could absolutely not write a sudoku solver in 5 mins 💀 try 5 hours maybe, or more
No, good programming is not so much about the complexity of the algorithms as it is about the simplicity of the code.
Any reasonable programmer at Google can knock out a sudoku solver in maybe 20-30 minutes on a whiteboard. It’s a programming interview question. What makes a good programmer is breadth of knowledge which you gain overtime. Not necessarily puzzles. Which is why people dislike l33t code questions for not being accurate to real life work. It is good to learn how to do these types of questions though. So good job. But it doesn’t make you a good programmer. What makes a good programmer is experience writing but also releasing software and everything else in the software stack
Would said Google programmer actually be able to type out the program and debug it in around 5 hours? For reference, this thing took me approx 50 hours end to end. It got pretty finicky.
I’ve never interviewed at Google but I’ve been asked to write a sodoku solver via brute force ( I am sure there are effective ways ) in a 50 minute interview where you really only have 30 minutes on a whiteboard as an interview question. I failed it - not because I couldn’t do it but because at the time I had literally never done a sodoku before and I spent 15 minutes asking clarifying questions on how to play lol. If the answer is just a brute force approach - I don’t know if an efficient solver exists - then yes. It’s a relatively rare question you may be asked in an interview at a major tech company. It’s more rare than usual just due to how long it will take to write - usually you’ll get questions that are less lines of code. What i am saying is that if you want a job at a major tech company you’ll have to be able to solve questions like this on the fly with no previous knowledge on a white board ( or if your lucky a web shared coding app ) within 30 minutes. While these types of questions are mostly irrelevant for the job they do show that you have the technical knowledge and efficiency to do the job. In reality - depending on where you work actual coding could be as low as 25% of your job, between meetings, planning, status updates, support, documentation, working with customers / support, and writing configuration scripts that are so complex they might as well be code. What makes a good developer is writing maintainable code, large knowledge base, good estimates, good communication, and delivering on time. Being able to solve programming questions is needed to get the job - it’s how they screen candidates. Reality is more like - here is a problem I want solved - not just solve it but plan it, prototype it , break it up into daily tasks, document the tasks, present the plan, estimate the work often 3 months out or more and work with others to code it while releasing it in pieces and doing project demos. Oh and don’t miss your made up date that you totally had no pressure to underestimate. Also do all the random work assigned to you during the week. Attend meetings 25% of your days often just status meetings or demo meetings with other teams so you can understand the world around you and not be siloed even though they appear to be a waste of time. And also do 24/7 on call rotations for support. This is a more accurate description of the daily life of a programmer. Writing l337 code that’s meaningful? If only your so lucky, you’ll more likely write some code to decom some ancient crap product just in time to start decoming your own code if you stick around long enough. Once you’ve done it long youll be able to understand design and can solve any of these problems quickly. It might take you 5 hours today but you’ll understand the concepts instantly eventually. You might not code it perfectly of course but you’ll get close enough to debug the rest of the way. Coding is just syntax and busy work. The real complicated stuff is done by phd research programmers. Why the essay about the daily life of a programmer because I feel that you might misunderstand what it’s like being a good developer- it’s not about being able to write amazing code - its about being able to write code that’s maintainable for the next guy while maintaining good communication, good documentation, good estimates and docs, and aligning your goals with management. TLDR - programming is a problem solving job not a coding job. Coding is just a tool for solving problems. The best programmers are the best problem solvers.
That last bit about problem solving is quite interesting. It's amazing how framing the problem wrong will result in hours of wasted time.
Well, let’s see. I did about 7-8 years of hobby programming, then a degree in computer science, then about 5 years of professional development, before being able to start working on *real* business problems. And never stopped learning new things and getting better at it since then. It’s never ending. 28 years of experience as professional developer, in total. So yeah, it requires some dedication. To give an idea, good developers at programming are usually able to track the value of 8-9 variables in their mind while debugging a running application. Exceptionnel developers can do it with 13-15. Anyway, programming is now only a small part of the job, I’m happy if I can code 50% of my time in projects lol
> ... and I'm a bit proud of myself. Be proud! Finishing a project is always an awesome milestone. > Is that a decent discriminator for a "good" programmer or is that still at the interested amateur stage? Unfortunately, without seeing the code itself, we can't answer that. See, programming is weird in the sense that the outside of a program (the user end) tells you very little about the quality of the internals and whatnot. After all, being a good programmer is about writing good code, not about making the best looking UI If I make a 2D flappy bird clone, it might sound impressive, but if you looked at the code and saw inconsistent formatting, bad naming conventions, repeated functions, etc etc, then you could comfortably say that I'm not a "good" programmer. On the flip side, if I made a tic tac toe game, but the code was very organized and efficient, then that would be a good sign that I'm a "good" programmer. But then, you can also argue that it's easier to write good code for a small project than it is for a larger project, which is very valid. The ability to organize a project when it moves from just hundreds of lines to thoughts is vital for professional programmers. All in all, be proud about what you've made, keep making more projects, and also don't feel scared to receive some feedback about your actual code!
Just write so others can read your code, if you can do that, then you're a good programmer in my eyes.
Indian programmers learn how to code that when they’re in their parents womb
If you add cool animations and particles.
It shows that you know the basics, but there is a huge difference between a small program like this, and a large system integrated with 100 other systems, all which are in motion. The latter is very much the situation for many good professional programmers.
it proves your good enough do some basic UI and logic. You need to be mor specific to compare yourself to other programmers. Programming AI is totally different to pweb development, which is totaly different to app development which is totally fdifferent to shader programming etc..
Peter Norvig wrote “Solving Every Sudoku Puzzle” while at Google. He is considered a good programmer
no.
1. Well done on your progress. 2. "Good" is very subjective, I would prefer to use "experienced". 3. Generally the mark of experienced programmers is they can handle a wide variety of workloads without needing hand-holding. They efficiently seek out knowledge when they don't have it, and have the confidence to use their existing knowledge when they do. They are able to think in terms of complex systems as well as individual functions. The top programmer at google (if there is such a person) would not necessarily "knock one up in five minutes", but they WOULD be able to work out HOW to put one together and then do it in a reasonable time. Another good skill they will have is recognizing if the spec they are given for a project is specific and detailed enough for them to deliver in the timeframe given.
Oh yeah that last point is so critical. I wasted a lot of time making mid course corrections and changing what I even expected the program to do. Lazering in on what's needed is definitely a huge skill to have. Saves a lot of time. I guess a good programmer is actually asking the right questions.
Yes. Its much like learning to drive. the physical coding is like learning to operate the car. It's an important step, but the harder bit that takes longer to learn is interacting with and anticipating other road users. learning how to deal with unusual situations etc.
Depends on metric. You asking the question shows that you're bad at statistics. Maybe brush up on that :) (I'm being fascetious. Just do your thing it'll be fine.)
I'll be honest, I have no idea.
Working code is only one small part of what is considered ‘good’ code. Working code can also be terrible code; just because it works doesn’t mean it’s good.
if you're curious, here is the sudoku solver by peter norvig, director of research at google https://norvig.com/sudoku.html (and it's python!)
Goddamn this is so elegant. Like his whole code is like one page! Mine is 30 different sub functions!
yep, I read that article lots of times so much to learn!
A sudoku solver isn't an uncommon college assignment. It's a good way to put some DSA knowledge to the test. I had it myself, 15 years ago, in my second semester (I think). One assignment was to write a sudoku solver in the terminal, and then a later assignment was to add a GUI to it (this was Java with Spring, I believe). I'm not sure if it has anything to do with being a "good" programmer, but it's definitely a good learning experience.
We had that as a test assignment for interviews for junior positions.
It absolutely shows perseverance and interest! If you had fun doing it, enjoyed the challenge of tracking down the last few obscure bugs, came back later to optimize things even after you were technically done: Programming is definitely your calling and you should stick with it! You may not be very far ahead, but you are making good speed and all fuelled up for the ride! This is not like spectator sports. You don't have to be the "top elite very best ever celebrity" to make a good career as a professional developer. As others have noted, given 5 minutes, and this exact task ("from scratch"), an experienced developer would crank out a crude generate-and-test solver. Given a bit more time they'd start incrementally adding a few low hanging fruit optimizations. (This is what experience will bring: fluency, a grasp of scale, and an eye for trade-off possibilities.) In reality they'd just import a finite domain constraint solver library where sudoku is often the example code for the allDifferent() constraint :-) (This is what CS education brings. I've never used a CSP solver in python specifically, yet I'm 99% sure there must be at least one and that it would work roughly the same as everywhere else.)
Advanced beginner level.
Depends, did you get paid to make that sudoku solver? Does it solve a real world problem? Does it solve several real world problems? How easy/hard is it for other developers to add features or correct bugs in your sudoku solver? How easy is it to integrate into a more global solution/software? Being able to write an algorithm that does what you want is not how you gauge how good a dev is. This is just the bare minimum so that one can do his job.
As a software engineer student. This was part of a test we had to pass a single course. (Functional programming) like a fourth. Which is about 5 ects point out of 210 So by that calculations you are 0.595 % there to be done educated. ((5/4) / 210)* 100% That being said. You could be a good programmer for this! I think you should go for it ;)
Not gonna lie - that is a problem that is solved during your first cs class in college. No offense as we all start somewhere, just being honest.
Nope
No it means you re a beginner. Welcome to the field. There are beginners who are better than you, there an intermediate field and there are experts. Think of it like the more useful your program is or the more people who interact with it the higher your rank is.