10 ms·

Ask HN: Uncommon but attainable programmer skillsets valued by employers?

• thorin 8y ago
  Speaking to a customer and developing some of use to them. Doing the design, programming and test yourself and helping them with the training. I'm thinking of standard enterprise web and back end development . There is a real shortage of this as far as I can see. Also people taking responsibility for their stuff and willing to pick up (not necessarily cool) skills required for the delivery.
• abhishekjha 8y ago
  Reading code, particularly as a beginner in the industry.
  • mafagafogigante 8y ago
    This. Being able to work on code that you (or the person sitting next to you) didn't write is fundamental but often ignored in university courses.
    • johnvanommen 8y ago
      My number one complaint about University Courses. We didn't spend a single minute doing what most of my job consists of: reading someone elses code and trying to decipher what the heck they were trying to do.
      • collyw 8y ago
        One you have done enough of it it maddens you enough not to make the same shitty mistakes. Keep things as simple as possible and no simpler.
  • passiveincomelg 8y ago
    Agreed, nobody reads code. Also nobody considers "debuggability" when picking languages/libraries/frameworks/etc.
  • realbarack 8y ago
    Yeah, this is the most important, ubiquitous thing which in my experience doesn't get explicitly taught anywhere. Are there any particularly excellent books on the subject?
    • cimmanom 8y ago
      Like reading a human language, once you can "sound it out", so to speak, it's something once typically gets better at by practicing. With well-structured code, as with a well-structured essay, you can learn to skim to get an overview before your deep dive by focusing on the beginning and end of every chapter/paragraph/etc (e.g. function definition and return statement; gate for each block; treating header files as Table of Contents; etc). But most code is no better structured than your average Tumblr post, so that's kind of hit and miss. And as with reading human language, you can learn techniques for taking notes as you go along to guide yourself or remember important details; but the technique that one person finds helpful may be a waste of time for another.
    • marktangotango 8y ago
      A book won’t teach you, pick a large open source project you use daily like nginx or apache and study it starting at main.
• tuxxy 8y ago
  Security centric development. I don't think I need to go into the details of why it's useful, but I think nearly every developer should have an idea of very common vulnerabilities and bugs and be able to catch them _before_ code gets committed. This means introducing security into your design discussions, stand-ups, and your code reviews. Developing the "adversarial mindset" isn't horrible necessary for just any developer, but it does help you see more issues that you may otherwise miss out on.
  • crdoconnor 8y ago
    I've noticed that a lot of companies don't pay attention to developers who raise security issues - they usually just hire an expensive consultant and pay them to tell them what to fix.
    • horofox 8y ago
      Exactly, you might want to be the consultant
      • crdoconnor 8y ago
        I might, but there's two parts to that: #1 having a security mindset and security knowledge and #2 successfully branding yourself as a trustworthy security consultant. I'm honestly not all that sure how you become the guy who an executive who knows nothing about security feels comfortable hiring. I'm also fairly sure that being good at #2 is somewhat orthogonal to being good at #1.
        • thiago_fm 8y ago
          go to conferences, develop your charisma, get older, know people
• cvaidya1986 8y ago
  How to sell
  • pliftkl 8y ago
    I think this is an incredibly valuable skill, but it's one that is sometimes looked down upon because many people have negative emotions around "being sold to". Good sales is really about learning to ask the right questions at the right time, which is something that engineers should in general learn to be good at anyway.
  • drjasonharrison 8y ago
    How to sell: - a proposed feature that does not yet exist that customers will pay for - a fix for a defect - an improvement to a fix for a defect - accepting a defect as being lower or higher priority - improvements in the product development process (automated tests, continuous integration, continuous deployment, pull request reviews, coding style over solution...)
