Clojure resume tips?

[Jason Basanese]

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

[Gary Trakhman]

I'd put examples of interesting (hard, nontrivial) projects you worked on during your time, not just keywords.  The function of the resume is to motivate someone to look deeper instead of throwing it out.  The function of the top of the resume is to hook someone to read the rest of it.  What's special about you?  You can pack a lot into a single page, I think yours has a lot of whitespace.  Does your school have a resume workshop or something like that?

On Thu, Mar 23, 2017 at 1:10 PM Jason Basanese <jason.b...@gmail.com> wrote:

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Moe Aboulkheir]

Jason,

If it were my resumé, I would consider including only the technologies I had interest in working with professionally.  Getting involved in collaborative open source development (i.e. contributing to established projects) is likely to increase your confidence, as well as that of a prospective employer - you could consider shunting off the coursework details (or listing those as "Interests", if they're interests) if you had some voluntary development to put in its place.  Other ways to fill out space while improving content would be to include a generic (i.e. not job-specific) introduction beneath the heading, or using complete sentences for the job description at the bottom.  If you go with bullet points, using a list indicator might make this clearer.

As far as visual feedback: it might scan better if the section headings in the left column were kept to single words (i.e. no line breaks), and were vertically justified with the top of corresponding piece of text in the adjacent column (using a table with invisible borders).  The alignment of the info icons (which are a good call) is off in a similar way, and that block does not appear horizontally centred to me.  Some colour variation may help also - examples would be converting the urls into links (with the url as the link text, for printing), or using a dark shade of grey for heading or title text.

Take care,

Moe

On Thu, Mar 23, 2017 at 5:10 PM, Jason Basanese <jason.b...@gmail.com> wrote:

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Luke Burton]

On Mar 23, 2017, at 10:10 AM, Jason Basanese <jason.b...@gmail.com> wrote:

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

Couple of general tips … based on a few decades of looking at these things :) Sorry about the length but I care a lot about hiring!

* Redact your home address and phone number when you circulate it on the open internet. I wouldn't even include that in a resume I sent to an organization, personally.

* Resumes are the worst. There's almost no correlation between "things the candidate had on his/her resume" and "that candidate is performing really well for us 2 years later", but we persist in using them because everything else is a lot more work. Just keep that in mind before you think there's something "wrong" with your resume.

* Resumes should be considered a marketing document. A classic new grad mistake is to think that what hiring mangers and recruiters are looking for is a complete transcript and accurate information. What they're actually looking for is purely subjective. I could tell you stories - resumes skipped over for the dumbest of reasons. After looking through hundreds, people start cutting corners or just plain discriminating. So, think of it as serving roughly the same purpose as a blurb on the back of a paperback novel.

* To play along with the resume game, I recommend customizing your resume to the greatest extent possible based on what you know about the job. That's "the job" singular, as in you need to do this for each application. It's easy to carpet bomb the same resume across many companies, but you simply won't stand out. You are on the right track here already - what would make it appealing to places looking for functional developers? Take it a step further and find those places, then write something that specifically targets them. Remember it's not just about keywords, you also have to come across as someone who might fit the culture.

* To avoid (or supplement) playing the resume game, build relationships. Keep all your projects up on GitHub, find and cultivate things you want to stick at and improve, and start getting to know people. Meetups, fixing issues on other people's projects, it doesn't have to be super involved, it just has to be an involvement. The absolute best jobs you will ever land will come from people who know the quality of your work and recommend you from the inside. 

* I am a huge fan of Thomas Ptacek's perspective on hiring. Very much worth your time to read. If you can find a company that asks candidates to write some code - actual code like you'll be writing on the job, not a graph traversal puzzle - then jump on that chance. I started applying these techniques and we immediately experienced an inversion between who we thought looked strong on paper and who ended up being a great engineering fit for our team. This candidate we hired would have flunked the keyword filter had we used one, they had not used a single technology in common use for our team. Eye opening. 

* So … if I was in your position, knowing what I know now, if I couldn't find companies that had very progressive hiring practices, I would make my resume stand out by leading in with an offer to spend a few hours writing a small implementation of anything the hiring manager would like me to write. Many hiring mangers are scared by take home projects because they're afraid of what the best candidate will think. "It's an insult to experienced candidates!" or "how would a rockstar candidate possibly spare the time?" But secretly I think all hiring mangers *really* want to know what it will be like to have you write code on their behalf. It's just not the industry norm to ask.

Hope this helps! Good luck …

Luke.

[Mark Engelberg]

On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton <luke_...@me.com> wrote:

* So … if I was in your position, knowing what I know now, if I couldn't find companies that had very progressive hiring practices, I would make my resume stand out by leading in with an offer to spend a few hours writing a small implementation of anything the hiring manager would like me to write. Many hiring mangers are scared by take home projects because they're afraid of what the best candidate will think. "It's an insult to experienced candidates!" or "how would a rockstar candidate possibly spare the time?" But secretly I think all hiring mangers *really* want to know what it will be like to have you write code on their behalf. It's just not the industry norm to ask.

Insightful post about a lot of things related to hiring, but I have to take exception with this very last point.  Recently, a friend of mine sought out a data science position in the Seattle area.  Each prospective employer gave him a take-home assignment that required 30-40 work hours to complete.  Some of the assignments were real problems the company was facing, so he was effectively being asked to do free consulting work for each company.  This is a horrible, burdensome interview practice and it would be dreadful if it became the norm in the software industry. Suggesting that someone offer to do a take-home project may make sense in specific cases for an inexperienced candidate, but I fear it starts our industry down the slippery slope.

[Luke Burton]

I definitely share the concern. 30-40 hours is totally not what I'd consider a take home project. I also think "real problems facing the company" has a host of issues associated with it, including the one you pointed out which is that it blurs the line between free labor and hiring pipeline. While I believe that a hiring pipeline this onerous is very unlikely to catch on and be the industry norm, I would put forward the proposal that a take-home project must *not* be work that directly contributes to the hiring company's value stream. 

I'd like to give you a sense of how I approached this problem, just to give a counterexample that is maybe more hopeful:

* We encouraged the candidate to have fun with the problem! The goal was not to stress them out under a deadline, but to give them enough time to relax into their normal engineering mindset. They could use any resource they liked, any framework or language they felt would suit the solution.

* They got to pick their own starting date, and deliver us a self-contained artifact of some kind a week later. Having to write "hand off" instructions was surprisingly telling! It was also surprising to see a candidate's git repo, to see how their solution evolved over time.

* The project was very, very general in specification. Almost uncomfortably open ended. I value candidates that can work with loose specifications, but I also wanted to let the candidate decide what they felt was "done" enough to share. And I wanted to ensure it wasn't possible to find canned solutions on the internet (Facebook found that their iOS candidates became increasingly adept at writing exactly the same tic-tac-toe interfaces, hmm …) 

* Their project solution would be the primary focus of any in-person interviews we followed up with. This is no small point, it really gave those interviews a sense of structure and purpose that I had not seen before. The candidate's memory for their code is fresh and they feel confident, while the interviewers all had plenty of good questions having checked out the candidate's repo and deep dived into it.

There was other minutiae specific to the role and company that isn't interesting here, but hopefully that gives some sense of how I tried to balance the various concerns. I think it parallelizes nicely too, in the future I would not hesitate to send a project like this out to *everyone* who submitted a resume, just to see what comes back. 

I guess I've spilled this many words I may as well share what the project was. Aside from lots of preamble explaining the above, what I sent out was:

The city of San Francisco has an open data repository located at data.sfgov.org. The amount of available data is pretty impressive. Your task is to create a composite metric for city restaurants, based on at least two variables from data in the repository. It need not take itself too seriously, if you want to rate a location based on its seismic activity and wind speed, go for it. It could be qualitative or quantitative. 

The end result should be a full stack web application that gives us the ability to browse or search your calculated results. We'd like to see what you can do in a week. Keep it simple! A working, but simple result is more impressive than a complicated, but half-finished result.

At the heart of it I'm really asking them to embark on a small descriptive statistics problem. They have to ingest some data, calculate a score based on potentially uncorrelated data points, and present it. All in a self-sufficient web application. The results were really, really revealing. 

I am looking forward to trying this on Clojure / ClojureScript positions in the future :) But I guess I'll have to change the problem now!

Luke.

[James Gatannah]

On Thursday, March 23, 2017 at 2:00:28 PM UTC-5, puzzler wrote:

On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton <luke_...@me.com> wrote:

 

Insightful post about a lot of things related to hiring, but I have to take exception with this very last point.  Recently, a friend of mine sought out a data science position in the Seattle area.  Each prospective employer gave him a take-home assignment that required 30-40 work hours to complete.  Some of the assignments were real problems the company was facing, so he was effectively being asked to do free consulting work for each company.  This is a horrible, burdensome interview practice and it would be dreadful if it became the norm in the software industry. Suggesting that someone offer to do a take-home project may make sense in specific cases for an inexperienced candidate, but I fear it starts our industry down the slippery slope.

It's not quite on-topic, since this is a post-resume story.

But once upon a time I worked at a company where a fairly senior candidate was asked about whatever real-world problem the interviewer was working on at the time. I think it was a relaxed "So, how would you approach this particular scenario?" big-picture kind of question.

We didn't hire him.

He sent us a bill for an hour of consulting.

The legal department told us to pay it and never, ever, under any circumstances, ask any question that could be remotely construed as relevant to our actual business needs.

Personally, I enjoy the little "Spend a couple of hours knocking this out" challenges, as long as I don't get graded on criteria that wasn't mentioned up front ("Our internal style guide, which you've never seen, dictates that you must do X"). But I'm at the point where I'd rather point people to github so we can talk about real projects that actually have serious time/thought investments.

And, on the flip side, I'd rather look at what a candidate's done there, even if it does take more time/effort on the hiring side than seeing how they approach a cookie-cutter project.

[James Gatannah]

To get back on-target, I think you should highlight 1 or maybe 2 of your github repos and go flesh them out.

I had high hopes for both click-time-fun and cljs-game, but wasn't sure what to try or where to start. Working demos are pretty magical, and, honestly, incredibly rare.

