Wow, full of great advice. The biggest one for me is: acknowledge applicants. I've hired and know what a hassle it can be, but use a system, and respond to everyone. Set deadlines, and if you miss them, acknowledge that. Look, this is a possible team member--why would they believe you'll treat them with respect when they are employees if you don't treat them with respect when they aren't?
Or thinking of a friend who might be a better fit for a position, or trying your product/service, or recommending your product/service, etc. The dividends of being kind and humane are pretty amazing.
I can't even begin to describe how worthless I think most coding interviews are.
Here's a contrived problem, that will never come up in our work. Now solve it by writing your code by hand without a compiler or any other tools that you would use in real life.
I understand that these questions are often about seeing how you think and how you solve problems. Throwing annoyances like writing code on a whiteboard into a high pressure situation doesn't help that at all.
Writing code by hand reveals far more than you give it credit for. Someone omits a semicolon? Bam, conversation about semicolons or ASI.
It's not about the fanciest solution. And anyone who does it that way is foolish. It's the purest test of Language facility, and a really good springboard for all kinds of questions.
Downvoters: have you actually tried to hire someone?
I didn't downvote, but I disagree and I did try to hire someone. Whiteboard questions are next to useless because they are, essentially, a guessing game. The candidates need to guess what behavior the interviewer wants them to exert. Some interviewers simply use it as an idiot filter, while others want the person to explain their reasoning, wile yet another group is stupid enough to think it's representative of real coding habits of the candidate. If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade.
In short, interpretation of whiteboard questions is too damn subjective.
That's bad interviewing, not bad practice. Get rid of the guessing. Make sure you explain to the candidate exactly what you're looking for.
I use whiteboard coding .. and it's not to catch you out on semi colons. I even tell my candidates that they can use any language they want or even mix them together or make up their own.
What I want to see on the whiteboard is a logical, working solution to a simple problem. And if your brain freezes up because it's an "interview", I'm going to push you in the right direction.
Once you have an initial working solution, we're going to chat about how it works. If there are cases where it would fail. What assumptions we've made about input. Maybe we'll (both) even jump over to another whiteboard and write a new version based on our discussion. (Do your eyes light up when we've found a cool optimization??)
The only language caveat I use: you can't have a call a function called doitforme()
(If you or anyone you know is looking for a senior PHP job in Melbourne.AU, I'm hiring. Hit me up and I'll send you to the ad on Seek)
"others want the person to explain their reasoning,"
I think far more people use whiteboard questions in that context than the article's author thinks.
" If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade."
I don't know about your experience, but in my experience candidates actually ask questions if you properly set up the problem and present an inviting atmosphere. And in my experience the best programmers are those that aren't afraid to ask good questions.
Conversation about semicolons? During a job interview? I'm sorry, but this is a waste of time. Why don't you talk about, you know, algorithms? Concurrency? Databases? Testing? Or anything that is more than remotely relevant to the job?
None of your alternatives "algorithms? Concurrency? Databases? Testing?" really test language facility. Those are important, and they have their place in the interview process, but so does language awareness.
Your whiteboard doesn't have an inbuilt syntax highlighter or linter that points out when I miss a semicolon. It's such a contrived situation that to expect perfectly written code is madness.
Personally, I'm vaguely aware that JS does ASI, but rather than waste brain space trying to understand it, I just use semicolons with everything.
And anyway, what better test of language facility is there than having the person code something? Or looking at code they've written? Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild.
Putting someone in front of a computer gives them the freedom to google (true story: I used to do a paper exam, and then I found one person was googling when I was in the bathroom and left the guy unattended for a few minutes).
"Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild."
You don't use a whiteboard when you code? I love them. The whiteboard is a nice tool for doodling and free exploration. I used to print out code and write on it, but I found that process to be much slower than the whiteboard.
No, I don't. I find them very uncomfortable to write on, and when I have to, I thus try to write as quickly as possible, resulting in messy lettering and not caring at all if I get every (or any?) semicolon in, just so long as I get ideas across.
I suppose if I had to use one in an interview I would try harder to write neatly, but my real-life day-to-day use of whiteboards is minimal.
> Putting someone in front of a computer gives them the freedom to google
And what's wrong with that? I use google several times/day to help out with programming problems. This is 2013; if your company doesn't have access to the internet (and thus Google) then people aren't going to want to work for you anyway. The problem is you're trying to set up some kind of artificial situation where you want people to solve a problem without access to readily available information.
Sure, you could have them sit down at a computer that you've unplugged from the network and have them solve your problem, but why bother?
I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial).
I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that.
I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation).
Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.
I wonder if I interviewed you. I've only ever had one or two people ask for clarification or want more detail about inputs BEFORE they start writing code.
I find that surprising. The advice I've gotten from everyone when interviewing at the big tech companies in Seattle is always "make sure you clarify ambiguity before writing any code".
I always assume that part of the evaluation is on my ability to resolve ambiguity, and always try to clarify anything I can, sometimes including writing out an example or two and verifying we agree what the expected output should be.
to be sure it wasn't writing code - whiteboarding code/pseudocode. it was a bit of an ego stroke, i think, but given the state of their company at the time, and how they advertised the position, i don't suspect they were getting many sr-level developers applying. i applied mostly cause it was close to home.
The problem is that at least 60% of people that call themselves programmers, and seemingly have no issue getting by HR, can't code fizzbuzz, let alone whatever it is you're working on.
Issue one for me as an interviewer, whenever I've needed to be in such a position, was just to figure out whether or not I was talking with a programmer.
After that though I tend to agree with you. Beyond demonstrating basic competence - which I think in the future I will look to put into some for of pre-interview screening - code writing tests don't do much.
Personally, I've found bringing my current work in with me and talking about different ways of solving the issue seems to work pretty well.
I've heard various numbers like this thrown around, but I'm having a hard time seeing how it could possibly be that high. Is that figure coming from personal experience?
I also struggle with that idea since I'm very capable of programming fizzbuzz and a lot more, but am still having a problem finding a new position.
Actually, if I went purely on personal experience it would be closer to 90%. I tempered it because I can't believe it could be anywhere that bad.
It's sad, but from what I've seen, applicants fall into two major groups, for the most part:
1. People who seem to know how to code (as in, actually use a keyboard) but who don't possess any type of critical thinking skills and can't actually figure out how a piece of code can solve a real world business problem - or even care - unless you tell them exactly how it should work. These people tend to live in big corps and stop coding completely at 4:59 everyday.
2. People with computer science degrees (the more the better) that can think up wonderful and complex solutions to the most basic of problems but can't seem to figure out a syntax error, or understand that a landing page does not require a $40K investment in the latest oracle database software, or that it doesn't matter how wonderful their design is if nobody can figure out how to use it, or that yes, it was more important to have it out last month than it was to make it run 30% faster.
Both of these hires are disasters. Unfortunately, the third group, the ones that can understand what a user is saying, design a simple way to achieve the goal, and where appropriate link it to other related features in a meaningful way, are few and far between. Most of them are working in small shops and never have the need to apply for a position via interview, since they get scooped up on reputation before that.
Well I still want to know where all those fizzbuzz claims come from.
Otherwise, I think you're largely right. But there's a lot of variation especially within that third group. I'm going to cautiously put myself into that third group. The problem is I'm probably on the lower end of that category. I'm able to make design decisions and use the things I learnt in computer science classes while still being pragmatic and solving real world problems. But I don't have a ton of experience. I often don't have language X or framework Y under my belt. And I think that's made it really difficult for me.
You seem to have a good idea of what you should be looking for, but what about all of the other interviewers? Are they just incredibly short-sighted?
And if the fizz buzz failures are actually that prolific, then I'm really at a loss as to why I'm having such a hard time finding a position.
I'm in the same boat here. It makes me wonder if I am doing something so terribly wrong that I am somehow being lumped into the same group as people who can't code.
I am in a similar situation I guess, although I also have phd not in cs and I am a foreign citizen. I do get interviews, I ask the questions and solve the coding problems and generally do well according to this and similar discussions here. I just don't understand why I can't get
a job and I'm pretty depressed by now. Even after I did Evernote programming challenge that is supposed to get you a phone interview, I've never heard from them. Sometimes I feel like I'm in one of those movies where your friends and family say they don't know who you are and somebody else lives in your apartment.
It's not a test of your ability to recollect something. It's a conversation. If you're just regurgitating the greatest code solution ever but can't explain why it's so damned good then you're not very impressive.
There ARE contrived problems that you can just regurgitate an answer for. (Why are manholes covers round? Because manholes are round duh!) And if anyone asks you one from the lists that are on the interwebs, they're probably just asking because that's What Google Does
As a coder, I couldn't agree more with the last paragraph (Let Me Code). Other than paring interview, I also like code submission. The company gives you a problem and couple of days and you write the code like you would in a real project. IMO, nothing reveals a developer's coding capability more than that.
Wow, can't tell you how much I have seen and experienced the BS that you mentioned. The company I'm with right now may be hiring soon, fwd this article to my boss. Thanks
Want to get my attention? Tell me you don't use email as a project management tool. Tell me you won't send me 5 emails a day. Tell me you don't want two status updates/meetings per day. Tell me you understand that the shotgun approach to adding features is stupid. Tell me that you don't randomly change features without any kind of data to back up the reason for making that change. Tell me you follow through on promises. Convince me you're not a fucking liar. Tell me you're offering benefits packages commensurate with your senior engineer position. After that, in addition to what OP said, I'll consider responding.
honestly, if i got a recruiting mail that emphasised a strong commitment to tool-based programming best-practices (dvcs, review, continuous integration) it would raise my interest in the company significantly.
> If you don’t have genuine passion for where you work and you do the hiring, you’re committing some kind of moral fraud. You might want to see to that.
Never really thought about this before, but I totally agree.
I completely agree with everything OP says, but I'll tell you what the real problem is: time. This is especially true in early stage startups and consultancies, where oftentimes the founders are still building stuff 95% of the time.
Recruiters are easy (as are, by the way, the new wave of non-recruiting recruiters like Developer Auction). Pay the man his money, and get a candidate in return. The founder doesn't have to spend time communicating with candidates or really doing any of the stuff OP mentions. That's why a lot of companies still hire recruiters. (Some of the companies) don't care what happens before the viable candidate walks thru the door, they just care that he/she does. It's like buying an iPad. Most of us don't think about, and don't care to think about what it took for that iPad to make it to us. We just care that it did and that it works as advertised.
Recruiting: the most important thing most companies don't have time for...
There's absolutely a better way, and in the end it's less time-consuming than what most companies do now. But the up front work is harder and more time-consuming. Convincing someone who's time is worth more than his money to adopt the better way is a hard thing to do.
I wonder if it's possible to move from employer to employer getting paid more and more by spending all your time answering questions on Stack Overflow instead of working...
A few years ago I was flown 3 hours first class and put up in a nice hotel for 2 days by a potential employer to interview in a white room with a white board for a few hours. I spoke with their development team which went great. Everyone was awesome and were very helpful.
I was then instructed to solve a problem on said white board. After I solved the problem I asked them what they were measuring with this test.
Their reply made me question the morals of said company.
They wouldn't tell me what the test was for. I asked them why. They said it was for internal review and I didn't need to know. I then asked them why I wasn't allowed to know. They had no definite answer other than that it was for their review.
After all was said and done I wished them a good day, thanked them for everything and I walked out. I got a call back a few weeks later informing me that I had another interview in a few days.
Long story-short. I turned them down. Something didn't sit right. I told them and they pretty much said, "welp, too bad for you."
Now I work at my dream job. I'm very happy I turned them down.
Thank you for putting this into words. I wanted to write something similar for a long time, but didn't get around to it.
Not only these things are frustrating for us as developers, they also decimate IT recruiting for companies. I've seen it from the other side too (while conducting some interviews). It's quite incredible, really. It's like a game. Both sides go through all the usual motions, but gain next to no useful information about each other. In the end it all boils down to unsubstantiated personal impressions, coated with some generic BS that makes it sound "objective".
(Before you ask, it's very hard to change interviewing process when you're a part of an established process with a lot of people involved.)
I've got to agree with you. I recently started getting serious about changing positions and I've become completely convinced that much of the so-called 'talent shortage' is caused by the job search process, from job listings through to interviews. Every step is unintentionally outrageous in a new way.
The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community.
Otherwise, it's a slog of browsing through hundreds of job listings, finding the one in 20 that isn't for .NET or MS-SQL or C# or Oracle, and the 1 in 50 that's not from a recruiter who's listed the same job 5 times, realizing that you aren't qualified because you haven't used the all 4 languages they care about, or maybe because you've only dabbled with some key piece of tech they're convinced you need 3 years experience with, or they won't look at candidates who need to relocate, or you absolutely need to know Red Hat when you've pretty much used Ubuntu derivatives or Arch or whatever. Then you waste time adjusting your resume, and never hear back.
Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.
Oh well.
All I need to do is start spending all my evenings and weekends on side projects while building an impressive blog to talk about coding and technology. Once it's popular with the Hacker New digerati all I'll need to do is wait... After all, we all know 'talent' is code for 'marketing.'
If my recent experiences are any indication, the secret is to go to hackathons and developer meetups. In the past I've gone through that whole painful and impersonal process you've described.
It has actually shocked me how effective this approach has been, and I wasn't even trying (I was just there to hack and learn). You get to have real conversations with people who understand you, and you can easily walk away a couple of those inside connections.
Also, the companies that send people to those events (more accurately, those that hire people who will attend of their own volition), seem to be more likely to have sane hiring processes. The two that I have been in talks with have actually made me feel "recruited," and follow most of the points in the article, which is a nice change (and I certainly don't have rockstar status or really any public image).
I recently started getting serious about changing positions and I've become completely convinced that much of the so-called 'talent shortage' is caused by the job search process, from job listings through to interviews. Every step is unintentionally outrageous in a new way.
Yep. Bilateral mismatch. Here's the dirty truth: people don't actually care about talent or even how good you are at your job. They just want to get a mission fulfilled. That'd be fine, with competent execution-- hire the right kind of person, get it done and done well, make your money and move on to something better. The problem is that it seems that 90 percent of them have no clue what they want or how to evaluate the relevant talents, and there's a hardcore Design Paradox effect going on as well.
By the way, I'm pretty well-known at this point. I'm probably in the 96-97th percentile for programming skill and 99th for loudness. It makes job searching easier to be "a quantity" and I'm finally getting to a point where it opens up some great options... but I've still dealt with a lot of frustration. It's nothing to be ashamed of.
Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.
This is a problem in stodgy bureaucracies and VC-istan. In the former, it's because in Douchebagland, one's value is based on how many reports he has-- not what those reports actually do-- so bringing in marginal people through dishonest means improves the boss's resume. In the latter, it has more to do with the way companies are valued by investors and acquirers-- some $X million per employee.
> "The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community."
You don't need to be famous, not even close. You did get it right though - you do have to know people.
Finding your next job is something you should be doing before you're actually thinking about leaving your current one. Go to meetups, look up interesting companies in your area and make yourself known to them - you'd be surprised how many people are willing to chat even with the knowledge that there's a 0% chance of you jumping ship in the foreseeable future.
It's not only a great way to get your name out there and make a few contacts, but it's also a great way to find out what's happening in your local tech community.
It is also necessary. In my experience the best employers and the best positions fulfill primarily via word of mouth. By the time a job hits a major job site it means the employer has already failed their first-choice option (i.e., a known referral by a trusted entity).
I did an interview 2 week ago. I'm not a programmer, yet, they gladly asked if I code wich I answered yes. What made me go nuts after show them all my work is, fill a questionary? one question was: "Tell us what you understand by "pixel perfect"
The problem is that recruiters carpet email (bomb) programmers, for many of them it's a numbers game. They aren't interested in taking the time to get to know you and frankly I don't expect that they do.
The best way, in my opinion, to get a new job is to be proactive and search for it yourself. Contact companies directly, use your network and see how you get on.
Recruiters sadly aren't interested making friends.
Thank you! That no recruiting recruiter email is such a buzzkill.
Even if the company itself looks interesting, just the fact that they sent some brocruiter to flood prospects with emails just makes me question the wisdom of the folks behind the company. I can appreciate a lax attitude at work up to a point, but beyond that, there's no real productivity. It's like the days before the dot com bubble when VCs were dumping cash on a potential product sold on hype.
Even if I were to get hired, what's the point if the company folds in a year?
1. Tell me about the 3 biggest things you must accomplish.
2. Tell me why you must accomplish them.
3. Tell me when you must accomplish them by.
4. Tell me how you intend to accomplish them.
5. Tell me what you're already doing to accomplish them.
6. Tell me the role you envision me playing in accomplishing them.
7. Tell me what you expect from me.
8. Put me with some of the key people already working on them.
9. Tell me what you'll do when things change or go wrong.
10. Take me to a Chinese buffet.
They're almost the same, and it probably wasn't intentional, but they're worded differently enough that you might get some surprising answers from someone if you ask them a few questions apart.
Actually, in all seriousness there is at least one start up here in Germany which hiring process consist in going for a beer with the founders and members of the team you'll work with, and only follow up if you liked each other. It's probably not very scalable for the founders as the company grows, but still an interesting approach.
(The following is made up and CERTAINLY isn't for the job I currently have open for a senior PHP dev in Melbourne.AU)
Here's why you don't see question one answered honestly:
A. Our sales guys sold our product based on feature "Foo" a year ago. We haven't started coding but they need a demo next week. You have to grok our codebase and write it on your first day.
B. The 'Bar' feature was written by a guy who should have failed finger painting, but we don't have time to rewrite it. You have to fix the many patches and modifications it's had since.
C. The 'Zap' feature was written by our cowboy programmer. You have to do all his bug fixes and modifications because he thinks he's too important for anything but new code.
While the term is firmly established within the jargon (and with good reason, it's a good word to have in the jargon), I have enough distaste for much of Heinlein's work that I don't generally use the term.
I'd have to find some other way to climb your opinion ladder ;)
Useless weekend project idea: a tool to automatically fork random repos on github and replace all variable/function/class names with one of the above much superior terms.
I absolutely hate Chinese buffets, they all feel like feeding troughs to me.
Of course, we take all our candidates out for Chinese food these days, but its kind of expected since we are in Beijing. Sometimes its difficult dealing with some foreigner's dietary restrictions (orthodox, vegetarian are hard; halal is quite easy).
1a. Show me the office I'll be working in. Any "open plan" or "2+ people per office" setup decreases your odds of hiring me by about 93%. Not to say I'll never take a job like that, but it really, really hurts your odds.
1b. Show me the rest of the building... are there common areas where people can hang out and collaborate away from their offices, preferably with natural sunlight to the area? Are there plenty of conference rooms, team rooms, or other areas for small group meetings? Do people have to fight to get a room for a meeting? Are rooms commonly "double booked" in whatever system tracks that? IS there a system for tracking room reservations? Is it Lotus Notes? If "yes" to the last question, I walk.
2. Show me the tools I'll have available to work with: Hardware, software, etc. If you're handing out ancient laptops with 1GB of RAM while expecting developers to use Springsource Tools Suite, I'm probably walking out on the spot. If you're using CVS for version control, I'm probably walking out. If you don't have a continuous integration server, I'm probably walking out.
3. Tell me about the training budget, if any. If there is no training budget, your odds just went way down.
4. Tell me about your software process. Here's where I am going to interview you. If you say "we are an Agile shop" you better be able to explain exactly what that means. Which Agile methodology do you use? Scrum? XP? Crystal? RUP? Your own made up psuedo-Agile process? Do you just use the "words" from Agile or Scrum without actually understanding them? If you use the terms "sprint" or "iteration", and "epic" and "story points" but clearly don't understand what they mean and how they should be used, I'm gone. Also, I'll want to know if the business side of the company understands and is onboard with the iterative approach with empirical feedback loops. Do execs prioritize stories for the backlog and then leave it be? Or are they randomly coming in, mid-iteration, and changing things around willy-nilly?
5. I'll want to know how many people I "report" to. If I have a "manager" telling me what to do, AND a "project manager" giving me conflicting instructions, AND random execs with an unclear relationship to the project coming along and tell me stuff, we aren't going to be together long, sorry.
6. Tell me more about the culture of the company... are people expected to be on-time for meetings? Do meetings always have agendas, and time limits? Does the company favor promoting from within? Do the execs have an "open door" policy? Are their performance reviews? How are they done? Do you make employees take any bogus "psychological profile tests"? Drug tests? Do managers go out to lunch with the "rank and file" and share a beer or two, or do managers go out in groups and pointedly avoid the riff-raff, and you'll get yelled at for having one drink with your lunch? Does the CEO interact with the "rank and file"? How? In short, convince me that this is a well run company, who respect their employees, value engagement and actually empower their people.
7. Is there any attempt to implement Kaizen or become a learning organization? Are there post-mortems for negative incidents? Do they use "Five Whys"? Are employees fired for one f%!# up, or is it more of a "support, coach and encourage" environment?
8. Are there bonuses? Profit sharing? Employee Stock Purchase programs? Stock options? What exists to align the goals of the employees with the goals of the firm as a whole, other than "I want to stay employed"?
9. Take me to eat Thai. A quality serving of Num Tok and a nice Mussuman Curry improve your odds considerably.
1. Mine are issues and yours are details. If my 10 are satisfactory, I can live with your 9, even though some may not be satisfactory. But if you 9 are good and my 10 aren't, I'd last about a year before moving on because of lack of meaning.
2. Mine are about them, yours are about you.
3. Mine show interest in the big picture; yours could easily paint you as a demanding nit-picker (whether you are or not).
Yours are important and a good list. I just don't think I ever would (or ever have) discussed them with a prospective employer.
And thanks for the tip on the Thai. I'm googling "Midtown Miami" and "Mussuman Curry" as soon as I finish typing this.
I certainly drilled down into more detail, but I'm not convinced that there's as much of a dichotomy there as you may see. Nonetheless, I understand what you're saying, but I'd counter that "details matter" and that different details matter more to some people than others. Also, I certainly don't intend that list to be seen as an alternative to your list, I mean it to be additive (from my perspective anyway).
2. Mine are about them, yours are about you.
To some extent, yes. But asking whether or not a company has, and understands, a reasonable software development methodology, or whether or not they have a culture that foster employee engagement and empowerment, is very much about them.
Mine show interest in the big picture; yours could easily paint you as a demanding nit-picker (whether you are or not).
Yes, I will say that I chose to drill down to a deeper level of detail. Basically I'm working backwards from the bad stuff I've actually seen in my career, and putting it in terms of "these things suck, I don't want to be in this environment, so convince me that this won't be the case here".
I just don't think I ever would (or ever have) discussed them with a prospective employer.
I mostly didn't in the past myself. But that was out of naivety, or fear. Either I was naive about the existence of the issue, or I felt like "I need this job too bad to be too demanding." As I've gotten older and more comfortable in my skin, and more confident in the value I can provide, I don't worry about that as much. I can walk away from a job offer, knowing there will be others.
And even if I didn't discuss these issues with potential employers, they have certainly been factors. I was invited to an interview with $BIGCORP once, went in, did the first round of interviews, and then got a phone call asking me to come back in. I politely declined. Why? I saw that all of their developers were in a big cattle shed full of low-walled cubicles - an environment that I consider "optimized for maximum distractions" and fairly inhumane. I decided they weren't a good fit for me based on that factor alone. Doesn't mean they were wrong and I was write, or vice versa, it just wasn't a fit that would have worked.
You lost me in caring about what the office looked like and what hardware you got. Who cares? I don't! I can hack on whatever; whenever; with whatever! PERIOD!
edw519's questions provoke conversation, where yours provoke sales talk.
> I can hack on whatever; whenever; with whatever!
So can everyone else, it's just not enjoyable for some people if they're stuck in a shitty office space with shitty hardware. Who wants to work at a place where they don't enjoy working?
More to the point, if you are paying someone six figures to write code, trying to save a few hundred bucks a year by giving them hardware they don't like is just plain stupid.
I mean, as an employee, I don't care that much 'cause i'll bring in my own stuff if you don't provide me with hardware I like... but my experience? employers get itchy if you do this with more than, say, a keyboard. Most places don't want me supplying my own workstation/laptop, which is fine, so long as they buy me reasonable hardware to work on.
I'm reminded of one place I contracted at where they gave me a P3 windows box (this was in the mid-oughts) - I mean, they were paying me like $70/hr. They wouldn't let me bring my own hardware, either. I go to put linux on the thing, you know, make it usable; and the IT guy finds out (well, I ask him for a blank DVD) Anyhow, he goes all 'Mordak' on me and tells me that I should just sit there in front of my useless computer and "think about what I did" or something like that.
I mean, I understand that some places want me to use their hardware, and let their IT people handle it... which is fine, if they are wiling to do a competent job of it.
"More to the point, if you are paying someone six figures to write code, trying to save a few hundred bucks a year by giving them hardware they don't like is just plain stupid."
And if the company is stupid about something as fundamental as creating a productive working environment, you can be sure they'll be stupid about lots of other things as well.
I disagree. I once tried coding an iOS app in a Windows 7 laptop using a hacked VMWare to run Mac OS X. And I will not do it again. The amount of time beach ball of death shows is greater than the time I saw the normal cursor. It's so damn hard!
So if you want me to code something for you, supply me the required hardware for it.
>edw519's questions provoke conversation, where yours provoke sales talk.
This... is actually kindof interesting. See, I would see it the other way around. Working conditions are real things that effect me day-to-day.
My experience? usually when you go work somewhere, your /actual/ job has absolutely nothing to do with what you got interviewed for. All this talk about 'the problem the company is trying to solve' is, well, marketing bullshit.
Hell, if you are hired on early, the people running the company don't (actually) know the answer to that question beyond "make enough money to cover payroll."
If you are hired on late, usually, your job is to do what your managers want, not to try to do what the company needs. Usually, if you do the latter, you will spend all your time in conflict with existing management structures.
I mean, part of that is that people are stupid, sure, and everyone wants to protect and grow their little kingdoms.
But part of that is that even if you really are as good as you think you are at your role (and most people aren't) you don't know everything.
I know that as a young sysadmin I got into a bunch of fights with my boss about how to do things. Now that I have my own company? my employees sometimes get into fights with me over the exact same things. I mean, now that I've gotta look at it from the business perspective as well as the technical perspective, I can see where my boss was coming from way back when.
Well, yes. As a non-equity employee, why should you care about "them", other than how you'll come out of working for them five years down the line? Will you have enjoyed your time there? Will you have grown as a developer?
"Creating something meaningful" only only really affects the lives of employees inasmuch as they now have something out there in the world that they can point to and brag about. That's not really as important to most people as you'd think.
The ones that it is important to? Too busy being entrepreneurs. :)
> Well, yes. As a non-equity employee, why should you care about "them", other than how you'll come out of working for them five years down the line?
Because when you work at a company you don't care for, you are contributing to a toxic environment, which can hurt your career prospects much more than a sub-par salary, by making you caustic and bitter. If you come out of a job in anything other than high spirits, that will subconsciously, but seriously, hurt you in your hunt for the next job.
I didn't say you should work at a company you don't care for. I meant that "whether the company does something I care about" will be, for most every employee, an instrumental value in their utility calculations, not a terminal value. You'll care about it, but you'll care because of what's in it for you.
I'd like to add 3 !!! after that last part, and add ... especially if people warned you ahead of time that they just fired ("lost") half their employees last year, and you shrugged.
As far as I can tell, this is quite untrue. Many of the most successful people I know are quite bitter about their previous employers. It's all about spinning that, though. It's not enough to just be bitter. You need to flatter your new employer, showing them that you jumped ship to them because they're so excellent, unlike those previous schmucks.
Everyone is bitter about their previous employers. If they wouldn't be bitter they probably wouldn't have left (except in odd case of, starting your own company,academics, research). What you are missing is - people generally have good time in companies but they leave when things go south.
For example, the startup I left - I slogged there for 4 years and I left because of some leadership changes(pressure from VCs), heck I had to leave without taking the stock options because of some technicality. Yes, I am bitter about them but out of those 4 years, 3.5 Years were incredibly fun and I learnt quite a bit. I think story repeats everywhere.
Why wouldn't you optimize for salary, if it is a bad place to work, you could, you know ... leave ... As far as becoming bitter ... sounds like a personal problem!
Is there a chance that the toxic environment derives from the people who "care" about the company, giving the culture a bit of a "too many cooks" problem? That is, not caring about the company itself can contribute to a "pure work" attitude that benefits the actual success of the business.
That's kind of interesting to me, because my questions are exactly like mindcrimes and I would never ask the kinds of questions you're interested in. I sometimes say in interviews that I'm actually not that interested in the big picture of the company, I'm much more concerned with the day-to-day issues of software construction.
Also, you seem to have a specific kind of company in mind. Your questions fit a new web startup but I can't imagine how Google (or a Wall street bank, accounting firm, consulting firm, etc.) is supposed to tell you the three biggest things they need to accomplish and when they're due. Lots of places are just looking for smart developers because there's lots of things to do rather than looking for somebody to fulfill a specific task.
Some companies have great high-level vision but terrible low-level infrastructure/culture and vice-versa. If we had to choose between the two, I suspect the two of us would make completely different choices.
"Lots of places are just looking for smart developers because there's lots of things to do rather than looking for somebody to fulfill a specific task."
That. If you are that company, I don't want to work for you.
You have to have a mission. The big hairy audacious goals guide your week to week work. If they don't then "You're doing it wrong".
If you don't know what I should be working on, then I am unlikely to be able to move you forward in a meaningful way. Sure, Google as a whole may not have a "thing" for me to work on, but each department will have it's key thing... again, if they don't, what the are they adding to google? Is my job secure? Or will I get axed in the next product that doesn't serve to organise the worlds information?
But even the biggest, hairiest, most audacious (audacious-est?) goals a company has will eventually get 'solved' to a satisfactory extent; that feature of the product you were hired to get working will be essentially "done" and go into maintenance mode, etc. Then what will the company do with you? Are they even sure you're good for anything other than the one problem they hired you to solve?
Hiring for general problem-solving ability means being able to rely on the same already-meshed team of people for your next big hairy thing.
Honestly, and I don't mean this in a bad way, I find your criticism of the parents response to you a little silly and kind off putting. If I interviewed someone and he or she put a list like that in front of me I'd probably just put in the reject pile. It's a little pompous for an interview. Just being honest.
1a. No offices, only cubes.
1b. Limited conference rooms, people ignore the reservation just enough to make it irritating.
2. No continuous integration. No Git.
3. We say there is, but there isn't.
4. As one of our supervisors said recently, "If I'm not telling you what to do, or changing your workload on a daily basis, then I feel like I'm not doing anything."
5. All of the above!
6. Most people show up for work, most of the time. Performance reviews are irrelevant. You may be evaluated on things like "dresses appropriately" when there is no dress code.
7. No, no, no. Employees are not fired. I'll let you think about where that eventually leads.
8. No. No. No. No. None.
9. Not in the budget, sorry.
That's where I work. And I wouldn't give it up for these fast paced do-or-die startups. :)
What's wrong with open plan wrt programming productivity is that it's distracting. Also, you can't have a private conversation without grabbing a real office, requiring you to move, and that takes up more time.
To be fair, plenty of people like it. I hate it. It's a personal preference. In terms of anything that's really quantifiable, I'll say that I believe "open plan" leads to a constant stream of distractions and interruptions which kills your ability to get into - and stay in - that "flow" state of maximum productivity.
It also sucks if you need to make the occasional personal phone call, or if you feel the need to pick your nose, etc., etc.
Indeed! but there is also some benefit with open plan. You can fire ideas and questions away without picking up the phone or walk down the hallway to reach your coworker cubicle or office. It also let you know your teammate better. With that being said, I am all for private space since I can think better in quiet place and dislike having people walking around my back and staring at my screen.
You completely skipped this somehow. When I was in charge of technical interviews at a large corp, we had complete morons come for interviews, that's after HR screening. Any one of them could breeze through your 10 steps, because they don't require any knowledge. Literally anybody can listen to your problems and have a free lunch at a Chinese buffet.
Sometimes I think it might be even more benign than this. Some hiring managers are already so ingrained into their work culture that it's already become transparent to them.
"Don't ask the fish about the water," and all that.
Much of this sounds like a joke [1] to me really as the most of the companies I have interviewed with won't tell all this even after signing an NDA. Even asking such questions elicits a strange look (don't you know we cannot disclose what we are working on).
A second question then is why did they ask for an NDA then, and the answer is "company policy". I have refused to sign such NDAs, and they have refused to interview me then.
Interestingly here is something that has worked: I have signed such NDAs with my annotation saying something like "It is mutually understood that this NDA is null and meaningless" right above my signatures, and they do not have any issue with that. Well, as far as I "signed" the NDA per the company policy!
This has been the case with several big name companies I have interviewed with.
[1] Not making fun of you here, rather of the companies and bureaucracy.
To companies hiring: explain who you are and what you do, what you are looking for and what the hiring process is, extra points for a FAQ. Here's an excellent example: http://www.matasano.com/careers/
There was an interviewee here today and I heard my boss tell someone to quiz him on big-o notation. I rolled my eyes.
Yesterday I had an interview that started off with "Tell me a bit about yourself." No direction as to what the interviewer wanted and, the worst part, as soon as I said I was done, he went right into asking me what the difference between "overloading" and "overriding" is.
How many years of experience do I need to have for them to stop asking me things like this? Most of my work lately is in JavaScript and Python. I had trouble answering "What's the difference between an abstract class and an interface?" That doesn't necessarily come up in those languages in a distinct way, so I'm out of practice in my vocabulary.
I have neat personal projects with source code on github. Do you really need to screen me with a phone interview?
"How many years of experience do I need to have for them to stop asking me things like this?"
It will never stop.
"Do you really need to screen me with a phone interview?"
Meh... I'm kinda split on that part of the process. I understand the frustration, and too often it's wasted time that doesn't gain anything you couldn't get from the CV itself. If done right, it can tell you if the other party is good at verbal communication, which is an important skill in its own right.
> Yesterday I had an interview that started off with "Tell me a bit about yourself."
To be fair, alot of well meaning interviewers start off that way. It's supposed to be a chance for you to mention all the good things that we may not ask about.
In fact that question is so common its a good weeder question; if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go.
I mean the interviewer basically says to you a golden opportunity to say why they should hire you. If you don't know what to say that pretty much says it all:)
Except this kind of demand for a prepared 5-minute self-pitch really tests how much you are confident and good at bullshitting, and not really anything about your skill with anything.
A person is not worthless and incapable just because they aren't huge salesmen.
No wonder women have trouble getting into this industry and getting ahead, with this kind of macho superior attitude from interviewers
> No wonder women have trouble getting into this industry and getting ahead, with this kind of macho superior attitude from interviewers
Calm down, no on one is having any kind of "macho superior attitude" :)
All I said was many interviewers start the interview this way so the interviewee has a softball question that they can use to clam themselves and make a point of anything they want the interviewer to know.
And I stand behind what I said, where if a person has a question perfectly teed up for them and they can't tell you why they should be hired then they probably won't do well with any kind of technical interview.
if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go.
Is this really true? I think if you turn it around you wouldn't agree with it so readily: if a person can blow your socks off in 5min, then you can predict how the rest of the interview will go." Well then why have the rest of the interview, or if the rest of the interview is still necessary, why go through the 5min pitch rigamarole? Why not just shave those 5min off the whole interview? Why not send the candidate on their way after they don't do their pitch-intro well? These are all rhetorical questions, but you see how I'm following the logic in your statement. I'm not judging either way, but hey, could it work any worse than the processes elsewhere described?
Heck, I wonder how a company would do if they gave the candidate 5min for whatever with the significant coworkers of the position, then take a vote from the interviewers and just hire based on the victors. Interviewers can do culture or technical interactions, doesn't matter, if they feel good about the person then they vote to hire. I guess it's like Speed Dating this way, but still.
What am I supposed to do instead of the cookie-cutter technical interview? Right now I do "Ask any question that starts with the phrase “tell me about a time when”." for most of the interview.
I'm trying to give them an opportunity to describe technical things they've done so I can drill into details and suss out if they're exaggerating their skill-set and/or incapable of communication.
For perspective, I'm a schlub at my company they grab out of the hallway to give technical interviews, not the founder or a full-time HR guy.
Just came up with this, but you could ask the interviewee to teach you something programming related that he/she learned recently. That should tell you how well they communicate, can deeply show you their level of experience (and interest), and it doesn't require that they recently revisited their notes from academia.
Another option would be to keep notes on programming challenges you hit (and the attempted and final solutions) while doing the job this person is interviewing for and ask the interviewee to walk you through how he/she would go about solving the problem.
The first one might be funner for people-persons, but I'd say the second approach would give you a much higher degree of confidence in the candidate's skills.
Completely agree with you - I frequently used to ask experienced candidates questions of the form, "tell me about one very difficult bug or performance issue encountered during your two years working on X."
Unfortunately, the number of flat-out liars on resumes is extremely large. Heck, I've even seen resumes from people I worked alongside at Microsoft who now claim to have done things that I did while there. <shrug>
Sussing that out is part of the interviewer's job, at least if you care about 1) whether you're hiring a liar 2) the skills that should have been gained if they actually spent two years working on X.
How about: hi, candidate, here's my laptop. I've created a guest account for you and installed an IDE with X programming language. Take some time to implement this original program I want done that can't be copied from google. I'll be back in 45 minutes and we can discuss your solution until our hour is up. Nice to meet you.
- Do not ask for a .doc Microsoft Word document resume
Because we might be scrambling and downloading LibreOffice and converting our .latex resume to .doc, if you want to get our attention, ask for TXT, PDF or LaTeX format.
Well, yes and no. I write everything either in LaTeX or markdown these days, but its ridiculously simple to output either of these formats to docx, so normally that's what I do. I'll always send them the PDF version of my resume first though, as good typography can make you look better.
If a job requires me to write in Word throughout the day, that's a job I don't want (in fact, writing grant proposals in Word was one of the most frustrating things about working in adeademia).
To be fair, a lot of recruiting companies or hiring companies only do that because their HR system will only import a .DOC file.
The absolute worst place I ever applied to required to you upload a version of your resume in Word format. After you hit submit, the next page wanted a plain text copy. Then, I bullshit you not, the next page was a web form in which they requested you fill out educational background, work history, references. Something you just uploaded twice!
He who is getting hired is at the mercy of the person doing the hiring. That's just how it plays out. If I'm getting hired, I have no say on how a company should conduct their interview process. Their interview process is a window into how they operate, and if it's terrible, I won't want to work for them. i would hate to have a great interview process only to find out that the company is terrible. There is a need for terrible interview processes, so long as it matches the company. The last time I had a bunch of interviews, there was a company I interviewed at, they were so terrible I knew I didn't want to work for them. At the new company, I ran into people who interviewed at same company and refused to work for them, and into two more who use to work for that company and were glad to leave.
With that said, the biggest motivation for me is compensation. I don't care what problems they are trying to solve, I don't have to love it. Want me to write in COBOL? Fine, I'll learn it. Want me to work 10hrs a day? Fine, compensate me accordingly. Everything has a price.
I find that people don't respond well to this 'mercenary' attitude. They usually want you to act like you love it, even if it's stupid. They want you to commit long-term, even if you are a temporary contractor. Etc.
Every company is like an oversensitive lover who has to be the best ever.
A job board has a 'resume wall'. It's like there's a very narrow slot in it you shove your resume through. Then you just hope. And hope. And hope. And then give up because that wall ain't talking.
Anyone ever applying to me that sends me a legitimate application WILL get a response. And if you made it to a phone interview you WILL get a phone response even if we're not continuing.
It's all about respect. (Plus, I might want to hire you next year for a different role. I'd like it if you thought highly of me. And it's not difficult to be polite)
(If you or someone you know is looking for a Senior PHP role in Melbourne.AU, hit me up and I'll point you at the ad on Seek's resume wall :-P)
Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ is an example.
Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ is an example.
Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ is an example.
265 comments
[ 2.7 ms ] story [ 219 ms ] threadBasically, it's the golden rule. It's not hard!
Here's a contrived problem, that will never come up in our work. Now solve it by writing your code by hand without a compiler or any other tools that you would use in real life.
I understand that these questions are often about seeing how you think and how you solve problems. Throwing annoyances like writing code on a whiteboard into a high pressure situation doesn't help that at all.
It's not about the fanciest solution. And anyone who does it that way is foolish. It's the purest test of Language facility, and a really good springboard for all kinds of questions.
Downvoters: have you actually tried to hire someone?
In short, interpretation of whiteboard questions is too damn subjective.
I use whiteboard coding .. and it's not to catch you out on semi colons. I even tell my candidates that they can use any language they want or even mix them together or make up their own.
What I want to see on the whiteboard is a logical, working solution to a simple problem. And if your brain freezes up because it's an "interview", I'm going to push you in the right direction.
Once you have an initial working solution, we're going to chat about how it works. If there are cases where it would fail. What assumptions we've made about input. Maybe we'll (both) even jump over to another whiteboard and write a new version based on our discussion. (Do your eyes light up when we've found a cool optimization??)
The only language caveat I use: you can't have a call a function called doitforme()
(If you or anyone you know is looking for a senior PHP job in Melbourne.AU, I'm hiring. Hit me up and I'll send you to the ad on Seek)
I think far more people use whiteboard questions in that context than the article's author thinks.
" If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade."
I don't know about your experience, but in my experience candidates actually ask questions if you properly set up the problem and present an inviting atmosphere. And in my experience the best programmers are those that aren't afraid to ask good questions.
None of your alternatives "algorithms? Concurrency? Databases? Testing?" really test language facility. Those are important, and they have their place in the interview process, but so does language awareness.
And anyway, what better test of language facility is there than having the person code something? Or looking at code they've written? Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild.
"Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild."
You don't use a whiteboard when you code? I love them. The whiteboard is a nice tool for doodling and free exploration. I used to print out code and write on it, but I found that process to be much slower than the whiteboard.
So? I use google all the time while coding.
No, I don't. I find them very uncomfortable to write on, and when I have to, I thus try to write as quickly as possible, resulting in messy lettering and not caring at all if I get every (or any?) semicolon in, just so long as I get ideas across.
I suppose if I had to use one in an interview I would try harder to write neatly, but my real-life day-to-day use of whiteboards is minimal.
And what's wrong with that? I use google several times/day to help out with programming problems. This is 2013; if your company doesn't have access to the internet (and thus Google) then people aren't going to want to work for you anyway. The problem is you're trying to set up some kind of artificial situation where you want people to solve a problem without access to readily available information.
Sure, you could have them sit down at a computer that you've unplugged from the network and have them solve your problem, but why bother?
Would you hire someone who has to google for an answer to fizzbuzz?
No, but there's very little utility in someone solving fizz buzz with or without google. Give them a real test and let them use google.
But I think there should also be a real test, with Internet access available.
I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial).
I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that.
I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation).
Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.
I always assume that part of the evaluation is on my ability to resolve ambiguity, and always try to clarify anything I can, sometimes including writing out an example or two and verifying we agree what the expected output should be.
Issue one for me as an interviewer, whenever I've needed to be in such a position, was just to figure out whether or not I was talking with a programmer.
After that though I tend to agree with you. Beyond demonstrating basic competence - which I think in the future I will look to put into some for of pre-interview screening - code writing tests don't do much.
Personally, I've found bringing my current work in with me and talking about different ways of solving the issue seems to work pretty well.
I also struggle with that idea since I'm very capable of programming fizzbuzz and a lot more, but am still having a problem finding a new position.
Actually, if I went purely on personal experience it would be closer to 90%. I tempered it because I can't believe it could be anywhere that bad.
It's sad, but from what I've seen, applicants fall into two major groups, for the most part:
1. People who seem to know how to code (as in, actually use a keyboard) but who don't possess any type of critical thinking skills and can't actually figure out how a piece of code can solve a real world business problem - or even care - unless you tell them exactly how it should work. These people tend to live in big corps and stop coding completely at 4:59 everyday.
2. People with computer science degrees (the more the better) that can think up wonderful and complex solutions to the most basic of problems but can't seem to figure out a syntax error, or understand that a landing page does not require a $40K investment in the latest oracle database software, or that it doesn't matter how wonderful their design is if nobody can figure out how to use it, or that yes, it was more important to have it out last month than it was to make it run 30% faster.
Both of these hires are disasters. Unfortunately, the third group, the ones that can understand what a user is saying, design a simple way to achieve the goal, and where appropriate link it to other related features in a meaningful way, are few and far between. Most of them are working in small shops and never have the need to apply for a position via interview, since they get scooped up on reputation before that.
Otherwise, I think you're largely right. But there's a lot of variation especially within that third group. I'm going to cautiously put myself into that third group. The problem is I'm probably on the lower end of that category. I'm able to make design decisions and use the things I learnt in computer science classes while still being pragmatic and solving real world problems. But I don't have a ton of experience. I often don't have language X or framework Y under my belt. And I think that's made it really difficult for me.
You seem to have a good idea of what you should be looking for, but what about all of the other interviewers? Are they just incredibly short-sighted?
And if the fizz buzz failures are actually that prolific, then I'm really at a loss as to why I'm having such a hard time finding a position.
Want to exchange e-mails and chat about it?
There ARE contrived problems that you can just regurgitate an answer for. (Why are manholes covers round? Because manholes are round duh!) And if anyone asks you one from the lists that are on the interwebs, they're probably just asking because that's What Google Does
Never really thought about this before, but I totally agree.
All this kind of statement will do is make companies extract faked workgasms from their employees every day.
I completely agree with everything OP says, but I'll tell you what the real problem is: time. This is especially true in early stage startups and consultancies, where oftentimes the founders are still building stuff 95% of the time.
Recruiters are easy (as are, by the way, the new wave of non-recruiting recruiters like Developer Auction). Pay the man his money, and get a candidate in return. The founder doesn't have to spend time communicating with candidates or really doing any of the stuff OP mentions. That's why a lot of companies still hire recruiters. (Some of the companies) don't care what happens before the viable candidate walks thru the door, they just care that he/she does. It's like buying an iPad. Most of us don't think about, and don't care to think about what it took for that iPad to make it to us. We just care that it did and that it works as advertised.
Recruiting: the most important thing most companies don't have time for...
There's absolutely a better way, and in the end it's less time-consuming than what most companies do now. But the up front work is harder and more time-consuming. Convincing someone who's time is worth more than his money to adopt the better way is a hard thing to do.
I was then instructed to solve a problem on said white board. After I solved the problem I asked them what they were measuring with this test.
Their reply made me question the morals of said company.
They wouldn't tell me what the test was for. I asked them why. They said it was for internal review and I didn't need to know. I then asked them why I wasn't allowed to know. They had no definite answer other than that it was for their review.
After all was said and done I wished them a good day, thanked them for everything and I walked out. I got a call back a few weeks later informing me that I had another interview in a few days.
Long story-short. I turned them down. Something didn't sit right. I told them and they pretty much said, "welp, too bad for you."
Now I work at my dream job. I'm very happy I turned them down.
Not only these things are frustrating for us as developers, they also decimate IT recruiting for companies. I've seen it from the other side too (while conducting some interviews). It's quite incredible, really. It's like a game. Both sides go through all the usual motions, but gain next to no useful information about each other. In the end it all boils down to unsubstantiated personal impressions, coated with some generic BS that makes it sound "objective".
(Before you ask, it's very hard to change interviewing process when you're a part of an established process with a lot of people involved.)
The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community.
Otherwise, it's a slog of browsing through hundreds of job listings, finding the one in 20 that isn't for .NET or MS-SQL or C# or Oracle, and the 1 in 50 that's not from a recruiter who's listed the same job 5 times, realizing that you aren't qualified because you haven't used the all 4 languages they care about, or maybe because you've only dabbled with some key piece of tech they're convinced you need 3 years experience with, or they won't look at candidates who need to relocate, or you absolutely need to know Red Hat when you've pretty much used Ubuntu derivatives or Arch or whatever. Then you waste time adjusting your resume, and never hear back.
Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.
Oh well. All I need to do is start spending all my evenings and weekends on side projects while building an impressive blog to talk about coding and technology. Once it's popular with the Hacker New digerati all I'll need to do is wait... After all, we all know 'talent' is code for 'marketing.'
It has actually shocked me how effective this approach has been, and I wasn't even trying (I was just there to hack and learn). You get to have real conversations with people who understand you, and you can easily walk away a couple of those inside connections.
Also, the companies that send people to those events (more accurately, those that hire people who will attend of their own volition), seem to be more likely to have sane hiring processes. The two that I have been in talks with have actually made me feel "recruited," and follow most of the points in the article, which is a nice change (and I certainly don't have rockstar status or really any public image).
Yep. Bilateral mismatch. Here's the dirty truth: people don't actually care about talent or even how good you are at your job. They just want to get a mission fulfilled. That'd be fine, with competent execution-- hire the right kind of person, get it done and done well, make your money and move on to something better. The problem is that it seems that 90 percent of them have no clue what they want or how to evaluate the relevant talents, and there's a hardcore Design Paradox effect going on as well.
By the way, I'm pretty well-known at this point. I'm probably in the 96-97th percentile for programming skill and 99th for loudness. It makes job searching easier to be "a quantity" and I'm finally getting to a point where it opens up some great options... but I've still dealt with a lot of frustration. It's nothing to be ashamed of.
Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.
This is a problem in stodgy bureaucracies and VC-istan. In the former, it's because in Douchebagland, one's value is based on how many reports he has-- not what those reports actually do-- so bringing in marginal people through dishonest means improves the boss's resume. In the latter, it has more to do with the way companies are valued by investors and acquirers-- some $X million per employee.
You don't need to be famous, not even close. You did get it right though - you do have to know people.
Finding your next job is something you should be doing before you're actually thinking about leaving your current one. Go to meetups, look up interesting companies in your area and make yourself known to them - you'd be surprised how many people are willing to chat even with the knowledge that there's a 0% chance of you jumping ship in the foreseeable future.
It's not only a great way to get your name out there and make a few contacts, but it's also a great way to find out what's happening in your local tech community.
It is also necessary. In my experience the best employers and the best positions fulfill primarily via word of mouth. By the time a job hits a major job site it means the employer has already failed their first-choice option (i.e., a known referral by a trusted entity).
The best way, in my opinion, to get a new job is to be proactive and search for it yourself. Contact companies directly, use your network and see how you get on.
Recruiters sadly aren't interested making friends.
Even if the company itself looks interesting, just the fact that they sent some brocruiter to flood prospects with emails just makes me question the wisdom of the folks behind the company. I can appreciate a lax attitude at work up to a point, but beyond that, there's no real productivity. It's like the days before the dot com bubble when VCs were dumping cash on a potential product sold on hype.
Even if I were to get hired, what's the point if the company folds in a year?
6. Architecture, TDD, code
7. 8 hour days, but available in emergencies at night.
P.S. (The secret is that good and cost are not in direct correspondence across the population of Chinese buffets.)
No need for the rest, this will do.
Actually, in all seriousness there is at least one start up here in Germany which hiring process consist in going for a beer with the founders and members of the team you'll work with, and only follow up if you liked each other. It's probably not very scalable for the founders as the company grows, but still an interesting approach.
Here's why you don't see question one answered honestly:
A. Our sales guys sold our product based on feature "Foo" a year ago. We haven't started coding but they need a demo next week. You have to grok our codebase and write it on your first day.
B. The 'Bar' feature was written by a guy who should have failed finger painting, but we don't have time to rewrite it. You have to fix the many patches and modifications it's had since.
C. The 'Zap' feature was written by our cowboy programmer. You have to do all his bug fixes and modifications because he thinks he's too important for anything but new code.
When hiring engineers (or speaking to any anyone ever again) NEVER use the word 'grok.'
I'd have to find some other way to climb your opinion ladder ;)
If I need more than that, then I should probably simplify what I'm writing, or use more descriptive names.
I've had so many bad experiences with Chinese buffets that I steer clear of any place that would suggest that.
Of course, we take all our candidates out for Chinese food these days, but its kind of expected since we are in Beijing. Sometimes its difficult dealing with some foreigner's dietary restrictions (orthodox, vegetarian are hard; halal is quite easy).
1a. Show me the office I'll be working in. Any "open plan" or "2+ people per office" setup decreases your odds of hiring me by about 93%. Not to say I'll never take a job like that, but it really, really hurts your odds.
1b. Show me the rest of the building... are there common areas where people can hang out and collaborate away from their offices, preferably with natural sunlight to the area? Are there plenty of conference rooms, team rooms, or other areas for small group meetings? Do people have to fight to get a room for a meeting? Are rooms commonly "double booked" in whatever system tracks that? IS there a system for tracking room reservations? Is it Lotus Notes? If "yes" to the last question, I walk.
2. Show me the tools I'll have available to work with: Hardware, software, etc. If you're handing out ancient laptops with 1GB of RAM while expecting developers to use Springsource Tools Suite, I'm probably walking out on the spot. If you're using CVS for version control, I'm probably walking out. If you don't have a continuous integration server, I'm probably walking out.
3. Tell me about the training budget, if any. If there is no training budget, your odds just went way down.
4. Tell me about your software process. Here's where I am going to interview you. If you say "we are an Agile shop" you better be able to explain exactly what that means. Which Agile methodology do you use? Scrum? XP? Crystal? RUP? Your own made up psuedo-Agile process? Do you just use the "words" from Agile or Scrum without actually understanding them? If you use the terms "sprint" or "iteration", and "epic" and "story points" but clearly don't understand what they mean and how they should be used, I'm gone. Also, I'll want to know if the business side of the company understands and is onboard with the iterative approach with empirical feedback loops. Do execs prioritize stories for the backlog and then leave it be? Or are they randomly coming in, mid-iteration, and changing things around willy-nilly?
5. I'll want to know how many people I "report" to. If I have a "manager" telling me what to do, AND a "project manager" giving me conflicting instructions, AND random execs with an unclear relationship to the project coming along and tell me stuff, we aren't going to be together long, sorry.
6. Tell me more about the culture of the company... are people expected to be on-time for meetings? Do meetings always have agendas, and time limits? Does the company favor promoting from within? Do the execs have an "open door" policy? Are their performance reviews? How are they done? Do you make employees take any bogus "psychological profile tests"? Drug tests? Do managers go out to lunch with the "rank and file" and share a beer or two, or do managers go out in groups and pointedly avoid the riff-raff, and you'll get yelled at for having one drink with your lunch? Does the CEO interact with the "rank and file"? How? In short, convince me that this is a well run company, who respect their employees, value engagement and actually empower their people.
7. Is there any attempt to implement Kaizen or become a learning organization? Are there post-mortems for negative incidents? Do they use "Five Whys"? Are employees fired for one f%!# up, or is it more of a "support, coach and encourage" environment?
8. Are there bonuses? Profit sharing? Employee Stock Purchase programs? Stock options? What exists to align the goals of the employees with the goals of the firm as a whole, other than "I want to stay employed"?
9. Take me to eat Thai. A quality serving of Num Tok and a nice Mussuman Curry improve your odds considerably.
1. Mine are issues and yours are details. If my 10 are satisfactory, I can live with your 9, even though some may not be satisfactory. But if you 9 are good and my 10 aren't, I'd last about a year before moving on because of lack of meaning.
2. Mine are about them, yours are about you.
3. Mine show interest in the big picture; yours could easily paint you as a demanding nit-picker (whether you are or not).
Yours are important and a good list. I just don't think I ever would (or ever have) discussed them with a prospective employer.
And thanks for the tip on the Thai. I'm googling "Midtown Miami" and "Mussuman Curry" as soon as I finish typing this.
I certainly drilled down into more detail, but I'm not convinced that there's as much of a dichotomy there as you may see. Nonetheless, I understand what you're saying, but I'd counter that "details matter" and that different details matter more to some people than others. Also, I certainly don't intend that list to be seen as an alternative to your list, I mean it to be additive (from my perspective anyway).
2. Mine are about them, yours are about you.
To some extent, yes. But asking whether or not a company has, and understands, a reasonable software development methodology, or whether or not they have a culture that foster employee engagement and empowerment, is very much about them.
Mine show interest in the big picture; yours could easily paint you as a demanding nit-picker (whether you are or not).
Yes, I will say that I chose to drill down to a deeper level of detail. Basically I'm working backwards from the bad stuff I've actually seen in my career, and putting it in terms of "these things suck, I don't want to be in this environment, so convince me that this won't be the case here".
I just don't think I ever would (or ever have) discussed them with a prospective employer.
I mostly didn't in the past myself. But that was out of naivety, or fear. Either I was naive about the existence of the issue, or I felt like "I need this job too bad to be too demanding." As I've gotten older and more comfortable in my skin, and more confident in the value I can provide, I don't worry about that as much. I can walk away from a job offer, knowing there will be others.
And even if I didn't discuss these issues with potential employers, they have certainly been factors. I was invited to an interview with $BIGCORP once, went in, did the first round of interviews, and then got a phone call asking me to come back in. I politely declined. Why? I saw that all of their developers were in a big cattle shed full of low-walled cubicles - an environment that I consider "optimized for maximum distractions" and fairly inhumane. I decided they weren't a good fit for me based on that factor alone. Doesn't mean they were wrong and I was write, or vice versa, it just wasn't a fit that would have worked.
edw519's questions provoke conversation, where yours provoke sales talk.
So can everyone else, it's just not enjoyable for some people if they're stuck in a shitty office space with shitty hardware. Who wants to work at a place where they don't enjoy working?
I mean, as an employee, I don't care that much 'cause i'll bring in my own stuff if you don't provide me with hardware I like... but my experience? employers get itchy if you do this with more than, say, a keyboard. Most places don't want me supplying my own workstation/laptop, which is fine, so long as they buy me reasonable hardware to work on.
I'm reminded of one place I contracted at where they gave me a P3 windows box (this was in the mid-oughts) - I mean, they were paying me like $70/hr. They wouldn't let me bring my own hardware, either. I go to put linux on the thing, you know, make it usable; and the IT guy finds out (well, I ask him for a blank DVD) Anyhow, he goes all 'Mordak' on me and tells me that I should just sit there in front of my useless computer and "think about what I did" or something like that.
I mean, I understand that some places want me to use their hardware, and let their IT people handle it... which is fine, if they are wiling to do a competent job of it.
And if the company is stupid about something as fundamental as creating a productive working environment, you can be sure they'll be stupid about lots of other things as well.
So if you want me to code something for you, supply me the required hardware for it.
And no, you can't hack on whatever hardware.
This... is actually kindof interesting. See, I would see it the other way around. Working conditions are real things that effect me day-to-day.
My experience? usually when you go work somewhere, your /actual/ job has absolutely nothing to do with what you got interviewed for. All this talk about 'the problem the company is trying to solve' is, well, marketing bullshit.
Hell, if you are hired on early, the people running the company don't (actually) know the answer to that question beyond "make enough money to cover payroll."
If you are hired on late, usually, your job is to do what your managers want, not to try to do what the company needs. Usually, if you do the latter, you will spend all your time in conflict with existing management structures.
I mean, part of that is that people are stupid, sure, and everyone wants to protect and grow their little kingdoms.
But part of that is that even if you really are as good as you think you are at your role (and most people aren't) you don't know everything.
I know that as a young sysadmin I got into a bunch of fights with my boss about how to do things. Now that I have my own company? my employees sometimes get into fights with me over the exact same things. I mean, now that I've gotta look at it from the business perspective as well as the technical perspective, I can see where my boss was coming from way back when.
Well, yes. As a non-equity employee, why should you care about "them", other than how you'll come out of working for them five years down the line? Will you have enjoyed your time there? Will you have grown as a developer?
"Creating something meaningful" only only really affects the lives of employees inasmuch as they now have something out there in the world that they can point to and brag about. That's not really as important to most people as you'd think.
The ones that it is important to? Too busy being entrepreneurs. :)
Because when you work at a company you don't care for, you are contributing to a toxic environment, which can hurt your career prospects much more than a sub-par salary, by making you caustic and bitter. If you come out of a job in anything other than high spirits, that will subconsciously, but seriously, hurt you in your hunt for the next job.
For example, the startup I left - I slogged there for 4 years and I left because of some leadership changes(pressure from VCs), heck I had to leave without taking the stock options because of some technicality. Yes, I am bitter about them but out of those 4 years, 3.5 Years were incredibly fun and I learnt quite a bit. I think story repeats everywhere.
Also, you seem to have a specific kind of company in mind. Your questions fit a new web startup but I can't imagine how Google (or a Wall street bank, accounting firm, consulting firm, etc.) is supposed to tell you the three biggest things they need to accomplish and when they're due. Lots of places are just looking for smart developers because there's lots of things to do rather than looking for somebody to fulfill a specific task.
Some companies have great high-level vision but terrible low-level infrastructure/culture and vice-versa. If we had to choose between the two, I suspect the two of us would make completely different choices.
That. If you are that company, I don't want to work for you.
You have to have a mission. The big hairy audacious goals guide your week to week work. If they don't then "You're doing it wrong".
If you don't know what I should be working on, then I am unlikely to be able to move you forward in a meaningful way. Sure, Google as a whole may not have a "thing" for me to work on, but each department will have it's key thing... again, if they don't, what the are they adding to google? Is my job secure? Or will I get axed in the next product that doesn't serve to organise the worlds information?
Hiring for general problem-solving ability means being able to rely on the same already-meshed team of people for your next big hairy thing.
That's where I work. And I wouldn't give it up for these fast paced do-or-die startups. :)
I just don't think a company is going to answer many of these questions. They might think you are a spy for the competition :).
It also sucks if you need to make the occasional personal phone call, or if you feel the need to pick your nose, etc., etc.
fuck you, arsehole
You completely skipped this somehow. When I was in charge of technical interviews at a large corp, we had complete morons come for interviews, that's after HR screening. Any one of them could breeze through your 10 steps, because they don't require any knowledge. Literally anybody can listen to your problems and have a free lunch at a Chinese buffet.
"Don't ask the fish about the water," and all that.
A second question then is why did they ask for an NDA then, and the answer is "company policy". I have refused to sign such NDAs, and they have refused to interview me then.
Interestingly here is something that has worked: I have signed such NDAs with my annotation saying something like "It is mutually understood that this NDA is null and meaningless" right above my signatures, and they do not have any issue with that. Well, as far as I "signed" the NDA per the company policy!
This has been the case with several big name companies I have interviewed with.
[1] Not making fun of you here, rather of the companies and bureaucracy.
There was an interviewee here today and I heard my boss tell someone to quiz him on big-o notation. I rolled my eyes.
Yesterday I had an interview that started off with "Tell me a bit about yourself." No direction as to what the interviewer wanted and, the worst part, as soon as I said I was done, he went right into asking me what the difference between "overloading" and "overriding" is.
How many years of experience do I need to have for them to stop asking me things like this? Most of my work lately is in JavaScript and Python. I had trouble answering "What's the difference between an abstract class and an interface?" That doesn't necessarily come up in those languages in a distinct way, so I'm out of practice in my vocabulary.
I have neat personal projects with source code on github. Do you really need to screen me with a phone interview?
It will never stop.
"Do you really need to screen me with a phone interview?"
Meh... I'm kinda split on that part of the process. I understand the frustration, and too often it's wasted time that doesn't gain anything you couldn't get from the CV itself. If done right, it can tell you if the other party is good at verbal communication, which is an important skill in its own right.
To be fair, alot of well meaning interviewers start off that way. It's supposed to be a chance for you to mention all the good things that we may not ask about.
In fact that question is so common its a good weeder question; if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go.
I mean the interviewer basically says to you a golden opportunity to say why they should hire you. If you don't know what to say that pretty much says it all:)
A person is not worthless and incapable just because they aren't huge salesmen.
No wonder women have trouble getting into this industry and getting ahead, with this kind of macho superior attitude from interviewers
Calm down, no on one is having any kind of "macho superior attitude" :)
All I said was many interviewers start the interview this way so the interviewee has a softball question that they can use to clam themselves and make a point of anything they want the interviewer to know.
And I stand behind what I said, where if a person has a question perfectly teed up for them and they can't tell you why they should be hired then they probably won't do well with any kind of technical interview.
Test coders on how to code, not on how to sell.
Is this really true? I think if you turn it around you wouldn't agree with it so readily: if a person can blow your socks off in 5min, then you can predict how the rest of the interview will go." Well then why have the rest of the interview, or if the rest of the interview is still necessary, why go through the 5min pitch rigamarole? Why not just shave those 5min off the whole interview? Why not send the candidate on their way after they don't do their pitch-intro well? These are all rhetorical questions, but you see how I'm following the logic in your statement. I'm not judging either way, but hey, could it work any worse than the processes elsewhere described?
Heck, I wonder how a company would do if they gave the candidate 5min for whatever with the significant coworkers of the position, then take a vote from the interviewers and just hire based on the victors. Interviewers can do culture or technical interactions, doesn't matter, if they feel good about the person then they vote to hire. I guess it's like Speed Dating this way, but still.
I'm trying to give them an opportunity to describe technical things they've done so I can drill into details and suss out if they're exaggerating their skill-set and/or incapable of communication.
For perspective, I'm a schlub at my company they grab out of the hallway to give technical interviews, not the founder or a full-time HR guy.
Another option would be to keep notes on programming challenges you hit (and the attempted and final solutions) while doing the job this person is interviewing for and ask the interviewee to walk you through how he/she would go about solving the problem.
Unfortunately, the number of flat-out liars on resumes is extremely large. Heck, I've even seen resumes from people I worked alongside at Microsoft who now claim to have done things that I did while there. <shrug>
Sussing that out is part of the interviewer's job, at least if you care about 1) whether you're hiring a liar 2) the skills that should have been gained if they actually spent two years working on X.
1) contribute to some open source project.
2) get a beer with the company's dev team at a hackathon.
3) job offer.
- Do not ask for a .doc Microsoft Word document resume
Because we might be scrambling and downloading LibreOffice and converting our .latex resume to .doc, if you want to get our attention, ask for TXT, PDF or LaTeX format.
If a job requires me to write in Word throughout the day, that's a job I don't want (in fact, writing grant proposals in Word was one of the most frustrating things about working in adeademia).
The absolute worst place I ever applied to required to you upload a version of your resume in Word format. After you hit submit, the next page wanted a plain text copy. Then, I bullshit you not, the next page was a web form in which they requested you fill out educational background, work history, references. Something you just uploaded twice!
Thats hilarious. I recently was job hunting and I ignored prob 20% of position due to that fact alone.
With that said, the biggest motivation for me is compensation. I don't care what problems they are trying to solve, I don't have to love it. Want me to write in COBOL? Fine, I'll learn it. Want me to work 10hrs a day? Fine, compensate me accordingly. Everything has a price.
Every company is like an oversensitive lover who has to be the best ever.
Anyone ever applying to me that sends me a legitimate application WILL get a response. And if you made it to a phone interview you WILL get a phone response even if we're not continuing.
It's all about respect. (Plus, I might want to hire you next year for a different role. I'd like it if you thought highly of me. And it's not difficult to be polite)
(If you or someone you know is looking for a Senior PHP role in Melbourne.AU, hit me up and I'll point you at the ad on Seek's resume wall :-P)