• nextos 8y ago
  Formal methods. Extremely cool and undervalued, except on a few key and well paying industries. I believe it will make a big comeback when it's more ready for prime time. You can start small and grow your skills in many directions: linear types, probabilistic model checking... It involves a very neat but approachable branch of mathematics: abstract algebra.
  • DennisP 8y ago
    I didn't realize abstract algebra was related to formal methods. Would learning the math first make it easier? Formal methods are on the verge of being a big thing in smart contract programming, where the code is short and failures are expensive.
    • nextos 8y ago
      Knowing a bit of abstract algebra, semantics and type theory doesn't hurt. But I'd suggest to start by reading http://www.concrete-semantics.org/ http://www.concrete-semantics.org/, which is a great overview. Once done, you can go for an approach well-grounded on the theories I mentioned above. I agree formal methods are great for smart contracts. Back in '08 when I was doing graduate work on the topic, some researchers were already talking about it, but the enabling technology (blockchain) was missing. They are also great for real-time critical systems, especially if you go with a formal methodology, where you start with some axioms (e.g. two trains can't be in the same track partition) and progressively derive your system from these by applying formally verified transformations till you end up with the code to deploy.
      • DennisP 8y ago
        Downloaded it and ordered the paper copy, thanks :)
  • bostonvaulter2 8y ago
    What would you advise looking into in regards to formal methods? Any particular software, books, or talks?
• flockonus 8y ago
  Remote positions tend to be more focused on track record, so it might be hard to impress if the applicant don't already have some project in their resume. Other than that, being able to demonstrate specialized in the skill that you are applying for. If the job asks for Java for instance, make sure that your related expertise is demonstrated. Non skill related, and really dear to me, is to think outside the box when looking for a job. Don't only apply for the obvious positions in large companies, search and go after less advertised positions that you can be competent in.
  • cookiecaper 8y ago
    > Remote positions tend to be more focused on track record, so it might be hard to impress if the applicant don't already have some project in their resume. A caveat here. Not all, but many, remote positions exist because the company is hoping to get labor for cheaper than they can source it in their local market. In such instances, qualifications aren't going to matter that much. If you're a fairly senior level person, any reasonable salary expectation will exclude your consideration for the majority of remote positions. Some companies are relatively shameless about this and announce that they have location-adjusted salaries (in the case of GitLab, they even have a public salary calculator that shows that they seriously underpay), etc., but many try to keep it under the covers since it would hurt their reputation and recruitment efforts if they weren't able to spring a low-ball on candidates. If you're good, I would suggest that you just keep applying rather than assume that your qualifications are insufficient, aware that the majority of remote positions are hush-hush attempts at keeping payroll costs down. Source: fairly senior, large part of my career has been remote.
    • johnvanommen 8y ago
      I've definitely thought about this. I live in San Diego, where the cost of living is very very high. If I relocated to somewhere cheaper, I could probably work for 40% less than what I need to make in SD. But it's unnerving to be in a spot where you MUST work remote. I've been working remote for over a decade now, but I'm still kinda amazed I've managed to keep it up for this long.
    • 8y ago
