<p><pre><code> Recently I went to an interview for python developer. I didn't get the job and when I asked for feedback, they said it seems I am more like scripter.
I can write codes under framework and abstract business logic on top of libraries. When I look at my works, They seem to solve a lot of things but design is a bit flat. Usually I am alone doing project. It makes me quite hands on. However the bad part is I think I know it but each time I just take easy path which might not be best practice.
I think really hope to leap from scripter to developer. maybe working in a team helps. any advice is welcomed. Thanks!</code></pre>
I just see this as a lame non answer. When being asked for why I'm passing on someone I can give some fairly clear and concrete reasons. What someone could have done differently or what skills they could have had that would have pushed them over the top.<p>My questions for you: do you know more than one language? Can you design a database "from scratch" - do you understand the rest of the technology in the stack of your domain - (servers/network and so on)?<p>> Recently I went to an interview for python developer.<p>This tells me a lot because the python community is, for lack of a better word, weird. There are plenty of (ab)users of python who get shit done without being programers by trade. I can point to plenty of data, EE and systems admin folks who see python as a swiss army knife. Their code is ugly but functional, it isn't code that is going to scale or be elegant, rather it serves a purpose. Python on the web/api side is a different beast, it is easy to turn your python code into a big ball of mud without a fair bit of discipline - Exactly what that takes is up for some debate and can be domain dependent.<p>If your the sort of python dev who focuses more on "get shit done" rather than "long view" I could see how someone might make the comment they did. The get it done mentality is not something you need to drop all together (it happens to be how I use python myself) but it doesn't preclude you taking the long view as well.<p>Lastly you can run into some very odd camps/elements in the python community - the fact that were 9 or 10 years into the 2.x to 3.x should tell you where some of the lines might fall.
The very short version:<p>Probably ignore that person.<p>The short version:<p>Reading charitably, what they meant is that they're looking for people with open-ended problem-solving skills. They're confident in your ability to, as you say, solve specific problems whose form is well understood: writing a controller, connecting APIs, and so on. What they're more concerned about is whether, if you had to, you could reproduce that API or write that framework from scratch, design and all.<p>In other words, they're looking for a person whose skill is "fix a broken car," not "fix the power steering on a 2015 Honda Civic." Maybe they don't have a Honda Civic. :)<p>The oops-not-long version:<p>Though it's possible to make a technical distinction between programming and "scripting," people who insist on making it are often doing that for social reasons (which is why I jumped to probably ignore them). I don't know if going into detail would be helpful, so I'll actually stop there.
I don't agree with the scripter vs developer differentiation.<p>But my interpretation of the difference is that<p>Some developers can read the documentation, put together what some devs might deem easy like build REST API, put on a rate limit, add authorization, integration with payment APIs, scrape website or parse CSV file etc... This is what 80% of the job involves.<p>Some jobs include requirements like this<p>Build a distributed key-value store for storing counters, it must work for 1200 RPS, the counts must be available in both EU and US region (150ms) apart. Counters should be consistent in both the regions.<p>Can you think through such problem? Do you know what it takes?
Do you know updating counter is not a single operation but:<p>1. Read the original value
2. Increment the value
3. Save the new value<p>Do you know how latency the between the region affects the throughput of the service? How can you make counters reflect consistent count in both regions consistent?<p>What if one of the servers goes down? How do you make it highly available?<p>Customers might increase and we end up needing more nodes. When are more nodes added how is the data rebalanced, what effect does it have on throughput and latency?
The main difference is whether they think that you'll write maintainable code and extensible code. Will teammates be able to work with your code easily? Will others be able to maintain or extend the code when you're gone? Is it easy to debug? Does your code use the right abstractions when appropriate? Is your code efficient? The response probably indicates that they saw something in your code that they felt wasn't up to par.<p>In general, this is something that you'll improve at naturally when you work on teams or maintain legacy code (assuming a relatively good codebase). One thing that can be super-helpful is to review a good codebase and see how features are implemented and think about why it was done this way and how you would have done it (for python, take a look at the flask or django codebase and see how they use abstractions). And honestly keep interviewing.