Earlier quoted context omitted.
I was told by someone many years ago to always take a copy of my resume with me to an interview. That advice has paid off a couple of times. These days I also keep an email draft ready to send.
While that's good advice, I don't follow it. If a company doesn't have their shit together enough to coordinate an interview schedule and get the right people into the right room at the right time with my resume in their hands, ideally in their hands ahead of time, I don't want to work there. It's a basic competence test.
Inverting Binary Trees Considered Harmful
161–170 of 225 posts
Re: Inverting Binary Trees Considered Harmful
#162This passage gives me a good idea: The OPower guy said they had a ton of problems where they will be using Scalding, so I asked him what they are doing in its absence. He said Oh we pojo it. Then he said pojo this and pojo that, and soon I was drowning in pojos, so I asked, Sorry, what exactly is a pojo ? Now, bear in mind I am a Scala programmer and haven't touched Java in ages, and they knew that. Their whole pitch…
pojo is a common term for java devs, at least any who have been molested by spring
Re: Inverting Binary Trees Considered Harmful
#163Re: Inverting Binary Trees Considered Harmful
#164I feel that interviews are essential. Every alternative I've heard seems to not work. I've tried.
0. Review their contributions to open source
--a. Some brilliant people have none - they prefer to get paid for their work & not disseminate it openly for free - that does not mean they should be disqualified
--b. I've personally seen people with stellar resumes claiming to have contributed to many projects who could not even tell me when they'd use a hashtable in any scenario of their choice
1. Ask about their last project
--a. It is easy to lie, to any level of detail. Anyone who tells you otherwise has never watched a politician speak.
--b. Speaking about engineering (even well) does not mean you can actually engineer well.
2. Pair program with them
--a. This tends to waste a lot of time, since either you use an abstract problem (and you're back to a normal interview) or you use a real problem and you spend 10000 hours explaining it.
3. Hire them on a trial period
--a. This is insulting to the brilliant people
--b. This is a waste of company time on the not brilliant people
Re: Inverting Binary Trees Considered Harmful
#165[speaking for myself only, not my employers past or present] [I am guessing this will be an unpopular opinion, so posting anonymously] I feel that interviews are essential. Every alternative I've heard seems to not work. I've tried. 0. Review their contributions to open source --a. Some brilliant people have none - they prefer to get paid for their work & not disseminate it openly for free - that does not mean they s…
This is a sellers market anyway.
What we found works is asking practical questions and not theoretical ones. You can ask people to code with a computer and internet and whatever editor they want simulating a real environment.
Re: Inverting Binary Trees Considered Harmful
#166While I'm completely, 100%, against these kinds of questions, how else can a company that receives thousands of resumes a day filter out the good from bad?
It's actually not that hard -- invite them to work with you on a small project. Pay them reasonably. See how they work in RL. Then decide, and -- by all means -- give them honest feedback even when not hiring.
Generally you tend to be given a few tasks that are representative for the work you will be doing if you get hired. This is similar to spec work (e.g. the result will typically be discarded unless it is exceptionally good and solves real-world problems) but typically you will be reimbursed if you are not hired.
For a programming job you may be given a task that doesn't require intimate knowledge of any of the company's codebases but should give some insights into how you work, followed by a short review.
It's important to note that this doesn't scale well. It works best if the candidate works on site and can work alongside future team mates, which may impact the team's productivity for the duration. This approach works best for small to medium scale companies with a small pool of viable candidates. It's beneficial for the company to only send a candidate through this process if they're very likely to hire them.
I actually prefer this approach. By the time you're invited for "Probearbeiten" both sides are fairly confident you're going to be hired and it gives both sides a chance to determine whether it's a good fit.
It should also be noted that even in companies that don't do "Probearbeiten" there's a trial period ("Probezeit") after you're hired of up to six months where you're pretty much employed "at will" and can be fired on the spot.
Re: Inverting Binary Trees Considered Harmful
#167Re: Inverting Binary Trees Considered Harmful
#168The rules are pretty clear on what the interview will cover. The recruiter tells you months before the interview and they (Google) even send you a list of what books and papers to read before you consider yourself ready. That is more than fair. I just joined a start up. It consists of 3 non-minorities and 3 minorities. All three non-minorities were recruited early on because they all knew someone within the company (…
I applied for a software engineer position. I was rejected when I couldn't answer system administration questions (the guy asking the questions was a system administrator at Google)
Re: Inverting Binary Trees Considered Harmful
#169Interviewer: "Can you show me on the whiteboard how you would invert a binary tree?" You: "Of course." Writes on whiteboard. Interviewer: "Excellent!" You: "Your turn. Can you show me on the whiteboard how you would implement a priority queue first with O(1) insert and O(n) remove complexity, and then with O(n log n) insert and remove complexity."
I think even better would be to solve a problem on the whiteboard WITH the interviewer: one which the interviewer did not know or prepare an answer to.
- First, it would reflect the type of problems you may have to solve in the role you're interviewing for.
- Second, it demonstrates your interpersonal skills, your ability to de-construct, understand and then solve the problem at hand.
- Third, it demonstrates how you work with others to solve a technical problem.
- Finally, it puts both the interviewer and interviewee on the same level. It's not so much of "you v.s. me", but a "we". Hopefully, by the end the interviewer thinks: "Hey, I'd really like to work with this person. They're really smart, solved the problem faster than I could, they were very easy to work with, etc."
I think this would make technical interviews more fair, more fun, and at last, representative of real work you would do in the role as I doubt the interviewer will want to solve the 8 queens problem under pressure either.
Re: Inverting Binary Trees Considered Harmful
#170I recently interviewed for (and got) a new job. The interview process took about two weeks and on the whole was pretty reasonable for both sides. There was a short phone screen (~30 minutes) Then I had two technical exercises to do. For each, I was given a reasonable time period (4 hours) that started when I visited a special link to the get the problem description, and then used whatever tools I wanted to get it don…
The correct way to write a CSV parser is to import one.