Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Uncommon but attainable programmer skillsets valued by employers?
128 points by Lordarminius on Apr 23, 2018 | hide | past | favorite | 98 comments
Was having a discussion with a programmer when this popped up. He has applied to various (remote) positions without success. (I tried this as well earlier, but gave it up to found a startup) How can he stand out ?

Lets leave out AI and ML for now.

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

[2] my personal breakdown: 50% luck, 40% perseverance, 10% ability to retain details

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.

Well, its the age old pragmatism versus idealism dichotomy. One isn't better than the other, except sometimes.


I don't feel "agile" is the same as being smart about scope cuts, or about shaving yaks that aren't in the way, so I'm left feeling that your comment was ...a bit of a shitty place to drag the discourse. :)

In other words then, I'm more inclined to think of what I was saying as that it may be better to hold off on shitting at all if you're having a hard time, than to decisively shit your pants long after you've left the toilet.

I always thought that "agile" was "you're doing it wrong".

It's a useful skill, but not a good career move. Early in my career, I used to fix bugs in a mainframe operating system. When I took a new job, I was given two stacks of paper crash dumps, each six feet high. I had to figure out what had caused each crash with paper and pencil, then fix the assembly code. It took me about a year to get the mean time to failure of the OS from a day to a month.

Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause.

I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom.

(This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)

I developed this skill because of a combination of social anxiety and wanting to keep my first job.

I agree with this wholeheartedly.

As an engineering candidate, how do I display these traits?

As an interviewer, how can I test for these traits?

As a candidate, when there are companies I'm interested in working at I research the hell out of them. A lot of companies will put employees on their website and I will research the profile of every person on it. If they don't, I find all the employees I can other ways. If they have an engineering blog I read everything I can, then I research the authors. I research the investors, the market, including competitors and any analyst commentary I can find. I look for past employees and try and calculate a rough idea of churn rate. I basically build as perfect a model of the company as I can as an outsider, and then I test the model throughout the interview process, updating as I go. I make it clear to people that I've done this through ways both subtle and obvious. "I noticed on your profile you were at X last, did you work with Y?" "From my research it seems like your CTO left earlier this year, can you tell me the story behind that?" "This journalist says you're doomed, which is funny because you don't look doomed, but what would you say to them if you could talk to them directly?" Etc.

Yes, this involves a lot of online stalking people. Honey badger doesn't care.

> As an interviewer, how can I test for these traits?

This is one trick I haven't figured out.

I can ask problems that require tenaciousness to dig all the way to the bottom. BUT motivations and incentives in a 45min interview and an ongoing job are very different. There's a higher reward in the job interview, and you know an upper bound to how much time it'll take.

I've hired people who aced that, but then were pretty lazy day to day, even for looking up trivial stuff like "you submitted a python code review that wouldn't even run because you made a typo in the method name."

Stories can help, but stories are (even assuming true and not borrowed) from a past version of the candidate which may not be the same as the present version.

So I just do the best I can, but also recognize that I won't necessarily get a 100% perfect employee no matter what questions that I ask. But "pretty good" is about all you can realistically hope for, I think.

You need to be your own honey-badger. :)

There are two very important tests to consider hiring someone:

- how a candidate handles feedback and negative situations like disapproval and rejection

- whether they delegate thinking or take ownership of solving hard problems

If they fail either, that’s a deal-breaker. Also, make the candidate pipeline as uniform, fair and repeatable as possible.

- anonymizing resumes by masking pedigree, names, addresses, etc.

- ask generally the same questions, while branching differently based on their responses

- perform social and skills tests as similarly as possible

”Be the change you seek”

In my experience, a lot of interviewers will ask questions along the lines of "What's the trickiest problem you've had to deal with?" I feel like those kinds of questions are excellent for bringing up this sort of thing if the candidate is so inclined. If they go in a different but still not disappointing direction (e.g. coming up with a process for stable development an environment where requirements are constantly changing), you might re-ask with the focus more on problems encountered while coding.

And, to paraphrase another poster, be a honey badger about it. "And then what happened? And then? Why did you do it this way? Why did that fail? Why did <cause of failure> happen?" until you get to the bottom of the story or hit a wall ("dunno. My boss took care of that"). If the candidate can explain what the root cause of the problem was, how they identified that root cause and then proceeded to fix it, that gives you a pretty good idea of how tenacious they are.

