March 5, 2012
There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.
1. First, pass a few simple "Hello World" online tests.
I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable.
That's why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it's sad and kind of depressing that this is even necessary, but if you don't perform this sanity check, trust me – you'll be sorry.
Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.
2. Ask to see their portfolio.
Any programmer worth their salt should have a portfolio of the things they've worked on. It doesn't have to be fancy. I'm just looking for a basic breadcrumb trail of your awesomeness that you've left on the Internet to help others. Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff. Got a professional blog? A tumblr? A twitter? Some other word I've never heard of? Excellent, let's have a look. Share applications you've designed, or websites you worked on, and describe what parts were yours.
Just seeing what kind of work people have done, and what sort of online artifacts they've created, is tremendously helpful in getting a sense of what people do and what they're good (or bad) at.
3. Hire for cultural fit.
Like GitHub, I find that cultural fit is often a stronger predictor of success than mad programming chops.
We talk about [philosophy] during the hiring process, which we take very seriously. We want any potential GitHubber to know what they’re getting into and ensure it’s a good fit. Part of that is having dinner and talking about stuff like the culture, philosophy, mistakes we’ve made, plans, whatever.
Early on we made a few hires for their skills with little regard to how they’d fit into the culture of the company or if they understood the philosophy. Naturally, those hires didn’t work out. So while we care about the skills of a potential employees, whether or not they “get” us is a major part too.
I realize that not every business has a community around what they do, but if you do have a community you should try like hell to hire from your community whenever possible. These are the folks who were naturally drawn to what you do, that were pulled into the gravitational well of your company completely of their own accord. The odds of these candidates being a good cultural fit are abnormally high. That's what you want!
Did a few of your users build an amazing mod for your game? Did they find an obscure security vulnerability and try to tell you about it? Hire these people immediately!
4. Do a detailed, structured phone screen.
Once you've worked through the above, it's time to give the candidate a call. Bear in mind that the phone screen is not for chatting, it's for screening. The call should be technical and structured, so both of you can get out immediately if it clearly isn't a fit. Getting the Interview Phone Screen Right covers the basics, but in summary:
- A bit of on-the-fly coding. "Find the largest int value in an int array."
- Some basic design. "Design a representation to model HTML."
- Scripting and regular expressions. "Give me a list of the text files in this directory that contain phone numbers in a specific format."
- Data structures. "When would you use a hashtable versus an array?"
- Bits and bytes. "Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"
What you're looking for is not magical perfect answers, necessarily, but some context into how this person solves problems, and whether they know their stuff (plus or minus 10 percent). The goal is to make sure that the candidates that do make it to the next step are not wasting their time or yours. So don't be shy about sticking to your guns and ending the call early if there are too many warning flags.
5. Give them an audition project.
So the candidate breezed through the hello world programming tests, has an amazing portfolio, is an excellent cultural fit, and also passed the phone screen with flying colors. Time to get them in for a face-to-face interview, right? Not so fast there cowboy!
I've seen candidates nail all of the above, join the company, and utterly fail to Get Things Done. Have I mentioned that hiring programmers is hard?
If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project. I'm not talking about a generic, abstract programming problem, I'm talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. Something you would give to a current employee, if they weren't all busy, y'know, doing other stuff.
This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement. Select a small project that can ideally be done in a few days, maybe at most a week or two. Either the candidate can come in to the office, or they can work remotely. I know not every business has these bite-sized units of work that they can slice off for someone outside the company – but trying desperately to make it inside the company – to take on. I'd argue that if you can't think of any way to make an audition mini-project work for a strong hiring candidate, perhaps you're not structuring the work properly for your existing employees, either.
If the audition project is a success, fantastic – you now have a highly qualified candidate that can provably Get Things Done, and you've accomplished something that needed doing. To date, I have never seen a candidate who passes the audition project fail to work out. I weigh performance on the audition project heavily; it's as close as you can get to actually working the job without being hired. And if the audition project doesn't work out, well, consider the cost of this little consulting gig a cheap exit fee compared to an extensive interview process with 4 or 5 other people at your company. Worst case, you can pass off the audition project to the next strong candidate.
(A probationary period of conditional employment can also work, and is conceptually quite similar. You could hire with a 6-8 week review "go or no go" decision everyone agrees to in advance.)
6. Get in a room with us and pitch.
Finally, you should meet candidates face-to-face at some point. It's inevitable, but the point of the earlier steps is that you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room.
I'm far from an expert on in person interviews, but I don't like interview puzzle questions, to put it mildly.
Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you'll quickly ascertain …
- Is this person passionate about what they are doing?
- Can they communicate effectively to a small group?
- Do they have a good handle on their area of expertise?
- Would your team enjoy working with this person?
The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me!
7. None of this is guaranteed.
Please take this list at face value. I've seen these techniques work, and I've occasionally seen them not work. Adapt this advice to your your particular situation, keep what you think makes sense, and ignore the rest (although I'd strongly advise you to never, ever skip step #1). Even in the best of circumstances, hiring human beings is hard. A job opportunity may not work out for reasons far beyond anyone's control. People are, as they say, complicated.
If you think of work as a relationship, one you'll spend 40 hours a week (or more) in the rest of your life, it behooves everyone involved to "date smart". Both the company and the candidate should make a good faith best effort to determine if there's a match. Your goal shouldn't be merely to get a job, or hire someone for a job, but to have fun and create a love connection. Don't rush into anything unless it feels right on both sides.
(as an aside, if you're looking for ways to attract programmers, you can't go wrong with this excellent advice from Samuel Mullen.)
[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.
Posted by Jeff Atwood
Great ideas here. The only suggestion I would make is to replace point 5 ... instead of having an 'audition project' why not just have a 'probationary period' (e.g. 3 months) during which time either the developer or the employer can decide to end it if things don't work out. Its fairly common in development jobs in Australia.
Saying knowing how to program is actually different from actually knowing how to program.
One job that I applied for (and got hired) I was asked to do using a flowchart (this was long long time ago) of determining the day of the week given a specific date.
Once I finished the flowchart they gave it to a programmer who wrote the COBOL program for it and with a few changes it worked!
Lots of good points here. Number 2 is the only one I take issue with. I think there are solid developers (hopefully myself included) that do not have any sort of public portfolio.
I think for every dev contributing to open source projects, working on websites, and spending there time on stack overflow, there are five that work 50 hour weeks for large companies in government, automotive, health care, finance, etc. who don't work on on products that are public and can't show code they've written. It's also tough when you work on a team of 50-100 in parallel and only pieces (maybe not even entire features) are solely written by you.
As for working on projects outside of work, maybe I just don't possess the proper dose of passion but in my free time I want to spend time with friends, family, and other hobbies - that's why it's free time. But that doesn't mean I don't bring my best during business hours inside the halls of my office.
I think this division in mentality is a core difference between Silicon Valley startups and large corporations. Regardless though, I think you're other metrics help to solidify a candiate and are excellent suggestions; I wish we exercised more them.
I think all this comes down to a simple rule:
Don't hire anyone that you don't already know, trust, and will fit in to your organization.
Now, how you get to know and trust any potential hire are details that can change depending on the situation. The steps that Jeff outlines above are good if you have had no contact with the applicant before the interview.
Personally, I've had good experience hiring grad students who already have some work experience and come recommended by their professor. It definitely helps to have strong connections to local universities, but hiring these kinds of students makes me fairly confident that they are: hard working, smart, experienced but still open-minded, and tend to have a good mindset for the place where I work.
In a similar vein to what TravisVT said about 2, I have concerns about 5. The time commitment alone is going to disqualify a lot of people who are currently employed and most corporates have employment contracts that specifically prohibit doing other work outside of office hours.
There should be a step 0 consisting of an introductory conversation to make sure that both sides know who they're dealing with in terms of basic things like the kind of workplace you are, the kind of person you're looking for and the recruitment process.
Last year I applied for a job through a consultant where all I knew was the name of the company and the content of their marketing website. The first communication I had with them was "do this code test", then the next communication was "now answer this 5 question exam". When the consultant told me they wanted me to come in for a "technical only" interview, I told him to get lost. It has to be a two way street, these people had sucked hours of my time without even giving me a hint of who they were and what they were offering. I got the impression they had no respect for what I might be looking for.
At another company, the manager contacted me directly and told me about what their recruiting process involved (e.g. how many code tests, interviews etc...) and the kind of working environment they offered. In the course of this conversation, it became apparent that the workplace culture was one of intense social engagement where the employees lives were centred around the job. While I could see the appeal of that kind of job for unattached people, I didn't think it would be great for me as a father of young kids. I was able to self-select out of the process early rather than waste everyone's time doing code tests etc...
Step 0: Introduce yourself, talk about your goals and outline the process.
Great post. I agree that companies should do all of this....But, it's very one-sided. Granted, the best hires are ones who, like you said in 3, are already part of your community and want to work for you. Most of the time, though, an amazing programmer will be amazing for many companies. You also have to tell them what your company has to offer. Especially in this market, the interview process shouldn't be about vetting the programmer, but figuring out if there's a fit, for both sides.
I feel you'll miss out on a lot of really good programmers if you approach interviews as a way to see if you want them to work for you. Interviews should be about figuring out if you can work together, and that goes both ways. In a sense, both sides should be interviewing each other.
Great ideas here, though I also disagree with point 5. There are a lot of people who a) want to be employees not contractors and/or b) are currently employed (and are "content" if not "happy" at their current job - these are usually the most desirable hires, and requiring an "audition" contracting period means you'll miss out on great people.
Also, I've used collabedit.com (I have no affiliation with them) for phone screens and found it very useful. I like the idea of codility and Interview Zen, but I'd worry about the interview questions being posted at various sites online (that I won't mention here to avoid giving them pagerank :) ).
Much like some of the commenters above, I think points 2 just eliminates 80% of the valuable workforce. And having something else to do than programming during your spare time is not the only reason, contractual agreements sometime mean everything you code during your spare time must be first submitted to your company before going public.
About point 1, in 20 years I never meet anyone who was not able to code during a programmer interview, but I guess we have less script kiddies in Europe (or, may be, better engineering schools).
To me the network is the most valuable thing, however, the worst programmers I ever met had been recruited because someone knew them, so this does not dismiss formal interviews with someone who doesn't know the guy.
I would love to see an equivalent of "How to Hire a Systems Administrator", which of course I'm currently struggling with...
I was with you until point 6. If I was asked to do that I would politely decline and carry on looking elsewhere for work. It seems more like a talent show audition than anything useful for me (the interviewee). I can see how it may be of value to the employer, plus the unwritten benefit of the occasional cringeworthy and uncomfortable presentation. That's one of the reasons why shows like America's got Talent are so popular after all right?
I'd much rather be put on the spot and have my area of expertise tested in a Q&A format so I can't just cherry-pick my strong points.
Maybe it's because I am more introverted, although still fine communicating and getting along with people. I wouldn't have applied to a role that needed me to present as part of the job in the first place so I certainly wouldn't expect it as part of an interview process.
Anyway, I'd be happy with any company doing the first 5 suggestions if I applied there.
Moneyball is an excellent allegory for software developers.
Can they code. That's really all that matters. The only way to know if they can code, put them in front of a whiteboard and make them code. Everything else doesn't really matter as much to me.
For those that don't have time/desire to work on projects outside of their normal day job, understand that you are competing with people who are equally as smart, who put in just as much time at the office, but also work on projects outside of work.
The problem with the audition project is time.
If it's something that can be done over a weekend then maybe this is fine (for most people at least).
But if you need someone to take a week or two away from work then your relying on them being able to get that time off from their current job or to quite their current job just on the risk of getting hired.
This is going to rule out many experienced candidates who may have family commitments and will want to use their limited holiday time to actually take their family on holiday.
I would struggle a little with 2 because I can only infrequently publish my code. However I have done a couple of presentations to user groups that are online, and I have a collection of StackOverflow accounts (one per employer). It's not a completely unreasonable requirement, but it does suggest that you're hiring at the top of the market. Whether that's a top 5% graduate or a top 5% senior software engineer, it means you're going to have to pay a premium to get those people interested.
Point 6 would wipe out pretty much every non-Merkin programmer I know. It's a very USA-centric thing, and possibly even US-startup specific. And I do wonder if you're selecting for people who are likely to quit on short notice because their out-of-hours project got funded.
I think this kind of process for interviews is really prevalent in the US, especially for big companies.
And when I read here and there how easy it is to get fired there, I don't understand why you put such a barrier for the entry!
As a programmer, I'd feel insulted if I had to pass through 5 layers of requests and experiments until seeing someone face to face. I'd let go after the 2nd or third.
If a company is making his future employees pass through hell just to have a chance of going in, thanks but no thanks. That's not the company I want to work for.
My 2 last job interviews (for 2 small companies in France) went in 2 shots: one on the phone, then face to face, where I was faced with 1 or 2 "programming" questions, then ~1 hour of discussions about what the job was, what I did before, and how comfortable I was feeling doing this job.
Now, these were (are) small companies, where there was no HR that was PAID to design lengthy interview processes. I directly talked to the guys I'd be working with, and I don't think they made a mistake taking me. I'm still working in the 2nd one, as an happy programmer.
There's a question of trust in an employer/employee relation. I had a 3 month trial after both my interviews, and I was absolutely ok with that. This period is made for that: if I didn't fit, it would show in the first 3 months and I'd be thanked. No need for a 2 month recruiting process!
At some point in the process you might want to think about how to convince that awesome programmer to work for you and not for somebody else.
I think it's important to respect the candidates time. Paying a candidate for a project is the right thing to do.
I've seen application process where the candidate is asked to write a whole app. They said it should only take 2 hours, but from experience I know it would have taken at least a day to do it correctly. I strongly doubt that they would have checked the code other than compile and run. Due to this I didn't even apply.
Just give person 4 problems from projecteuler.net or similar site starting from really easy to any difficulty. Leave candidate for X hours and come back to check progress.
"portfolio"? Nice if you have one. Many don't.
"audition project"? I don't have free time for that.
"15 minute presentation"? As somebody mentioned - talent shows are not for me.
Not a fan of #5. It feels to me that you're simply trying to get the candidate to do free work for you.
I'm also not a big fan of the "on the fly" testing. I can't remember how every damn function works off the top of my head and some of the problems outlined in this article are things I have never run into (most likely because I'm a web developer rather than a software programmer) so I wouldn't be able to answer them right away.
I'd rather just give a few examples (code and all) of what I've done and then talk with the recruiters to see if I would be a good fit. That's how I landed my current job and it didn't waste days of my or the company's time jumping thru hoops with multiple rounds of interviews and crap.
"Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"
How is this not a stupid interview question? It's not obvious in context that "Oct" refers to octal and "Dec" to decimal.
@kasakka Read the article. He says that the audition project should be a regular contracting gig and paid on an hourly rate. Definitely not free work.
Scripting and regular expressions. "Give me a list of the text files in this directory that contain phone numbers in a specific format."
Will I get bonus points for linking to the xkcd comic instead? http://xkcd.com/208/
"Design a representation to model HTML."
LOL - have you seen the specification for HTML5?!
As mentioned by several commenters, not all good programmers have an online-visible portfolio, though the percentage seems to be growing. One thing I've found to be almost as good of a screen, that I tend towards at the phone screen level, is to ask them about a challenging project they've done and get them to talk about the tradeoffs that went into that project.
A good programmer will not only be able to explain the architecture of the project, but all of the things that were not ideal about it and that they'd like to have done better.
Great Article Jeff and couldn't agree more. I've started four software companies the latest being RoundPegg.com, started just for the purpose of being more diligent about #3. Fit to company culture is one of the best predictors of success.
Your phone screen questions are crap. Do you know how often I use Regex? Almost never. I've got an open source project with a hundred tests for Regex if you're that curious, but I almost never use it. Those questions are too in-the-weeds to ask without context.
A surprisingly large fraction of applicants, even those with masters' degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I've personally interviewed graduates who can't answer "Write a loop that counts from 1 to 10" or "What's the number after F in hexadecimal?"
Honestly, even five years after this article was posted, I still have a very hard time believing this part. I mean, sure, anyone can apply for a programming job even if they know nothing about it, but "even those with masters' degrees and PhDs in computer science"?! Unless they have an imaginary degree or something, it seems very unlikely.
Still, it doesn't make the "hello world" test any less useful. This method of weeding out candidates is very well thought out and more business leaders should adopt it. I've seen enough clueless "specialists" in the industry already, and I'm still a junior.
"Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"
Terrible interview question. Especially over the phone, where you wouldn't get the visual hint. Unless you already know that "joke" there's a good chance you wouldn't find out the answer in that context. And that certainly doesn't say anything about your programming skills.
I've always thought of the hiring process as a series of filters. Each step along the way (resume review, phone screen, programming quiz, interviews, group meeting, ...) is useful at excluding candidates, but not at detecting whether they will be a good hire.
There is no test or process that can assure a person will be a good hire, short of actually hiring them. Along those lines, I've often hired people on a 3-month contractual basis to give me a chance to work with them and them a chance to see what the job is really like. It's sort of like your auditioning practice but taken to a much further degree.
5. Give them an audition project.
I like this plan, but if you try this make certain they get paid, state law here in Washington states you cannot have an employee work during an interview without them getting paid. Last thing you want is any state government having a talk with your managers... Then you may well be interviewing.
I assume any interview I go into is a sales pitch on my part and their part - do i want to work for them? They need to answer that question for me. As one of the gray beards I am too old to get into a crappy management structure. I'm getting picky in my old age.
eh...too much of a PITA to get a job with you Jeff :) If a company needs that much time/info to decide, then I probably already got another offer somewhere else.
With an article like this you're going to get the people who know the answers thinking it's great and the people who don't thinking it's crap.
With that out of the way...
As others have said, the audition project step seems like it would only work if the candidate were self-employed or unemployed. I have a pretty busy life, and after leaving work for the day I don't really have another eight hours I can put into a side project.
Similarly with the on-line portfolio. I have a few points on SO and EE, but I don't have anything on GitHub as the software I do write on my own time is so specific to a problem I'm trying to solve that there's really no benefit to sharing it.
However, I have consistently gotten outstanding reviews, commendations, and praise everywhere I've worked, so I like to think I'm a pretty darn good developer/engineer/architect who would be passed over because I don't eat/drink/sleep software development every hour of my life.
One thing Joel Spolsky is well-known for is his expertise on hiring good programmers. I find it interesting that Jeff worked with Joel for 3+ years on Stack Overflow and the first posting he does after leaving that company is on how to hire good programmers.
Very interesting topic you are raising here. However, I think it should come with a disclamer: "Works for really awesome workplace!" (Like Google, Facebook and other hot tech companies). It is very many hops to go over and as a potential employee, I should feel confident it is worth it. Too many places aren't.
I do agree with commenters, that not everyone has an online portfolio. Partly because we we work on proprietary software and also due to the fact of having life besides coding.
Audition project - again, would work for very in-demand workplace, if you are not that sexy company, competent people will most likely not bother.
Cultural Fit - absolutely! Unfortunately, it is difficult to tease out during interview, as applicants are going to put their best foot forward. Perhaps only trial period can really show it.
Doing pitch - which position are you trying to fill?
It does not make much sense to me for a more junior one, with little administrative/managerial responsibility. Developers, who can pitch and do great presentations would command a hefty premium, because it is often way out of typical developer skillset.
It is better to hire a developer and teach him pitching/selling if it is that important, though I have yet to see it being necessary outside startup environment.
On the tangential note, I really liked Joel Spolsky's take on hiring. You just need a person, who is a good cultural fit, smart and get things done. http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
Oh god. Save me from the companies that think if you don't participate in programming as a hobby you're not worth hiring.
Do we expect surgeons to practice on their friends and family when home from the hospital? Do we expect lawyers to go file lawsuits for fun? Do we expect chemical engineers to go mad-scientist in their backyards?
You are self-selecting for those with extremely poor work-life balance. That may work for some. It is not a recipe for success across the board.
A live troubleshooting of a real world problem can work very well also. Hard to set up if your in a big business, but in smaller organizations it's a very good test.
I don't think there's a single enterprise developer who could pass this process.
Interesting ideas and I agree strongly with most of it, but I do take issues with a couple of points.
The consultancy or probationary period is the one I find most objectionable. This works fine if an individual is out of work, but the majority of people you'd want to hire are already employed and looking for a change. Asking them to quit a current role so that you can audition them for a month is something very few people would accept. There's always the chance it won't work out and now you've gone from employed and looking for a perfect fit to unemployed and needing to find a new role ASAP. An audition project that is smaller and can be worked on over a weekend or in free time can work great, I think.
In addition, although commitments to open source work is great I know many programmers who haven't worked on anything that isn't proprietary and confidential since college. It isn't that they don't love their work (although that is possible of course), but would rather spend free time with family and devote extra time, when it exists, towards advancing prospects with their employer by working on "nice-to-haves" there. In many cases this is an employee you'd love to have, but may completely lack a public portfolio.
I kind of disagree with Number 5. Small assignments are fine but what's the line on how much to pay that person compared to the size of project/task that is given to him/her?
I also think that some companies are using that kind of a task to their advantage or can start using it that way, which isn't nice if you don't get hired in the end...
I was given a test after a face-to-face interview. I aced the test, then told I was a 98% fit (I had a good interview (2-3 hours prior to this "assignment") with 2 senior programmers and CTO), then I didn't get the job because I was "too confident".
I blogged about the assignment and solution here: http://www.kanersan.com/blog.php?blogId=46
The company was providing private advertising solutions to businesses. They could've used the idea/theory of my solution in one of their projects but I did not get a dime out of it and spent a good day solving it... This is why I'm not happy.
I'm glad this works for you and it works for the unmarried prospective employee, but what about the rest of us? I don't have time to code as a hobby anymore. And I have a family situation that requires me to have actual insurance so I don't do contracting and would never agree to your week long contracting gig and a hiring process that looks to take another week or 2 beyond that. Regarding your "pitch" idea: really? Just ...really? You're picking the best introverted programmer based on a high-pressure sales pitch?
I love so many of your posts but it's hard for me to even read this one.
"Hire for cultural fit"
I get what you mean, but you're treading on an HR minefield in the US!
Be very careful that 'cultural fit' doesn't become a code word for 'guys I'd like to hang with who are non-disabled members of my age group, racial group, etc'.
Culture fit is good, but if your hiring process produces a homogenous employee group then that's bad for business and possibly not legal.
Fit, fit, fit -- #3 is the most important for me. I actually ask only a few technical questions just to be sure the person actually has the technical knowledge to match their resume. (In fact, an interview I did last week was laughable -- the candidate claimed significant database experience but could not answer the question "what is the difference between an INNER and OUTER JOIN".)
I was trained in "character-based interviewing" where certain characteristics (team work, problem solving, communication) are key in most jobs. I have found again and again that if a person demonstrates these characteristics, and has decent technical skills, the person will succeed. Then again, my current company requires a close working relationship between the business and the developers so "soft" skills are a must.
#2 isn't generally applicable - I've generally worked for corporations, and they've paid me for my skills. They don't want that code walking out the door with me, and between kids, a wife, and a life I haven't always had time for doing programming on my own. And anyone who asks specifically for code that I've done for a previous employer is asking me to act unethically, and I'm not working for people who ask me to violate my ethics.
#5 is a 'no-go' for me as a candidate. I've had people try to do this before, and I told them no thanks. If I'm job hunting, then I'm looking for a real position. Offering me consulting work says to me that you don't actually want to hire - you want to pay me less than I'm worth for a while, without all that hassle of having employees and paying unemployment, etc, etc.
Now I understand why you want #5, I really do. But from the candidate's point of view, you look like you're trying to take advantage.
Instead, state up front that you're hiring the employee for a trial period (my present position says 3 months) and if they don't work out DO NOT HESITATE to send them packing. If you can't fire people who don't belong at your company, then you shouldn't be running a company.
One of the worst things is to get a candidate to "write software" on a whiteboard. No one writes code on a whiteboard. So don't ask someone to do it. The candidate would be better off walking out of the interview than to be made to to that.
#5 ensures that you only hire someone who is not currently working, and thereby seriously reducing your applicant pool. As other have said, it may work for Google, but will not work for a generic Fortune 500 company, unless there is something spectacular to motivate the applicant to jump through all those hoops. There are just too many willing employers who will not require as much.
Posted too soon, and stopped at #5. #6 is a real laugher. Not sure what market you are hiring in, but usually, in this part of the country, it is the employer who is pitching the candidate, especially one who has completed steps 1-5 successfully (around 10% in my experience would get past #4). Jeff, I think you have been around the Cali startup scene too long, and forgotten how things really work in the real world.
I think many developers these days are poor programmers because WE DO NOT PROGRAM ANY MORE. We simply use frameworks. And what is frameworks? Guides into making great and powerful applications.
I remember when I was a C programmer, I use to code a lot -- from the ground up. Now I use Spring framework alongside with some ORM, and what I do? I simply inter-connect everything and I got
Given what's available in the field, if you're going to put your applicants through all that, it had better be one amazing job.
What do you do when your burned out from boring work at your current employer and aren't really passionate about anything? It's hard to get passionate again with programming as a hobby after spending 40+ hours in a week doing unenjoyable programming.
I'm with Matthew Kane and Bob T (figuratively).
Really? And after you have a good fight with the other super-hot leading edge colonies of brilliant coders in your area over this guy, have fun with the warm body you hire overseas.
No wonder American employers say there's no one good in this country.
Sorry to be a curmudgeon.
Great information, thank you.
One problem I am up against right now is not know enough about it all to know if I am hiring someone with the right skill set and language to build it in. I am looking for a trusted programming partner.
Chances are if you are reading this, you are a programmer.
Organic Mechanic, a green technology company, is looking for a partner to help us apply to GreenStart - an accelerator program which will provide funding, training, and ongoing mentorship and support to make sure that the company grows. (http://GreenStart.com/ - great 2 min video)
In order to apply, we must have a programmer on the team. We have years of sales history and a really awesome idea for a personal energy profile on the site - we just need to work with a solid programmer who knows his/her stuff and wants to be part of a world changing green startup!
You will earn money once it is launched, equity in the company if you become a longterm partner, and you can come with us to the once in a lifetime startup development program in San Francisco beginning in the fall! This will introduce us to a world of unbelievable contacts, ideas, resources, exposure and opportunities. Plus it will be a lot of fun!
Let's earn a spot in Greenstart and build something revolutionary together! Please respond here or email Office@OrganicMechanic.com if you are interested or know someone who is.
I read your post, and overall it's really interesting. I think the idea you're getting at is (like other aspects of business) to reduce risk. Like you say, hiring programmers is tough and humans are complicated. Maybe another approach is to look at quantity over quality. That's the whole idea behind continuous integration, right? Keep gathering information and make changes as necessary. The process you've suggested is really time and resource intensive. Imagine coming up with, supervising, and evaluating audition work, in addition to finding applicants, coding tests, telephone screens, resume reading, etc. It's a lot of work for everyone involved.
Now imagine you need programmer(s) for a project. Hire the first candidate that meets some very minimal requirements (passes FizzBuzz, has required experience on paper, seems friendly and personality matches). Hire them on a contingent basis (ie you can be dismissed for any reason within the first 60-90 days or whatever, like in Ontario) and go. Repeat as necessary. You may go through a bunch of applicants, but that's why the process is minimal; avoid cost but keep valuable information. You can change your requirements too. "Maybe looking for C++ devs isn't what we really want". "That question about why manhole covers are circular does seem to be a crappy question".
Just throwing out ideas, but I have a sinking feeling that this approach might work better in some settings than what places do now.
I read most of your posts, and normally agree with you - but I think you're way off here.
Let's say I'm a good candidate. A great one. Maybe the best. Your company want me to jump through these silly little hoops for weeks trying to prove it. Company B looks at my resume, calls me in for an interview the next day, calls a few of my references right after the interview and makes me a good offer by phone which I've accepted before I even get home. You've lost me.
This is not hypothetical, it's happened to me a number of times.
The only people left in your recruitment process are the guys and girls who aren't being snapped up by your competitors. You have lost.
When I'm recruiting, I do it based on one interview in which I need to see some code the candidate has written and have him/her talk me through it and answer questions in a way that convinces me they wrote it themselves. That's enough. If they suck, or they cause trouble, or whatever - then it's obvious within the probation period anyway and it's easy to get rid of them.
Jeff been reading you for a long time and this is the first post that doesn't seem right when I read it. You've lost a lot of the best people at #1, #5 is bordering absurd as is #6 if it actually follows #5
While I agree with some of the posters above that this interview process is very specific a certain type of programmer and a certain type of business... I'd love to encounter it. Sadly, my resume rarely makes it past HR, let alone to an actual skills assessment of any sort. Almost every time I've ever coded on a whiteboard or multiplayer notepad I've gotten an offer. For some of us, it's getting that far that's the problem.
I have given some thought to your article. And now feel compelled to reply.
Detailed phone screens (#4) with the questions your illustrated is only appropriate for developers that do not have a portfolio.
Specific questions such as those you [presented in #4] are ridiculous for experienced developers. The phone interview format as you presented is essentially a time-based test of algorithm syntactics.
It does NOT allow developers to demonstrate ability to deliver quality solutions. It does not reflect developer ability to research options (using Google/internet blogs/etc). It does not reflect best-solution usually derived from iterative refactoring and testing.
I have encountered many candidates that pass your tests with stellar results. And some of those candidates can even write short code pieces in a time-test environment.
But those same candidates cannot write quality code nor deliver on required features. They are horrible developers.
Your questions do not highlight the candidates's ability to deliver results. Usually it is not about "how fast can they produce" but more about "the substance and quality of what is produce".
The best phone interview uses screen sharing and agile-style code reviews. Ask the candidate to provide code samples of their work... work that they are proud of. Walk through their code with them; analyzing pros and cons of the implementation and architectures. Discuss feature requirements and testing. Review the coding style, motivating factors, the refactoring, encapsulation, coupling, APIs, documentation of that code.
Another great approach is to present new code samples and ask the candidate to perform online, on-the-fly review of the code: discuss the implementation, style, etc. Ask them to provide their thoughts and analysis.
#1 is ridiculous for developers with a portfolio (#2). Only entry-levels should be give #1 or online tests. If the candidate is not entry-level, then they MUST provide samples of their code (written by them).
#2 and #4 performed with code reviews [as discussed above] gives really good indications of enthusiasm, comprehension, completeness of feature, representations of the candidate's version of "quality delivery", and more.
#5 is a great follow-up to candidates passing #2 & #4.
Another Great and useful post by Jeff Atwood. but I am little disagree with you in some points to kept in mind while hiring a programmer.
Interesting article. As a general matter, I don't look for programmers - I look for problem solvers.
While much of what I read in this post is good in theory, practically, it is not workable. Too much effort on the part of the interviewer.
You want to learn about skills? Post a repo on github with problems. Direct the candidate to that. There will be a readme. The code should have problems as to not working and not compiling. Instruct them to fork, fix, and submit a patch. Did they write tests? Did they make one big checkin or several? You can also add hypothetical use cases and problems for them to answer. Writing is a key skill in this industry. Do they just answer in tech terms? Or, do they mix in business analysis.
Through this process, which takes no time on the part of the interviewer - except to review the submission - you can learn a lot. The candidate may be a senior developer - but through this process - you will have a gauge of what kind of senior dev he/she is.
What you say is very interesting. I'm a passionate software engineer but I have a problem. I stutter a little when talking to people and I have fear to not pass my future interviews due to this problem and because I think I have some kind of social anxiety disorder... What can you say to me? Thanks.
These methods only fit if you're a google level company. i.e. you can
1.) Afford the risk of filtering out a good candidate (which is bound to happen with the way you interview)
2.) Afford the high paycheck that anyone who passes this gauntlet deserves.
If you're not, then please burn in hell. I always hated small-time startups taking more time to hire than it would to actually develop their project.
Ask the candidate to provide code samples of their work... work that they are proud of.
I've never understood this. I've been asked for code samples a couple of times in the last twenty years of developer interviews, and I just don't get it.
I work for companies, producing software that they own. So I have no rights to that software and would be violating my contract if I was to show it to anyone outside the company. Not only that, but in any company with a long-lived code base it will modified and rewritten by numerous other developers, so finding a self-contained piece of code that I wrote by myself would be difficult, to say the least.
I can pull some code from the open source projects I've worked on, but that's hardly representative of what I'd be writing in a professional job with budgets and deadlines. So unless you want to hire people who'll walk out the door with code you've paid them to write, you're basically asking me to sit down and write some dummy code which will never be used for anything other than a talking point in an interview. I don't get it.
Then you are doing something wrong with your resume. Ask some help around to see if you have something on your resume that makes HR bin it.
#1 is not ridiculous at all, as Jeff mentioned. It is trivial and takes no time to solve it, but it proves you have rudimentary coding skills.
If you as a candidate have problems with this test, it would be a red flag for me. But for totally different reason - attitude problem. No task should be "below you" to perform, no matter how trivial. It shows how good a team player you are.
I would never focus attention on CODE, because it is learnable. Problem-solving and designing good solution is critical and scarce.
I guess this applies only to the "junior programmers" that sometimes are sent to the customer by large organizations, honestly, if after 31 years and millions of lines of codes written in a dozen different programming languages somebody asks me to write a program to display "hello world", it means only that I am in the wrong job interview and I should immediately locate the nearest way out.
I like to see if the candidate can type. I give them the keyboard and ask them to show me what they've done. If they look at the keys, its off to a bad start.
Right on Martin. If you can't touch type, then you can't code!
We have established gurus teaching our teeks (IT learning units), so we don't worry too much about an immediate type test, but our business is virtual and international, so a touch test is less important than a portfolio. Great article!
This sounds exactly like the interview process for big corporations such as Microsoft.
"At some point in the process you might want to think about how to convince that awesome programmer to work for you and not for somebody else."
The strategy you're outlining is extremely risk averse (mostly to the benefit of the company), heavyweight, and is going to lose a lot of good people. Maybe all of them. Personally, I would immediately conclude my time was being wasted, there was a cultural mismatch, and I would head elsewhere.
I am grateful for the sample phone screen questions, especially number 5. If I'm ever asked that question in a future interview, I'll have the answer, but only because I read your blog. I haven't messed with octal values in over 20 years. It's a fine brain teaser; I might change it to "How is Halloween the same as Christmas".
I really do enjoy your blog.
Hiring for cultural fit is very important - but you can't really determine cultural fit unless you meet someone face-to-face first.
Phone screening is a good way of ensuring that the person you want to interview isn't a total monkey, but we've found that it doesn't save much time in the end, as we still have to interview the candidates that pass phone screening anyway, so we might as well just interview anyone who we feel qualifies based on their CV and agent recommendation, as we can kill several more birds that way.
We've done a lot of dev recruiting recently, and have streamlined our process to the following, as an example:
- Candidate is evaluated based on CV and agent recommendation. We try not to be too picky at this stage, depending on how many CVs we get.
- Candidate has initial face-to-face interview with 2 senior developers (to ask technical questions) and dev manager (to establish initial cultural fit). Any interviewer can veto the candidate at this stage and cut the interview short.
- If initial interview is successful, a standardised audition project is given. This enables us to compare developers against each other, if need be, whilst still establishing the candidate's core competency and coding style. The project is tailored to the technical and business environment of the company.
- If the audition project passes, then we invite the candidate for a final interview, where they will meet a wider range of staff in a more informal setting, including the directors of the company. At this stage the technical evaluation is complete, but staff members can still veto the hire if they find the cultural fit or personality of the candidate to be a real issue. It happens quite frequently, actually - I've had several candidates that I felt were technically strong and a good cultural fit get booted out at the last second due to poor performance in the final interview.
For our company, this process has resulted in the least involvement from both parties, as we establish the majority of what we need from the initial review. The audition project is very useful, but I do believe it needs to be standardised, otherwise you can't see how different developers stack up on the same tasks and sometimes that's the only way to choose between them! The final interview is really just a sanity check.
Your optimal process will be different of course, but it should be streamlined and consistent, and not waste anyone's time, if at all possible.
I'm going to take a stab in the dark and guess that you've never actually done this process that you're recommending. I don't know if you caught it while you were writing, but you actually just recommended having people come into your office to do paid work for up to two weeks before you've even met them in person. Somebody correct me if I'm completely off-base here, but isn't that completely absurd?
Not to mention that this method (step 5 specifically), is likely only going to get you two types of applicants: Those that are completely and utterly dedicated to getting hired to your specific company, and people with nothing better to do with their time. I don't consider myself to be in the very top tier of programmers, yet months before I graduated college I had more job offers than I knew what to do with. Not just "job offers," but good job offers with reputable companies and competitve salaries. If a company had required me to do several days of work for them before even considering giving me an interview, guess what I would have done? If you guessed "dropped everything (including school, several actual job offers, and my very fulfilling part-time programming work) to work for you for a week or more just to audition for your company," you are sorely mistaken.
Yes Robert, it is absurd. This is the outcome that should happen.
Interviewer: “We see that you have 10 years’ experience as a corporate engineer.. We need you to take a week off of your current job and complete this project for us. After that, please come back to our office for a talent show.”
Interviewee: “I’m leaving….”
Interviewer: “Your hired!”
If you want to hire the best, you should be marketing to them. Not making them jump through hoops for you. If I asked even a young develop/engineer to do all of these requests and they walked out of the interview, I would run out into the hall and hire them. They know the true value of what we are working for and creating, not all the fluff.
Better questions would be about application design, modeling, and testing. If your interviewee can carry a conversation then it’s pretty much implied that they can code what you need. If they start talking about CSS when you mention application design, then that’s the only filter that you need.
Its old programmers that forget they were once a 24 year old with no professional experience come up with these crazy interviews. It’s becoming unfair. I don’t think I could solve some of these programming mind games in high pressure interviews.
I'm not a fan of #1 and #4. I know how to program, but I've been on interviews where I've be asked to write code on a white board and I looked like an idiot. Programming is done with a keyboard, with your eyes on a computer screen and seeing what happens with it. Writing code out by hand feels unnatural and I can't think straight if I'm asked to do it like that.
Same thing with answering random programming questions over the phone. It's different to be writing code on your own to solve problems you're working out, than to try to speak about it to someone and answer their gotcha questions out of context.
I'm sure you can find great candidates like this, but I think you'll also be weeding out great candidates. It seems like you're trying to find one kind of thinker, but there are people who can get the job done and have a different perspective on things that won't pass these tests.
Except for the guidelines 2, 3 and 5, all the other points are reasonable and pragmatic and I definitely agree that they would help hire a good candidate, however
- 2. Ask to see their portfolio
This must be optional as many might not have the time to write their own blog but participation on StackOverflow or other programming websites is a good indication but making it one of these a pre-requisite and there is a good chance the interview can be an over-kill for the candidate.
- 3. Hire for cultural fit
This is debatable as you have rightly mentioned not every business has a community around it. What is the alternate strategy would you adopt for the one's that don't ? Where do you draw the line?
- 5. Give them an audition project
Well I am not sure how many people can sacrifice one week their work time to work on an interview project. This round can be a show stopper for many. Count me in. I can definitely agree with an assignment that can be completed within that day.
But overall an effective and tough screening to get a worthy employee but I am expecting another article from you which gives similar perspective from the employee who pass all these tests. :D
Without going into how much I agree or disagree with whats been said, this article is making the bold assumption that a company gets flooded with applicants for a programming position, ranging from useless to awesome. This is so far from reality that I find it obsolete to form an opinion on the validity of the further arguments.
It's like writing about how guys can weed out all the chicks offers in a club and pick the best one. How's the weather on the planet you're on?
While I agree with the need to test coding skills with all due respect I think a lot oof the ideas presented here are archaic at best. I think the more real world interaction you can get with the person the better.
Give them a quick project to work on a couple of nights before the interview and then do a ccode review. The process you describe above takes hours of time from the Candidate and the staff. You can do a code review in an hour and know more about the Candidate than you do by the above.
And a project? I would question anyone who would or would even ask someone to work for free and any senior level developer would laugh.
I went over this in some detail at this post. http://www.lonestarprod.com/?p=22
I believe the dichotomy between Jeff's post and the various comments/blogs is partly reconciled by keeping in mind two things.
1. Job candidates break down into:
a. People for whom programming is just a job.
b. People for whom programming is a career.
A career programmer will have a portfolio, will play with open source projects, will study programming in their off hours and constantly improve themselves. A job programmer codes during core hours and that's it. A contractor might be either.
2. As the hiring party, keep in mind what kind of programmer you need. E.g. if you are an enterprise, a hardware company, a services company, or a manager that thinks programmers are interchangeable, then don't follow Jeff's suggestions. You are looking for a job programmer, not a career programmer. Following Jeff's ideas will annoy your candidates, the interviewing staffers, and HR.
If you are a hiring for a company that writes software for a living (the product is the software), and/or an entrepreneur company, than the suggestions here work: you are looking for a life partner, not a jobber. The interviewer(s) will be working closely with the interviewee for a long time and must have a high confidence level that there is a fit.
For contractors, no matter what your company, the suggestions are overkill. You want someone that a. Can do the job; b. Is not an asshole. You need to pass/fail a contractor with a single interview and get them on board ASAP. They'd better be gone in 6 months, this isn't a lifetime commitment.
I am suggesting various points to keep in mind while giving a project to particular company. Company's experience, portfolio, his customer satisfaction and the way of communication to the client is most important part and if company is also supporting in the issue came after the compilation of the project then it is most trust worthy company. I had work in past with one company and i was satisfy with this so suggesting you the same :- http://www.indianic.com/iphone-programmers.html
Great post Jeff, with these tips it can help as a guide on how to hire a programmer effectively. In general the best way to hire a programmer is to try them first even on the most basic programming. Sometimes conducting an interview is just not enough to effectively determine the capabilities of a person to work. It is also one of the most common mistakes employers do when hiring. Another is when hiring don’t just stay focus on one area just like hiring only on job sites such as Monster.com, which could be a mistake for your business. Check out this article https://www.staff.com/blog/hiring-on-monster-is-it-a-mistake/ regarding hiring mistakes that you don’t want to do in your business.
For quality software development, the most important task is to hire developer who is dedicated as well as skilled and talented. In such scenario, this blog proves to be very informative. Keep it up!!!!!!!!!!!!!
Great post! I like the idea of an audition project, but have some concerns. Many companies have substantial code libraries and frameworks. If the goal is to produce code that you would want to see integrated and used in your production environment, then that code will probably need to use your code libraries, frameworks, and databases. So, the first problem is providing access to that code base and sample data. Are you really prepared to do that for a potential new hire without actually hiring them? Think about all the issues involved there - legal, potential competitor stealing / copying functionality, obtaining the code, providing a test environment, providing enough good data to test on, etc.. It could take a few days to a week just to set up the environment - depending on the company. The second problem is that getting up to speed on some projects is much, much tougher than others. C++ programming jobs in general take a longer time to come up to speed on than say Java or C#. I had a tough time coming up to speed in one of my C++ jobs in the past. Fortunately, the managers knew it was a difficult environment to learn so they did not expect very much from any of their developers for the first month or 2.
I thought Roloc (who I have never met by the way) made a good comment and from his blog post:
"1. A night or two before the interview give the person a problem. Something like, parse this file of words and print out on the screen the count of all the words that start with each letter, and end with each letter. Now it doesn’t have to be this specific problem, that is just one I came up with as I was typing it. Realistically, pick a problem that your company has recently had to solve, and won’t take hours to complete. Something simple yet forces them to cover the concepts that are important to you. For instance the above example is obviously going to need some loops and show file reading, inspection of strings etc etc.
2. Ask the person to bring the solution to the interview on a thumb drive or email it to you earlier.
3. Sit down with a projector or just around a monitor and do a code review! Let them describe what in detail the code is doing and why they chose to solve it that way. Ask them clarifying questions just like you would if you were helping out a peer."
I would add if algorithms are important, then ask the candidate to find all the possible combinations that 8 queens can be placed on a chessboard without attacking any other queen. Mix it up for different candidates. Change it to 8 rooks, 8 nights, or a mixture of pieces that don't attach each other.
I would also add a debugging problem or 2 as well as a few simple object oriented programming tasks that shows the candidate understands how to take a non-oo solution and turn it into a well designed oo solution. Whatever tests you come up with, also give them to your best developers to see how long it takes them. Don't be surprised if it takes most candidates anywhere from 3 to 5 times longer. But, I would not be discoraged by how long it takes them, especially if they completed most tasks and they were for the most part correct. Speed comes with experience.
During the interview, I also would not ask the developer to write any code on a whiteboard or a piece of paper. Again, Roloc's blog explains the reasons for this quite well.
This is really interesting and gives a lot of help to when it comes to business online. I tend to stumble around with technology but as an independent artist, the benefits of linking online content and improved ranking can only help raise the professional profile.
When a company is so proud of itself that it can't settle for less then 5 recruiters and 200 resumes (supposedly), I wish there was time for them to follow this recipe... My own experience: 1. The majority of companies ask for links but never checks portfolios and blogs of a candidate (I have a little software bird to tell me). 2. Every step except the f2f interview is replaced by a few phone screens, 40-60 minutes each, by people comparing answers with cheat sheets. It really puzzles me why it should be more then 1 of those and why it should be done over the phone, not in writing. 3. Asking for a test project is likely to result in an HR/manager permanent disappearance. 4. If a candidate brings a demo project to an interview (a short pitch) they are told there is no time to look.
YOU ARE SO WRONG! GOOD PROGRAMMER GETS JOB DONE! IT DOES NOT METTER IF HE KNOWS REGEXP OR SOMETHING LIKE THAT. I ASK ONLY ONE QUESTION (MAKE ME ARRAY OF OBJECTS!!!) IF HE KNOWS THAT THAN HE NOWS EVERYTHING SINCE THAT IS SOMETHING ONLY TOP LEVEL PROGRAMERS KNOWS HOW TO DO!
When searching for the best programmer,there are many locations to look them. Many companies choose to use the services of an career organization that focuses primarily on specialized tasks in the Technology market. The organization chooses and displays the candidates for you and only relates the most certified candidates for the position. This is a great way to complete roles quickly if the need occurs. Magento Development India
Information about to hiring when programmer which types of point to keep our mind for hiring best programmer for our site that gives by you. Not mind to about who know about computer knowledge but say to them who does not include in copmuter world please read this post and follow this point for your website development.
Web Development Company India
Hire programmer of India at lowest hourly rates, a flexible pricing option offered by India’s best offshore programming hub. The best of talent of software application and web programmers who are expert in diverse areas of web application programming.
Why not get an expert and experienced programmer for Hire?
Outsourcing Programming Services
Some good info here, but be careful asking questions like this:
> Bits and bytes. "Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"
Cultural and locale differences may leave the candidate totally confused and you thinking they are worse than they really are just because they didn't get your "geek joke".
Great tips and technique for hire developer,
Seeking a Hire Developer with High expertise and experience?
I like points which you are finest explained here.
Thanks for sharing, Keep it up!
You can Hire Developer India as per your requirement.
No offense, but if there's a facebook like button, it'll be much easier for me to share. buy facebook fans
At United IT Solution Ltd., we hire the best talent in the world for Joomla Development. This notion has become popular with the advent of the internet and the shrinking of the world into a small place. As the concept implies, the client can hire a dedicated resource in the form of an entire team to pursue his development project.
This team will work exclusively for your project either from our development centre in Bangladesh. The team can also work for the client from your location abroad as well. We have extensive hardware, software, and other infrastructure to meet your development requirements.
All our work is carried out in a reliable manner in a completely secure environment. We assure you of complete data privacy at our development centre. We offer you the most nominal rates in return for high quality services. You can rest assured of our high professionalism and commitment to excellence.
Rate/ Month (USD)
Dedicated Joomla Templates Development – Junior
Dedicated Joomla Templates Development – Senior
Dedicated Joomla Templates Development Team
(2 Junior Joomla Templates Development, 1 Senior Joomla Templates Development)
Time: 8 Hours Day, 6 Days a Week- Monday to Saturday. (Saturday half day working)
Holidays: Sundays & Bangladesh National & Religious Holidays
Looking into your complex requirements, we have developed a variety of contract plans to suit your needs. Contract plans are available for three months, six months, or even one year. All your communication needs will be met promptly through phone, fax, or email.
For this plan, billing is carried out on a monthly basis. We have no objection if you sell the application to a third party. All applications will be developed to your complete specifications within the contract period. Further, all source code will be owned by you. Contact us for your requirements today!
I now own an iPhone 5, several retina iPads, and a Nexus 7. I'm sure there are many more of these devices on the way. In the calculus of deciding what kind of computing device I want with me, even the most awesome ultraportable laptop I can find is no longer enough. how to unlock
Every clients are facing this problem when the have to choose any programmer or consultancy, I do agree with your points. they should have this type of quality. Hire PHP Programmer
Ask to see their portfolio? That's now even possible when someone is working on proprietary applications such as internal payroll systems etc. What if you are developing Middleware and backend systems? All of those are proprietary and companies have strict rules about what can be shared on social networking sites.
As for an audition project, our employee guidelines quit clearly state that working for another company at the same time is subject to disciplinary actions even possible termination.
Finally, if you think I'm leaving a PERM job for a 6-8 week contract to hire opportunity you can forget about it. Typically, corporations do 6 month contract to PERM opportunities. It can take 3 months just to become productive unless you are just cranking out emails or making DB changes.
specifically for intelligence agencies. All these recruits, he said, must be made to pass a strict personality test based on evolved and dynamic physiological and psychological aptitude tests. personality tests