• f1gm3nt 8y ago
  Soft skills are the way I found that stands out. Being an engineer there is still the belief that engineers are ass holes and treat others poorly. Being able to explain complex topics and doing so in a way that doesn't come off like a jerk has been the most helpful. Always be positive and provide stakeholders with options with your recommendation and the reasons why.
  • drjasonharrison 8y ago
    This includes: the ability to make eye contact, to listen to other people, to ask question, to confirm what you said was understood, to confirm what you were told is understood. You don't have to be a psychologist, just interested in other people, what your shared goals are, and confirming that you are working together to achieve them.
  • kat 8y ago
    Totally agree! My current team always asks increasing complex questions in an interview until we the candidate admits 'I dont know that'. People with good soft skills can easily say 'I dont know, what does happen in that case?'. They come off as polite and self-aware. My other favourite interview question is what do you do when QA says they can reproduce a bug but you cant? A lot of developers don't have the soft skills to explain how they work with QA instead of against QA.
    • blablabla123 8y ago
      I mean you definitely need the culture for that, not every place is like that. Too often I have worked with people accusing me of not knowing about the Domain in question enough. (Even if it's something that can be learned in a short amount of time, if would be properly explained...) And what happens is then that I must work on something else. Especially in really culturally old school IT places you need to earn your (invisible) badges. So you are definitely right but at many places you shoot yourself in the foot with that big time...
  • blablabla123 8y ago
    I have gotten the impression that the more engineers are around, the less welcome are explanations of any kind unless there is someone with a really high reputation. Of course people like to listen to the management types of people but it's afterwards still ignored. Probably this is not the case at every organisation but I see there is a strong force that makes people do things exactly the way they want and nothing else. To be honest, I think this behaviour is not at all limited to engineers... But yeah, Soft skills, especially not caring only for oneself, are very helpful but they should be spread among the team.
• sgslo 8y ago
  Domain expertise. Before going into software full time, I got a degree in structural engineering and a few years of experience in construction engineering and management. That experience can be easily parlayed into a job at myriad companies producing project management tools, construction tools, etc. It has been something that allowed me to stand out amongst other engineers applying for the same job. As far as any employer is concerned, all the applicants can probably write the same quality code, but the ability to claim knowledge of why we're building some given feature has been a great boon.
  • 3pt14159 8y ago
    I did the same thing before moving into data science. I'm curious, do you really get sky high offers for your related knowledge? What range are we talking about here?
    • deleted 8y ago
      [deleted]
  • sixothree 8y ago
    I work in health IT and have noticed that candidates with experience in the field are more appealing. If you don't know what FHIR is, then you're "just" a programmer. I use FHIR as an example because it's an excellent technology to investigate for someone new to health IT.
    • stuxnet79 8y ago
      My CV has health IT written all over it, but sometimes I fear being pigeonholed. Yes, I know what FHIR / HL7 is.
      • sixothree 8y ago
        I'm so deep into quality measures, I don't know if I can ever climb out. Not sure if I even want to at this point. It's incredibly tedious but I enjoy it.
• aaavl2821 8y ago
  Some domain expertise or technical skills in a non-software domain. If you are A level software talent and C level in another domain that is a big differentiator. For example, finance / trading experience combined with engineering is a lucrative field. Also recently have heard many VCs and entrepreneurs wishing they knew more engineers and data scientists with at least some basic biology knowledge
• jaredhansen 8y ago
  Speaking as an employer of remote programmers: initiative cannot be underestimated. Often this can stand in for other skills, in that if you don't have skill X yet, but you've demonstrated again and again that you can and will figure out "how to get there from here" in a variety of situations, you're a very attractive candidate vs someone who already has skill X, but due to a lack of demonstrated initiative may be less certain to use it effectively. Consider the position of syntax in learning to program. When you first start, it seems daunting, and you spend all your time fixing compiler errors because you forgot a semicolon or whatever. Once you actually learn how to program though, the syntax and even sometimes higher order structures of a language will fall away as you start to think more abstractly about how to get the machine to do what you want. This isn't a perfect analogy, but it's a similar kind of thing here: early in a programmer's career it seems like [ COBOL / SQL / HTML / Java / Ruby / NodeJS / $framework / Big Data(tm) / ML / etc] is The Thing to focus on, and that you'll become instantly more marketable if you develop that skill. This is a little bit true in the very short term, but it burns out quickly as an approach, and cultivating Generalized Problem Solving -- including especially the motivation to solve any problem within range -- is much more valuable. The famous quote from Musashi[1] comes to mind: “The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy's cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.” [1] https://www.goodreads.com/quotes/38725-the-primary-thing-when-you-take-a-sword-in-your https://www.goodreads.com/quotes/38725-the-primary-thing-whe...
  • superplussed 8y ago
    I think I've always conflated motivation and initiative, and it's nice to see initiative being evaluated on its own right. It seems clearer and probably more actionable to discuss lack of initiative with someone than lack of motivation.
  • nscalf 8y ago
    So I'm very good at taking initiative and owning problems myself---I put a huge focus on learning in my own time, I love the challenge of a new unique problem or tool, I'll frequently come into work with a new idea of how we can make a product we're working on/our workflow/etc better in some way. I don't know how to show this to interviewers in the very brief time I have with them during screenings/technical interviews in most cases. I do research into any tools they use before the interview and do my homework on the company and interviewers. Do you have any advice on how we show initiative to employers?
• sulam 8y ago
  A honey-badger[1] approach to problem solving. So many people let themselves be "blocked". Rarely are they really blocked, they simply want someone to tell them the answer. This one personality trait has been responsible for a good 40%[2] of my success I'd say. I developed this skill because I literally had no one to ask for help with questions when I was learning software engineering, but I think anyone can develop it by simply not giving up when they hit a hard patch. I'm not saying not to use Stack Overflow -- that's a great way to get through the hard patch. But one thing that happens repeatedly for me (and I suspect for everyone) is that I'll get stuck and no one has left a written history of how to solve that problem. Honey badger reads the code of the library they're using. Honey badger learns to trace the packets. Honey badger reads logs. Honey badger learns gdb and strace. Honey badger doesn't hope in vain for someone on the Internet to play the role of deus ex machina, because they don't have time for that. Honey badger Keeps Going. [1] https://www.youtube.com/watch?v=4r7wHMg5Yjg https://www.youtube.com/watch?v=4r7wHMg5Yjg [2] my personal breakdown: 50% luck, 40% perseverance, 10% ability to retain details
  • wcarss 8y ago
    A related skill is being strategic about what really needs to be done right now. If you hit a roadblock, some people will just stop. Some will ask around and stop if there are no easy answers. Some will persevere until they hit their head so hard against the wall that the wall gives way. Some people will check if this is really a critical thing to accomplish right now, and just work around it when it makes sense. This can be the difference between 100% done, six weeks late, and 95% done on time, with a small outstanding improvement left to complete. It may even be easier to do when other work is done first. Sometimes you can't go around it -- then the honey badger does surely take the day! But I've found (and seen) a lot of success in asking yourself / a Product Owner if a feature can be delayed, or even cut.
    • Animats 8y ago
      Yup, that's "agile". "Shit early, shit often."
      • 8y ago
• kawera 8y ago
  Writing skills, specially fluid, precise technical writing skills.
• jkuria 8y ago
  If I could pick only one it would be communication skills. Writing and speaking clearly and being able to explain things well, especially to non-technical stakeholders.
  • gargarplex 8y ago
    And your resume is a great opportunity to 'show' rather than 'tell' this.
• munificent 8y ago
  The two skills that have been really helpful for me: 1. User interface design. There are many programmers who "hate UI" to their detriment. Your software doesn't do anything until a human can use it, and use it correctly. Having a little UI background means my solo software is easier to use, I work more effectively with UI designers, and I design better APIs (because API design is also UI design). 2. Writing. If you measure the number of characters you type every day and which applications they go into, you'll probably discover you spend more time writing email, chat, code review comments, design documents, etc. than actual code. Even when writing code, a good fraction of it goes into naming, comments, and doc comments. Writing improves all of those directly. It also taught me to invest in editing even more than I do in writing, which is a useful mindset to have for code. It helps me organize my thoughts more clearly, and choose better metaphors and names.
  • ydnaclementine 8y ago
    can you recommend a good UI book?
    • munificent 8y ago
      It's been years since I've actively worked on my UI education, but the ones I liked were: * The Design of Everyday Things * The Inmates are Running the Asylum * Any of Edward Tufte's books * Usability Engineering
    • bgorman 8y ago
      Don't make me think
    • adamnemecek 8y ago
      Design for hackers.
• randcraw 8y ago
  Cloud-based programming is such a skill, esp. to support scalability, portability, and redundancy. This includes in-house back office and analytical apps as well as classic web services and infrastructure support. Many companies also have custom in-house code that needs to be modernized and better integrated due to ongoing changes in their business processes. In big companies most of the major apps are 3rd party/outsourced, but quite a bit is not, and much commercial code needs to be custom fitted, made backward compatible, or made compliant.
• randcraw 8y ago
  Old-school coding tools/practices like Cobol, Ada, waterfall S/W development methods or projects that require extensive reliability/safety testing (NASA, car companies, air traffic control, military platforms, etc). These are niche opportunities, but far enough out of the mainstream that folks who have such skills are retiring and increasingly rare.
• Bahamut 8y ago
  Conflict management - engineers inevitably have conflicts on ideas, sometimes feeling very strongly about the solution. One skill I expect from a tech lead/manager is the ability to facilitate/foster the tough conversations for resolving these conflicts, and making sure all viewpoints felt heard & satisfied over the process.
• mayniac 8y ago
  Along with everything else people have already said: something you do in your spare time which shows some level of motivation. Hiring/firing managers I've spoken to in the past have been very, very wary of hiring people who either don't list any hobbies in their CV, or in interviews reply to "what do you do in your spare time?" with "just watch TV or game". You don't want to be seen as that person who has nothing to talk about but work when everyone is out for a beer after hours.
  • sirbranedamuj 8y ago
    Just because you don't enjoy those activities doesn't mean that they aren't respectable hobbies. You don't want to be seen as that person who has nothing to talk about but how other peoples' hobbies aren't as interesting as your own.
    • mayniac 8y ago
      I enjoy them and regularly do both. I still wouldn't mention it in an interview since they're something almost everyone does (gaming especially in tech fields). If every candidate is similarly skilled/experienced then it mainly comes down to who the interviewer likes the most, and if you can't hold two minutes of small talk on what you do in your spare time then you're at a disadvantage.
  • ConfusedDog 8y ago
    So relative. This will essentially eliminates vast majority of married candidates with family and offspring obligations and older gens that just won't have a drink with you. Nor is it an effective measurement of a person's capabilities of doing their jobs. Well, maybe that's what some startups want.
  • collyw 8y ago
    Screw that. I prefer to keep fit and get outdoors to clear my head.
• maxxxxx 8y ago
  I am partial to well written resumes. Most resumes I see are just a long list of things they have done. And then there are a few that are interesting to read and give you a sense of the person. Since the guy you are talking to is applying for remote positions this would be even more important to me. For remote work you need people who are reliable and don't need constant handholding.
• callesgg 8y ago
  Social skills. But such skills are insanely hard to attain. Some people simply give up on trying.
• z3t4 8y ago
  The address is probably the most important. It's really hard to find remote job.
• adius 8y ago
  One word: Haskell
  • Lordarminius 8y ago
    Interesting. Haskell programmers are scarce enough that just knowing the language makes a difference ?
    • solresol 8y ago
      Unlikely to be true in general. I'm having no troubles hiring Haskell developers. Hiring good front-end developers on the other hand....
• jowiar 8y ago
  Overall, the fundamental career decision is whether your goal is to join "big tech" or to be at a startup/small business/non-tech firm. If the goal is to be at Google/Amazon/etc, I'd probably suggest an overall strategy of "pick something relatively narrow, and be the best in the world at it". Big Tech firms tend to be the land of experts -- there are fewer job titles of "full-stack engineer", and more of "we have enough engineering resources to have specialists for everything". For small companies (or small tech teams), it's the opposite. There is a ton of value of being able to be able to move up and down the stack -- Sales, Product, Design, Frontend, Backend, Devops... and pinch hit in any job capably as needed.
• falcolas 8y ago
  Server Administration. Nobody thinks you need to have the skills of how to administer a Linux machine, until you do. In one example, understanding how to strace a deadlocked series of microservices saved a month or so of "add logging" cycles. Database Administration. Another "you don't need it until you do" skill. Being able to track down the cause of a CPU bottleneck to a poor DB config saved the company the operational cost of 4 additional DB servers, not to mention the development cost of utilizing read replicas and write masters in the same code. Re-emphesizing one mentioned previously: Writing. English is a fairly imprecise language and your processing nodes are way more flaky, but both can be worked around; need to be worked around on an almost daily basis.
  • twoquestions 8y ago
    Know of any good books or other content to learn how to do this? Or is the best way to read a ton of man pages?
• rajacombinator 8y ago
  See what the places he’s applying to are looking for, learn that. Seems like Rails is popular still.
• pragmatic 8y ago
  1) have decent experience 2) be decent at interviews I've had more than one promising candidate that just blew the phone screen or interview for various reasons. Speak up, don't mumble, don't take the call in a coffee shop or outside in the wind ffs. You'd be surprised how much this affects my hiring decision (continue on the process and explain to my team/boss why I recommended a mumbler with a barking dog).
• rajeshpant 8y ago
  As other people are pointing out specific skills, I would like to tell you that it is a totally wrong approach to start with. There are only few lucky people who start with a very niche technology. Let's say you are graduating from Masters and you luckily get a job in AI/ML niche. For most people, they start with easy stuff. Skills which are not niche, which are fairly known. You slowly get accustomed and start working in it and pick related technologies from there and keep moving. I would suggest start with any kind of web programming(html, css, any backend language) and explore from there. Also, enterprise products/technologies are pretty niche but they have a high barrier of entry. But once you know any web programming(either UI or backend), it is pretty easy to switch to these niches. Just start and keep going.
• EnderMB 8y ago
  Public speaking and the ability to pitch ideas is perceived as very valuable to client-facing businesses. In terms of career progression, a lot of companies are more willing to hand control to a developer that can articulate their ideas to a non-technical person, or display confidence in their skills to a room of external stakeholders. Additionally, the ability to sell yourself or an idea to others is a great one if you're in the startup space, or working with startups.