Well, if you have such a trait then you can figure it out yourself.

Great skill, but a far better skill is knowing when to give up and move on from the problem instead of wasting days on something while other backlog work piles up.

Well that applies to every task, not just to problem solving. "Work hard" doesn't imply "neglect your wife and kids".

That's a good way to only be assigned easy tasks.

This is basically my only skill. I just don't stop google'ing for answers. If i run into something I just keep working until it works.

I think most of the problems a honey badger solves aren't google-able.

Parent comment could refer to self study in a domain until they know enough about what's in front of them to better tackle the problem.

As someone who is an alt student, working as SFE while going to school at a traditional University, I've noticed the opposite of this mentality a lot. Expectations of being told how to do everything and literally getting upset when the prof doesn't give them enough. Will note though the guys who are also alt students, surprisingly higher than I remember/noticed when doing my first undergraduate, tend to not have this mentality and are usually the people I talk to when I am really having issues. Feel like this is something that took me entirely too long to learn or at least too long to realize that I needed to learn it. I'm sure I was the same way when I was 19-22. Just thought this comment stood out don't care to get into the failings of academia.

I think my relative success comes down to one basic thing: When I learn new things, I focus on essentials first, and always. I gain normal skill like anyone, but I do feel like I retain the essentials better than the next hacker. I can't recall a time I've ever said, "oh, I used to know _____ but it's been too long." I've always been able to get back into old saddles. It's been like this most of my 25 years in the industry.

Relevance: retaining essentials confers ability to honey-badger more things in more ways.

I came in here to post exactly this. It's hard to demonstrate but I will take time to listen to a candidate if they have a horror story about debugging something painful.

Occasionally there will be a post on HN about someone who debugged a compiler bug or a even a hardware bug, and it lifts my spirits.

The danger here is that you have to make sure Honey Badger's manager doesn't see him/her seemingly making no progress toward a solution. Honey Badgers might be solitary animals, but software engineers are social creatures.

I agree that these are useful ways of solving problem, but its rarely that anyone asks about that sort of skill in an interview.

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.

can you recommend a good UI book?

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

Don't make me think

Design for hackers.

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-whe...

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.

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?

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.

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.

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.

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...

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.

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.

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.

My problem is that my other domain of expertise is biology. Bioinfomatics jobs generally pay less than straight Software Engineering where I am (a lot of the work is just counting things).


My CV has health IT written all over it, but sometimes I fear being pigeonholed. Yes, I know what FHIR / HL7 is.

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.

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?

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.

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.

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/, 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.

Downloaded it and ordered the paper copy, thanks :)

What would you advise looking into in regards to formal methods? Any particular software, books, or talks?

Concrete Semantics is an excellent free book http://www.concrete-semantics.org/ written by some well-known names in the field. It's a good place to begin.

The book itself contains references to much more advanced works such as Nielson & Nielson or TAPL. It doesn't cover one part of formal methods, (probabilistic) model checking.

Thanks for this -- I've been looking for recommendations on resources for HOL and this looks like a good one.

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.

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.

Exactly, you might want to be the consultant

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.

go to conferences, develop your charisma, get older, know people

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.

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?

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.

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.

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.

> 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.

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.

This and/or the org can't find local talent either b/c of pay or reputation. Glassdoor is helpful on both fronts but especially the latter.

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).

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.

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.

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.

Reading code, particularly as a beginner in the industry.

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.

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.

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.

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?

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.

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.

Agreed, nobody reads code. Also nobody considers "debuggability" when picking languages/libraries/frameworks/etc.

Social skills.

But such skills are insanely hard to attain. Some people simply give up on trying.

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.

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.

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.

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.

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.

Screw that. I prefer to keep fit and get outdoors to clear my head.

Writing skills, specially fluid, precise technical writing skills.

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.

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

How to sell

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...)

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.

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.

The address is probably the most important. It's really hard to find remote job.

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.

And your resume is a great opportunity to 'show' rather than 'tell' this.

See what the places he’s applying to are looking for, learn that. Seems like Rails is popular still.

One word: Haskell

Interesting. Haskell programmers are scarce enough that just knowing the language makes a difference ?

Unlikely to be true in general. I'm having no troubles hiring Haskell developers.

Hiring good front-end developers on the other hand....

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact