mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge branch 'master' of https://github.com/LCTT/TranslateProject
This commit is contained in:
runningwater
commit
ef919811a8
108
sources/talk/20181129 9 top tech-recruiting mistakes to avoid.md
Normal file
108
sources/talk/20181129 9 top tech-recruiting mistakes to avoid.md
Normal file
@ -0,0 +1,108 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (9 top tech-recruiting mistakes to avoid)
|
||||
[#]: via: (https://opensource.com/article/18/11/top-tech-recruiting-mistakes-avoid)
|
||||
[#]: author: (Rikki Endsley https://opensource.com/users/rikki-endsley)
|
||||
[#]: url: ( )
|
||||
|
||||
9 top tech-recruiting mistakes to avoid
|
||||
======
|
||||
We round up common mistakes tech recruiters make and a few best practices to adopt instead.
|
||||
|
||||
|
||||
Some of my best friends and colleagues are tech recruiters, and a bunch of my favorite humans are on the job hunt. With these fine folks in mind, I decided to help them connect by finding out what kinds of recruiting efforts stand out to potential hires. I reached out to my colleagues and contacts and asked them what they like (and hate) when it comes to recruiting, then I rounded up a list of top tech-recruiting mistakes to avoid and best practices to use instead.
|
||||
|
||||
### 9 common tech recruiting mistakes to avoid
|
||||
|
||||
Don’t even think about reaching out to a potential candidate without doing due diligence on their background, experience, and expertise. Not knowing what skills a recruit has and what kind of work they’ve done in the past instantly turns off job seekers. Recruiters who make it clear that they’ve done their homework signal that they aren’t planning to waste a candidate’s time and stand a better chance of piquing their interest from the beginning. Common recruiting mistakes also include:
|
||||
|
||||
**1\. Sending form letters — or even worse, broken form letters.**
|
||||
|
||||
Unless someone is job-seeking and not getting many offers, chances are your form letter won’t stand out or get much interest. And if your form letter is broken and has [NAME] where a candidate’s name should appear, forget about getting any qualified candidate responses.
|
||||
|
||||
**2\. Blowing the salutation.**
|
||||
|
||||
Be sure to spell the candidate’s name correctly, and typing “Mr.” or “Miss” in the greeting could be a big mistake. For example, I can’t tell you how many “Mr. Endsley” messages I get every month, and “Miss Endsley” won’t sit well with me, either.
|
||||
|
||||
**3\. Not understanding what the recruit does.**
|
||||
|
||||
Potential candidates can tell whether you’ve done your homework, dug through their LinkedIn profiles, and have a grasp of their backgrounds, experiences, and areas of interest. Reaching out to a UX designer about an engineering role won’t get you good results.
|
||||
|
||||
**4\. Sending unsolicited contact requests.**
|
||||
|
||||
Don’t send LinkedIn connection requests to people you don’t know. Just don’t do it.
|
||||
|
||||
**5\. Being too general about the job position.**
|
||||
|
||||
Kill the coy. Share as many details you can about the role, including any must-have and nice-to-have skills. Draw potential recruits a picture of what the work looks like to make qualified candidates take notice.
|
||||
|
||||
**6\. Being too vague or mysterious about the team and company.**
|
||||
|
||||
Tech professionals with in-demand skills and experience are being more selective about what kind of team dynamics they walk into and [organizational ethics][1]. Letting potential hires know right away what the team looks like (e.g., small vs. large, remote vs. on-site) and which company you represent can save everyone a lot of time.
|
||||
|
||||
**7\. Having unrealistic or overly specific requirements.**
|
||||
|
||||
Does the right candidate really need to be an expert in every technology and programming language and hold multiple degrees? Be clear about what skills a candidate needs vs. what skills might come in handy or can be acquired on the job.
|
||||
|
||||
**8\. Getting too cutesy or culture-y in a description.**
|
||||
|
||||
Not all of us consider office puppies, free booze, and ping pong to be job perks. If this is the messaging you lead with, you’re going to attract a pretty specific kind of applicant and quickly narrow down your list of potential candidates.
|
||||
|
||||
Also [avoid terms][2] like “guys,” “rock star,” and “recent graduate,” which can translate to “women, minorities, and anyone over 25 need not apply.” Ouch.
|
||||
|
||||
**9\. Asking for referrals to other potential candidates.**
|
||||
|
||||
This is a no-win for recruiters. For example, I’m happy to recommend job seekers in my network for roles, but lots of other folks working in tech see this as lazy recruiting. The safest approach might be to ask a candidate later in the process, after you’ve developed a friendly working relationship and you've both agreed that this role doesn’t quite fit their interests or expertise. Then they might have other contacts in mind for it.
|
||||
|
||||
### 6 best practices for tech recruiters
|
||||
|
||||
**1\. Provide a sincere and personalized greeting.**
|
||||
|
||||
A personalized greeting goes a long way. Let potential candidates know you understand their previous work experience, you’re familiar with what they do, and that you have an idea of what they want to be doing.
|
||||
|
||||
|
||||
**2\. Offer a transparent description of the team and the role.**
|
||||
|
||||
Be as clear as you can when describing the team and the role. Using words like “rock star” or “fast-paced team” does nothing to help the potential candidate visualize what they’d be walking into. Is this a small team? Remote team?
|
||||
|
||||
Being mysterious about the role won’t build intrigue, so opt for transparency.
|
||||
|
||||
**3\. Give the company name.**
|
||||
|
||||
Telling job candidates that the organization is a startup or a Fortune 500 company also won’t work as well being transparent about the organization from the beginning. How can anyone know whether they’re interested in a role if they don’t know which organization they’d be joining?
|
||||
|
||||
**4\. Be persistent and specific.**
|
||||
|
||||
In addition to providing the job description and company name, specifying the salary range and why you think the potential candidate is a good fit for the role stands out. Also consider specifying the work authorization and whether the organization provides visa sponsorships, relocation, and additional benefits beyond an hourly or annual salary. If you have a good feeling about a candidate who might not be a 100% technical fit with the job posting, let them know and open those lines of communication.
|
||||
|
||||
**5\. Invite potential candidates to local recruiting events.**
|
||||
|
||||
The event should provide brief presentations about the company, refreshments, and a networking opportunity. Here’s your chance to show off the culture (i.e., people) part of your organization in person.
|
||||
|
||||
**6\. Maintain a relationship with potential recruits.**
|
||||
|
||||
If you talk to a candidate who isn’t the right fit for a role, but who would be a great addition to your organization, keep the lines of communication open. If candidates have a good experience with a recruiter, they’ll also be more inclined to join the organization later or send other job seekers their way in the future.
|
||||
|
||||
### Bonus advice for tech recruits
|
||||
|
||||
Keep in mind that recruiters, like you, are just trying to do their jobs. If you're tired of hearing from recruiters and annoyed when they contact you, step back and get a little perspective. Although you might be in the fortunate spot of being happily employed and in-demand, not everyone else is. Grumbling about recruiters on social media is a great way to humble brag, but not the best way to show empathy for the job-seekers or win any friends.
|
||||
|
||||
_Thank you to the many people who contributed to this article! What would you add to these lists? Let us know in the comments._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/top-tech-recruiting-mistakes-avoid
|
||||
|
||||
作者：[Rikki Endsley][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/rikki-endsley
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://spectrum.ieee.org/view-from-the-valley/at-work/tech-careers/engineers-say-no-thanks-to-silicon-valley-recruiters-citing-ethical-concerns
|
||||
[2]: https://www.theladders.com/career-advice/job-descriptions-driving-away-women
|
||||
@ -0,0 +1,68 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Why giving back is important to the DevOps culture)
|
||||
[#]: via: (https://opensource.com/article/18/11/why-sharing-important-devops-culture)
|
||||
[#]: author: (Matty Stratton https://opensource.com/users/mattstratton)
|
||||
[#]: url: ( )
|
||||
|
||||
Why giving back is important to the DevOps culture
|
||||
======
|
||||
Our habit of not sharing knowledge is doing us harm.
|
||||
|
||||
In the DevOps [CALMS][1] model (which stands for Culture, Automation, Lean, Measurement, and Sharing), Sharing is often overlooked or misunderstood. While each element of CALMS is just as important as the others, sharing knowledge is something that we often neglect.
|
||||
|
||||
### What happens if we don't share?
|
||||
|
||||
[Jeff Smith][2], director of production operations at [Centro][3], tells this story:
|
||||
|
||||
> A change to the level of granularity that gets stored in one of our reporting tables was made. The change increased the disk space usage on the database instance by 8x. Not only did this cause our existing database instance to rapidly fill up, but it also made operations question if the design pattern made sense. Because they weren't included in such an impactful change, all of the design decisions that went into the new process architecture were viewed as suspect and underwent a constant re-examination from ops. In a nutshell, a little bit of faith and trust was lost.
|
||||
|
||||
The damage caused by eroding faith can't be understated. Collaboration is based on trust. Every time this trust is chipped away, energy is spent on questioning the validity of decisions made by others.
|
||||
|
||||
### What are the benefits of sharing?
|
||||
|
||||
Today's systems are incredibly complex. The days when one person could hold an entire infrastructure and system interdependencies in their head are long gone. Communicating across boundaries of expertise makes our entire organization more robust and resilient.
|
||||
|
||||
Sharing isn't just about the technical data or access, though. "Inter-team communication should always start with the goal, not with one team's proposed solution to a problem," Jeff says. "When you start with a solution, the conversation veers in the wrong direction."
|
||||
|
||||
[Emily Freeman][4], CloudOps advocate at [Microsoft][5] says "Collaboration is impossible without sharing information." She points out that having a "mental map" of the skills and knowledge of other teams "enables people to ask questions more efficiently and reduces the fear they're asking too many questions or look stupid."
|
||||
|
||||
### How can we share better?
|
||||
|
||||
"Sharing doesn't have to be a drum circle every Tuesday at 10:30am," Emily says. "It's openness and authenticity. It's removing the shadows from your organization and ensuring everyone is honest and forthright and accountable."
|
||||
|
||||
At a minimum, there should be read-only access to logs, code, and after-incident reports for everyone. Before you cry "separation of concerns," please consider that the data that cannot be shared with everyone in the organization is a much smaller set than we usually think it is. It might require some additional effort to scrub and protect this small subset than to default to "nobody can see anything but their small part of it," but the benefits outweigh the effort.
|
||||
|
||||
"If anyone's excluded, they aren't part of your team, no matter what the org chart says," Emily reminds us.
|
||||
|
||||
It's more than the logs and the tooling, though. "The 'S' is often just seen as knowledge sharing, training, etc.," Jeff says. "But if it doesn't include the sharing of responsibility and ownership, it can be difficult to get your organization to that next level of productivity."
|
||||
|
||||
### Why don't we share?
|
||||
|
||||
There are many reasons that sharing information and knowledge isn't the default position for knowledge workers, but both Emily and Jeff agree it usually comes down to fear.
|
||||
|
||||
"Teams may feel that only their circle is capable of performing a particular task with the zeal and delicacy it deserves," Jeff says. "So information gets siloed, access gets restricted, and gates get constructed. But that diminishes our responsibility to build safe systems, instead leaning on 'operator expertise' as a crutch."
|
||||
|
||||
Emily agrees. "DevOps cultures never look to change the past," she says. "Instead, the companies that thrive at embracing the DevOps philosophy are realistic about where they are and work toward continuously improving their process so everyone on the team can thrive."
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/why-sharing-important-devops-culture
|
||||
|
||||
作者：[Matty Stratton][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mattstratton
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://whatis.techtarget.com/definition/CALMS
|
||||
[2]: https://twitter.com/DarkAndNerdy
|
||||
[3]: https://www.centro.net/
|
||||
[4]: https://twitter.com/editingemily
|
||||
[5]: http://dev.azure.com/
|
||||
@ -0,0 +1,125 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Boxing yourself in on the Linux command line)
|
||||
[#]: via: (https://opensource.com/article/18/12/linux-toy-boxes)
|
||||
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
|
||||
[#]: url: ( )
|
||||
|
||||
Boxing yourself in on the Linux command line
|
||||
======
|
||||
Learn how to use the boxes utility to draw shapes with characters at the Linux terminal and make your words stand out.
|
||||
|
||||
|
||||
It's the holiday season, and every Linux terminal user deserves a little gift. It doesn't matter whether you celebrate Christmas, another holiday, or nothing at all. So I'm gathering together a collection of 24 Linux command-line toys over the next few weeks for you to enjoy and share with your friends. Let's have a little fun and add a little joy to a month that, at least here in the northern hemisphere, can be a little bit cold and dreary.
|
||||
|
||||
Chances are, there will be a few that you've heard of before. But, hopefully, we'll all have a chance to learn something new. (I know I did when doing some research to make sure I could make it to 24.)
|
||||
|
||||
The first of our 24 Linux terminal toys is a program called boxes. Why start with boxes? Because it's going to be hard to wrap up all of our other command-line presents to you without it!
|
||||
|
||||
On my Fedora machine, boxes wasn't installed by default, but it was in my normal repositories, so installing it was as simple as
|
||||
|
||||
```
|
||||
$ sudo dnf install boxes -y
|
||||
```
|
||||
|
||||
If you're on a different distribution, there's a good chance you'll find it in your default repositories as well.
|
||||
|
||||
Boxes a utility I really wish I had in my high school and college computer science courses, where well-intentioned teachers insisted I provide very specific looking comment at the beginning of every source file, function, code block, etc.
|
||||
|
||||
```
|
||||
/***************/
|
||||
/* Hello World */
|
||||
/***************/
|
||||
```
|
||||
|
||||
It turns out, once you add a few lines of text inside, formatting them can get, well, tedious. Enter boxes. Boxes is a simple utility for surrounding a block of text with an ASCII art-style box. It comes with defaults for source code commenting, as well as other options.
|
||||
|
||||
It's really easy to use. Using pipes, I can push a short greeting into a box.
|
||||
|
||||
```
|
||||
$ cat greeting.txt | boxes -d diamonds -a c
|
||||
```
|
||||
|
||||
Which will give us the output as follows:
|
||||
|
||||
```
|
||||
/\ /\ /\
|
||||
/\//\\/\ /\//\\/\ /\//\\/\
|
||||
/\//\\\///\\/\//\\\///\\/\//\\\///\\/\
|
||||
//\\\//\/\\///\\\//\/\\///\\\//\/\\///\\
|
||||
\\//\/ \/\\//
|
||||
\/ \/
|
||||
/\ I'm wishing you all a /\
|
||||
//\\ joyous holiday season //\\
|
||||
\\// and a Happy Gnu Year! \\//
|
||||
\/ \/
|
||||
/\ /\
|
||||
//\\/\ /\//\\
|
||||
\\///\\/\//\\\///\\/\//\\\///\\/\//\\\//
|
||||
\/\\///\\\//\/\\///\\\//\/\\///\\\//\/
|
||||
\/\\//\/ \/\\//\/ \/\\//\/
|
||||
\/ \/ \/
|
||||
```
|
||||
|
||||
Or perhaps something more fun, like:
|
||||
|
||||
```
|
||||
echo "I am a dog" | boxes -d dog -a c
|
||||
```
|
||||
|
||||
Which will, unsurprisingly, give you the following:
|
||||
|
||||
```
|
||||
__ _,--="=--,_ __
|
||||
/ \." .-. "./ \
|
||||
/ ,/ _ : : _ \/` \
|
||||
\ `| /o\ :_: /o\ |\__/
|
||||
`-'| :="~` _ `~"=: |
|
||||
\` (_) `/
|
||||
.-"-. \ | / .-"-.
|
||||
.---{ }--| /,.-'-.,\ |--{ }---.
|
||||
) (_)_)_) \_/`~-===-~`\_/ (_(_(_) (
|
||||
( I am a dog )
|
||||
) (
|
||||
'---------------------------------------'
|
||||
```
|
||||
|
||||
Boxes comes with [lots of options][1] for padding, position, and even processing regular expressions. You can learn more about boxes on the [project's homepage][2], or head over to [GitHub][3] to download the source code or contribute your own box. In fact, if you're looking for an idea to submit, I've got an idea for you: why not a holiday present?
|
||||
|
||||
```
|
||||
_ _
|
||||
/_\/_\
|
||||
_______\_\/_/_______
|
||||
| ///\\\ |
|
||||
| /// \\\ |
|
||||
| |
|
||||
| "Happy pull |
|
||||
| request!" |
|
||||
|____________________|
|
||||
```
|
||||
|
||||
Boxes is open source under a GPLv2 license.
|
||||
|
||||
Do you have a favorite command-line toy that you think I ought to profile? The calendar for this series is mostly filled out but I've got a few spots left. Let me know in the comments below, and I'll check it out. If there's space, I'll try to include it. If not, but I get some good submissions, I'll do a round-up of honorable mentions at the end.
|
||||
|
||||
Or check out tomorrow's command-line toy, [Drive a locomotive through your Linux terminal][4].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jason-baker
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://boxes.thomasjensen.com/examples.html
|
||||
[2]: https://boxes.thomasjensen.com/
|
||||
[3]: https://github.com/ascii-boxes/boxes
|
||||
[4]: https://opensource.com/article/18/12/linux-toy-sl
|
||||
@ -0,0 +1,71 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Drive a locomotive through your Linux terminal)
|
||||
[#]: via: (https://opensource.com/article/18/12/linux-toy-sl)
|
||||
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
|
||||
[#]: url: ( )
|
||||
|
||||
Drive a locomotive through your Linux terminal
|
||||
======
|
||||
Using the sl command, you can train yourself to get on track with a fun command-line experience.
|
||||
|
||||
|
||||
It's December, and every Linux terminal user deserves a reward just for making through the year. So we're bringing you a sort of advent calendar of Linux command-line toys. What's a command-line toy? It might be a game, a pointless little time waster, or just something to bring you joy at the terminal.
|
||||
|
||||
**sl** , which is short for steam locomotive.
|
||||
|
||||
Today's Linux command-line toy is a suggestion from Opensource.com community moderator [Ben Cotton][1] . Ben suggested, which is short for steam locomotive.
|
||||
|
||||
It's also, conveniently and not coincidentally, a common typo for the Linux **ls** command. Want to stop mistyping ls? Try installing **sl**. It's probably packaged for your default repos. For me, in Fedora, that means it was as simple to install as:
|
||||
|
||||
```
|
||||
$ sudo dnf install sl -y
|
||||
```
|
||||
|
||||
Now, just type **sl** to try it out.
|
||||
|
||||
|
||||
|
||||
You may notice, as I did, that **Ctrl+C** doesn't derail your train, so you have to wait for the entire train to pass. That'll teach you to mistype **ls**!
|
||||
|
||||
Want to check out the source to **sl**? It's over [on GitHub][2].
|
||||
|
||||
**sl** is also a great opportunity to share a personal PSA about open source licensing. While its [license][3] was "open source enough" to be packaged for my distribution, it's not technically an [OSI-approved][4] license. After the copyright line, the license reads simply:
|
||||
|
||||
```
|
||||
Everyone is permitted to do anything on this program including copying,
|
||||
modifying, and improving, unless you try to pretend that you wrote it.
|
||||
i.e., the above copyright notice has to appear in all copies.
|
||||
THE AUTHOR DISCLAIMS ANY RESPONSIBILITY WITH REGARD TO THIS SOFTWARE.
|
||||
```
|
||||
|
||||
Unfortunately, when you chose a license that's not OSI-approved, you may accidentally be creating extra work for your users, as they must figure out whether your license will work for their situation. Do their corporate policies allow them to contribute? Can they even legally use the program? Does the license mesh with the license of another program they wish to integrate with it?
|
||||
|
||||
Unless you're a lawyer (and perhaps, even if you are), navigating the space of non-standard licenses can be tricky. So if you're still looking for a New Year's Resolution, why not resolve to choose only OSI-approved licenses for any new projects you start in 2019.
|
||||
|
||||
No disrespect to the creator, though. **sl** is still a great little command-line toy.
|
||||
|
||||
Do you have a favorite command-line toy that you think I ought to profile? The calendar for this series is mostly filled out but I've got a few spots left. Let me know in the comments below, and I'll check it out. If there's space, I'll try to include it. If not, but I get some good submissions, I'll do a round-up of honorable mentions at the end.
|
||||
|
||||
Check out yesterday's toy, [Box yourself in on the Linux command line][5], and check back tomorrow for another!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/linux-toy-sl
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jason-baker
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/users/bcotton
|
||||
[2]: https://github.com/mtoyoda/sl
|
||||
[3]: https://github.com/mtoyoda/sl/blob/master/LICENSE
|
||||
[4]: https://opensource.org/licenses
|
||||
[5]: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
Loading…
Reference in New Issue
Block a user