https://github.com/noffle/art-of-readme has some advice that I've been planning to take to heart for a while now about how to help other people understand what your projects are about.

That probably won't help your resume get through the original HR screen, but it can definitely make interviewers stand up and take notice.

Good luck,

James

[Gregg Reynolds]

On Mar 23, 2017 2:00 PM, "Mark Engelberg" <mark.en...@gmail.com> wrote:

On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton <luke_...@me.com> wrote:

* So … if I was in your position, knowing what I know now, if I couldn't find companies that had very progressive hiring practices, I would make my resume stand out by leading in with an offer to spend a few hours writing a small implementation of anything the hiring manager would like me to write. Many hiring mangers are scared by take home projects because they're afraid of what the best candidate will think. "It's an insult to experienced candidates!" or "how would a rockstar candidate possibly spare the time?" But secretly I think all hiring mangers *really* want to know what it will be like to have you write code on their behalf. It's just not the industry norm to ask.

Insightful post about a lot of things related to hiring, but I have to take exception with this very last point.  Recently, a friend of mine sought out a data science position in the Seattle area.  Each prospective employer gave him a take-home assignment that required 30-40 work hours to complete. 

hardy har har.  the correct response to this is "my fee is $200/hr".  seriously, i would not hire anybody dumb enuff to consent to this kind of "interview". that companies even try it boggles the mind.

[Gregg Reynolds]

On Mar 23, 2017 12:10 PM, "Jason Basanese" <jason.b...@gmail.com> wrote:

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

nobody ever gets hired on the strength of their resume. at best they get an interview. almost every hire for an interesting job comes from personal connection. forget your resume and start networking, contributing to os projects, wtc.

[Jason Basanese]

Thanks for the response Luke. You make a lot of good points. Thomas Ptacek's article was eye opening. The suggestion to ask the hiring manager if they would like a sample of me doing company related work for them is a good one. The networking tip is one I hear time and time again, but the more I hear it the more I believe it. Also thanks for being somewhat specific on what you mean when you say networking. Overall this post has helped me get a picture of what a good job search or rather network building looks like. Again thanks for taking the time to write this post.

[Jason Basanese]

I had never thought of a resume this way "The function of the resume is to motivate someone to look deeper" thanks.

[Jason Basanese]

Getting involved in collaborative open source development (i.e. contributing to established projects) is likely to increase your confidence, as well as that of a prospective employer. This is a good point I see echoed in a few other posts. Thanks for the tip. 

In my case and I imagine in the case of many curious younger developers we do not have strong enough opinions nor preferences for this yet; I would consider including only the technologies I had interest in working with professionally.

On Thursday, March 23, 2017 at 1:54:25 PM UTC-4, Moe Aboulkheir wrote:

Jason,

If it were my resumé, I would consider including only the technologies I had interest in working with professionally.  Getting involved in collaborative open source development (i.e. contributing to established projects) is likely to increase your confidence, as well as that of a prospective employer - you could consider shunting off the coursework details (or listing those as "Interests", if they're interests) if you had some voluntary development to put in its place.  Other ways to fill out space while improving content would be to include a generic (i.e. not job-specific) introduction beneath the heading, or using complete sentences for the job description at the bottom.  If you go with bullet points, using a list indicator might make this clearer.

As far as visual feedback: it might scan better if the section headings in the left column were kept to single words (i.e. no line breaks), and were vertically justified with the top of corresponding piece of text in the adjacent column (using a table with invisible borders).  The alignment of the info icons (which are a good call) is off in a similar way, and that block does not appear horizontally centred to me.  Some colour variation may help also - examples would be converting the urls into links (with the url as the link text, for printing), or using a dark shade of grey for heading or title text.

Take care,

Moe

On Thu, Mar 23, 2017 at 5:10 PM, Jason Basanese <jason.b...@gmail.com> wrote:

Attached is a fairly bad resume that I am using. Any tips on how I might change it to appeal to more places that are looking for functional developers?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Jason Basanese]

I might think that 30-40 hours for a sample is excessive. Honestly many candidates worry and or prepare for at least two hours for an interview. Then have around an hour round trip. They also might spend a full hour in an interview. With about four hours to replace or supplement an interview you are getting much better results for the same time cost. Maybe even less stress for the applicant.

[Jason Basanese]

He sent us a bill for an hour of consulting. Wow, noted. Maybe I would be more hesitant to give questions directly related to the job if I ever found myself interviewing.

[Jason Basanese]

Hmm. I never really considered anyone would try to use them outside of just looking at the source code. You have made me second guess that. I definitely will consider adding ReadMes. Also thanks for the link.

[Jason Basanese]

Thanks, I have been told this before. After hearing it a couple more times I am taking it much closer to heart.

[Gregg Reynolds]

On Apr 18, 2017 2:16 PM, "Jason Basanese" <jason.b...@gmail.com> wrote:

Thanks, I have been told this before. After hearing it a couple more times I am taking it much closer to heart.

also check-out #jobs-discuss on the clojurians slack thing.  this kind of question would be welcome there, i think.