You might have heard that Google is looking to hire some 6,000 new employees this year. What that means is a lot of time spent by recruiters looking for candidates, talking with them, and then setting them up with one of us for a phone interview. If that goes well, we invite you onsite for a day’s worth of more intensive interviews, and if everything matches up we extend an offer, you take it, and you become a Noogler.
As it turns out, I get to do a lot of these phone screens, at least for aspiring front-end developers. And I’m frustrated by how bad it usually goes; that is, the interview itself was already a waste of time, but it’s compounded by the necessity to write a detailed account of the conversation to avoid frivolous discrimination lawsuits.
Of course, this is not a new problem; the reason why we don’t just bring everybody on-site immediately is that it’s better to waste one person’s time and discover a bad match than it is to waste 4–5 people’s time to make the same conclusion. That said, if you’re applying to an engineering position, here are some tips to save everyone some time and unnecessary frustration.
Clean up your resume
Be honest about what you know and what you don’t know in your resume. Yes, putting in a bunch of buzzwords will get you noticed by the recruiter, but quantify your experience with various technologies (e.g., “I’ve worked in: C++, Java; I’m familiar with: Python, Rails) so I know what’s fair game.
For whatever reason, front-end engineering candidates are particularly offensive; I’ll see someone put “expert in Javascript” on their resume, only to find that they barely know the syntax to jQuery and if I take the library away they will stutter and sulk in the corner. Be realistic about what you’ve done, and we’ll tailor our expectations accordingly; call yourself a “10” in Python, and we’ll have Guido van Rossum interview you.
Know your computer science
It’s hardly a secret anymore that Google will ask its interviewees CS-type questions, from algorithms to runtime analysis to data structures. For whatever reason, we have people with 15 years experience, having forgotten what they learned in school, applying and then completely freezing up when we touch on these subjects. The truly outrageous ones will attempt to stall the interviewer while they frantically try to Google an answer.
If you’re not going to bother reviewing CS concepts or think that stuff is beneath you, you will probably not pass the phone screen and you’ll definitely not pass the onsite. I’m not even necessarily saying that this is a good metric – I’m a fan of giving small interview projects and pair programming for technical screening myself – but this is what Google does and you simply won’t get past the interview process.
Be comfortable with coding without a compiler/interpreter and in a shared document
Some programmers live by their REPL shell, and some hate having another programmer look over their shoulder while they code. Unfortunately, we use a shared Google doc to test your coding abilities, so you’d be better off being used to the feeling of coding in a shared environment.
On a related note, try to remember the syntax and API’s of your favorite languages and know the structure of the code, and make sure to list those on your resume. I’m personally lax at getting the exact syntactic structure correct in a non-computing environment, but I know some interviewers will ask for perfect code in a language the interviewee claims they’re familiar with, and subsequently point out compilation errors. At the same time, I do make note of programming quirks1, and if you’re borderline those might make a difference.
Keep talking
For a lot of programmers, it’s unnatural to keep talking as they’re thinking about a problem or writing code. If you’re stuck on a problem, though, the easiest way to move forward is to tell the interviewer what you’re thinking, or even if you can’t think of anything at the moment. We want to move forward with the interview too; the more we get to ask you, the more data points we have.
And really, it’s in our best interest to help you get to a solution, even if you completely bomb the question. We want you to feel a sense of accomplishment and learn something, even if we don’t end up hiring you, so you’ll get a good feeling about the company and in the best case scenario tell your friends. I’d like to think that the slightly more positive interview feedback we’ve been getting on glassdoor.com means we’ve been doing a better job.
Ask us about our job, our work, and the company
At the end of the phone screen, we’re supposed to give you a few minutes to ask us any questions; take this opportunity to figure out whether Google sounds like a place you’d want to work. Not only is it important for you to figure out whether the environment and atmosphere jibes with your personality, it also tells us that you’re somewhat serious about the process, and you care about the culture as much as we do.
I remember back in the dark days, post-dotcom crash, when my company would send me to a career fair and I would be stuck listening to a guy with his 5-page CV, telling me that he didn’t care what he did as long as he got a job. Don’t be that guy.
Certainly, a lot of this advice isn’t specific to Google; our interview process is pretty standard for software companies, especially around these parts. That said, interviewing is totally unnatural for software engineers – I’ve always complained that most interviews tend to be artificial, administering a series of tests that bear no resemblance to the code you’d actually produce on the job. And I make no excuses for some of our interviewers who seem to have a chip on their shoulder and will put down candidates because they deem them unworthy of being a Googler, perhaps because they don’t have a Ph.D in CS or they don’t have a handful of github projects under their name.
If it’s any consolation, at least we don’t ask gotcha riddle questions anymore. Those were especially offensive.
E.g.,
++ivs.i++,lengthvs.length(), ("x" == x) vs. (x == "x"), etc.↩
I’ve been working as a contractor for several years and am constantly surprised by interviewers asking me questions about obscure topics or coding references. Stuff you would never memorize. Some interviewers act like you’re never going to have the internet to reference anything and all your knowledge is locked inside your head.
Indeed. The more banal the coding questions, the less likely I am to want the job. I’ve cut short interview processes for asking me things like “which of the following is not a reserved keyword in C#?”
Really? You want me to tell you what is not a reserved keyword in the primary language I was using for the last five years? I guess the rest of my resume wasn’t very interesting, then.
Algorithm questions are a little more fair game–I ask these, just because it’s hard to figure out how else to gauge someone’s intelligence. But they’re imperfect at best–I think I’ve only had to write a sorting algorithm myself twice in the last some-odd years (and if you’re doing it much more than that, you’re probably doing it wrong).
The issue I have with Allen’s essay isn’t that it’s inaccurate–this is, in fact how it is at companies like Microsoft and Google–but that it doesn’t ask the hard questions of how we, as interviewers, can do better. I am a pretty good interview candidate, but I know I’m a horrible interviewer. What I really want to know is how to do that better.
Yea, I agree – getting interviews right is hard, and I certainly wouldn’t call myself an expert. I’m going to think about it a little bit, though, and perhaps write another article on it.
I guess I also have little faith in my ability to judge which of my coworkers are good and bad even after working with them, so judging candidates is a lost cause. Incompetence is noticeable, and brilliance usually shines through, but the difference between moderately good and moderately bad? As an IC, I don’t need to recognize this, but it does make me think I’d be a shitty manager.
To draw an analogy from baseball, most of the greatest managers were not great ballplayers themselves. (There are a few exceptions, such as Joe Torre.) What made (makes) these managers good is that they know how to maximize the production of their ballplayers. They understand the importance of teamwork; of recognizing when they have to make key strategic decisions (do you leave the starter in to face one more batter; do you steal a base; do you sacrifice a runner over in the hopes of scoring a single run even though you are giving up an out). Good managers realize there are going to be days when their starting pitcher is roughed up; when their #3 hitter is going to take an 0-for-4; when their Gold Glove fielder boots a routine play. They understand that a baseball season is 162 games (at least), so they need to manage for the long haul, not just focus on individual games or game situations.
At least from my perspective, the types of interviews that are given do not test people’s ability to do jobs in realistic situations. Especially for people with lots of experience — they don’t commit implementation details or facts to memory. Instead, they recognize certain situations call for certain types of problem approaches, so they reference appropriate sources as solution aids.
For those of you who interview people, and wonder how candidates get things wrong that they hadn’t done in 5,10, 15 years, think of something that you do not do regularly, but someone else thinks is important. If these things had come up on your interviews, you might not be working where you are right now.
The other issue is that there is so much competition for jobs right now (at least at companies that have achieved a visible amount of success) that it’s basically a crap shoot whether you will get a particular job.
Speaking as one of those interviewers known to ask language syntax, if you claim a decade’s experience, but cannot tell me which of abstract, public, and closure are reserved n the java version you claim to have used, I am going to have doubts about your resume and background. I have had people interview who could not write a line of code in what they claim as their favorite language. Not one.
A gent who claimed a decade’s web and HTML development experience could not tell me what a doctype did, or give an example of a valid HTML page with a head and body tag.
Don’t get insulted by a basic question. Assume your interviewer is spot checking the resume for blatant lies, and for some way to find the things you actually care about. And assume he has seen those lies before.
Nice Points!! But yeah i have to agree with Crash too.
“And I make no excuses for some of our interviewers who seem to have a chip on their shoulder and will put down candidates because they deem them unworthy of being a Googler, perhaps because they don’t have a Ph.D in CS or they don’t have a handful of github projects under their name.”
Very good points. I think these rough interview processes tend to become like a fraternity hazing ritual–having gotten through them, employees believe that those tough questions are in fact the best indicators of true merit, no matter how ridiculous they really are.
The one way I do think I have improved as an interviewer over the years is that I try more and more these days to be sympathetic and helpful to the candidate. We talk the problem over, discuss reasonable solutions, and look at his code together. In the real job, he’s not going to have me peering over his shoulder making smart-ass comments, but he will have me down the hall to help him out if he gets stumped. What I want to know is whether, with that help, he can be a great employee.
For what it’s worth, my own experience interviewing has been that those gotcha questions seem in decline. I think some of that is a real trend and some of that is that I’m a bit more senior now, and people are more interested in asking me about my experiences than in getting my goat. For a college hire, unfortunately, I think there’s still a lot of goat-getting going on.
I think I would enjoy interviewing at Google if I could meet Guido. Still, I dislike phone interviews. So will probably will never see the inside of google plex.
Yea, or Jeff Dean. Although, I’d imagine you would have to be on their level before you could request such an interview.
And Allen you better stop posting all this on the internet, you are not a very competent interviewer to start with and you are now being an unworthy employee.
I’m confused – I haven’t posted this article for months, nor have I interviewed for Google for months (I’ve left the company more than 6 months ago).
As to my competence in interviewing, I wouldn’t know how *you* could know either way unless I personally interviewed you, and if I did and you found problems with it feel free to contact me directly.
What is the “quirk” with (“x” == x) vs (x == “x”)? I’m not sure which language you’re referring to, but in most languages I’m used to (C, Python) string comparison is an abelian operation (order doesn’t matter). It’s ambiguous which is better if equality holds either way. (“x” == x) has the advantage of returning an error if you accidentally type an assignment, but the (x == “x’) is readable and arguably canonical. Personally, I’d pick whatever style you see in the source, but I don’t see how either option is advantageous over the other.
Exactly why it’s a “quirk” and not a hard-and-fast rule – you may be writing your code as (“x” == x), or subconsciously using ++i or i += 1 instead of i++, and it wouldn’t matter in most languages, but it’s a sign that you’ve been burned in the past and understand the underlying issue. (another example I just thought of, some assertion libraries’ assertEquals() return the value of the first argument when the comparison fails)
I can’ speak for other languages such as c or python, but in Java (x==”x”) may result in a NPE.
(x==”x”) can never give you an NPE in Java. x.equals(“x”) can.
What happens if you typo and forget an ‘=’? One of those alternatives is safer than the other, especially in weakly-typed languages.
Still, I and most other developers I have seen still do (x==”x”) simply because it feels more natural.
I wonder if there is a possibility in some languages that if x is in fact a property than the execution of the property get will occur at a different point in the compiled code thus causing a different result in certain conditions (threading/event triggering issues perhaps?). Though if your code is reliant on something that side-effecty then it’s probably way too brittle and needs a heavy redesign.
Arguably, in K&R, which is considered a quality reference work for C programmers, (x == “x”) is liberally used. I can’t speak for C++, having done very little programming in it (and none recently).
cracking google interview is pinnacle of job interview specially in programming they really test your so called programming skill not the language skill like Java and C++ . there questions requires real brain storm and there followup are even more tougher but noways there are lots of resource available so don’t forget to use those before heading for google interview.
Javin
How Classpath works in Java
You have to be joking. I went to a google interview and they asked me three easy coding questions. I didn’t do well and have no defense except for I was nervous and trying to write python with a cryon on a wall. But when the interview finished before being asked a single question that requires real thought, I was a very surprised. To top this off, I asked my interviewer what its like to work for google, which he then used as an opportunity to brag about his awesomeness. I wasn’t impressed to say the least…
Let’s say I had a phone screen or in person interview with Google and it went badly, for whatever reason. Would that at all inhibit my chances later on, say a year or so down the line? Or even with another branch or section of Google? I really would like to work there but I’m not sure my current skill set is up to par… yet.
I don’t think it should, unless your feedback is laced with big bold “DO NOT HIRE THIS PERSON UNDER ANY CIRCUMSTANCES” disclaimers. Which you wouldn’t get unless you personally insulted the interviewer with your intelligence.
So yea, you’re fine. =)
“quantify your experience with various technologies”
Do you think it’s worthwhile to list the languages with which you are only peripherally familiar or ones that you haven’t used in the last, say, 5 years? As an example, I’ve done a little php hacking now and then to tweak pre-packaged web sites I’ve set up, but I wouldn’t even know where to start from scratch. Or, I used a lot of Java for several classes in college, but that was 10 years ago. Would you recommend leaving that stuff out entirely, or is there a good way to word it so I can set expectations low but still have the buzzwords?
On my own resume, I separate the two by listing my favorite languages as “familiar with…” and ones I’ve come across as “have experience with…”; it should be clear esp. if you list them right next to each other. You’re right in that having the buzzwords on your resume will get you past sourcerers and recruiters, though.
Weird. Familiar is a weak word to me on a resume. Maybe I have been picking the wrong words. In a conversation, if I answer “Do you know X?” with “I am familiar with it” then I am really not inviting you to bank on my knowledge, but if I tell you, “I have good experience with X.” Now I am telling you ready to rock: lock and load with your questions!
Tip
I actually recommend that people when I’m doing phone screens. I want to see their code, not watch them do mental gymnastics trying to cope with the editor.
Generous of you. The other thing that made me giggle in Docs is a Python triple-quoted docstring:
“””don’t try this at home”””
I’ve probably interviewed at least 100+ people in the past 3 years for different languages/teams (not for Google though). Personally, I think it’s harder to differentiate a candidate on paper than in interviews. All the resumes begin to look the same, and most people who tries to look different just ends up sounding…weird.
I agree with Allen on most of the points he discussed in this article. It is most essential I think to talk out your thinking process; even if you don’t know the answer to something, as long as I know how you’re thinking, I can judge how well you can logically think things through or your ability to analyze a problem. Some candidates can not even see what the problem is when I ask an analytical problem or they are not solving the real issue. I don’t always care about the correct answer either, because a good candidate now may still be a good candidate tomorrow or fall slightly behind the crowd, but a candidate who can become great tomorrow, that’s what I am looking for (for full times only, for contractors though, you better know anything and everything).
Once I had this candidate who talked the problems out loud, and her thought process was good, she set up the individual steps to solve the problem perfectly, but somehow she ended up with the wrong answer albeit very close to the correct one so I gave her somewhat of a positive mark anyways.
My advise is that don’t think of this as an interview, think of of this as a discussion between experts on some of the issues that we need to solve. If you don’t know the answer, ask and find out (it just might show up on your next interview), or tell me you have tried some things that didn’t work. Remember, when Edison was asked “why do you keep trying after failing 2,000 times, before finally inventing the light bulb”, he answered “I didn’t fail 2,000 times, I found 2000 ways how not to invent a light bulb”. You really can’t fail a interview as long as you learned everything that was there to be discussed in it.
I do ask a lot of exotic coding questions that you’d use only once in a life time. I don’t base your interview on getting those wrong, but it tells me where you have explored in this language. Normally, people are satisfied with completing their job according to requirements. If requirement says loop ten times, you write a loop that loop ten times, you’re done. Rare individuals ask, hey, do I really need to loop ten times? Is there a better way? This individual will say there should be a better way….he/she will do some research on the internet, and find something called recursive functions and implement that if it fits better. Either way, he/she now knows what a recursive function is while most programmers don’t. This is obviously a simple example and most of us knows what a recursive function is; but this is the illustrate while people ask these kind of questions. If you don’t get it right, that’s ok, but if you DO, you’ll capture my attention immediately.
Be honest, you can put 5, 10 years of experience, but if I ask you the most basic question and you can’t even answer that, then you either lied or wasted all those years, either way, I don’t want you. I’ve interviewed candidates with 12 years of experience (and we verified through our network that, that person have at least 9 years of verifiable work experience solely at that company so it’s probably true for 12 years), but the candidate had problems even with the most basic questions. It does depend on companies, some companies will let you do only 1 project, after project goes live, you support this project until it is obsolete. You’d obviously have no stress what so ever but you’ll lose your skills over the years.
Your best tool in your interview is your communication (and I don’t mean perfect english). Good communication can make your lack of knowledge look average and your average knowledge look good. It is the basis for understanding what is being asked and what you are answering. If you explain something and I understand exactly what you have in mind without any loss of information and without possible mis-interpretations, you’ve got the communications down, even if you have to draw diagrams, use hand gestures, NO LIMITATIONS on how you communicate to me.
Try different things out, be confident and put your personalities into it. Good luck everyone!
” … and most
people who tries to look different just ends up sounding…weird.” Your grammar is … weird. People do not “tries” – they “try”.
Well, English IS my second language but:
“The noun people has both a PLURAL sense and a SINGULAR sense.
In the PLURAL sense, people is used as the plural of person very frequently. It is a plural count noun and takes a plural verb. It never has an –s ending; it is already plural.In contrast, the SINGULAR sense of people is used to refer to ALL the men, women, and children of a particular tribe, nation, country or ethnic group, speaking of them as a UNIT, and so the phrase a great people is indeed singular. It is a singular count noun”In the above case, people referS to the group of personS who TRIES (because the subject is A group) to look different but fails. My POINT is that it is hard to look different on paper. This also reiterates my point that communication is not about perfect EnglishI do apologize for some of the mistakes in the reply, I never intended to write such a long reply, just wanted to help; I am trying to submit my resume to Google so my friend sent me this link. I was in a hurry so some of the later parts sound weird. For those who are looking for real advice, look beyond the words and read the message!
LOL. Acrien, the message is important. But you said “most people” – so what unit exactly is “most”? Just pointing this out – I mean language and being correct in usage is important…
Good point, I didn’t go back and read everything, apologies.
Geez, it’s been so long since I had a job actually doing what was listed as the requirements or responsibilities or asked about during the interview process an actual interview would be tough to get through.
I’ve always worked in places, oh, there is a problem, see if you can solve it.
As far as the guy with a 5 page resume and willing to take any job I would surely empathise with the guy and at least try to see if he might be of use rather than just scoffing at him; but no, I wouldn’t want to be him. I mean, after all, most resumes I’ve seen, even at one page, are very poorly written. So a well written resume of 5 pages, well that says a lot to me…
“I’ll see someone put “expert in Javascript” on their resume, only to find that they barely know the syntax to jQuery…”
You must be joking. Just because someone is not familiar with the jQuery library means they do not know Javascript? Personally, I HATE having to download big Javascript librarys–most of which will be unused–just so the site can do some stupid javascript tricks like expanding image boxes or annoying accordion menus.
I generally agree that *BIG* libraries are problematic, but the jQuery site lists the minifed/gzipped size as 31kb. Also, your quote is a little out of context; the next line suggests the candidate did even worse when the library was taken away.
Is not asking any questions (as the interviewee) during the phone screens considered a show stopper ?
After all, one reads a lot about
the workplace culture at Google. Other questions about the daily work such as ‘how large data sets do you actually need to deal with’
are probably
asking for classified information…
Not at all. If there’s something we can’t tell you, then we simply won’t; it’s not like we’ll take points off because of curiosity. So go ahead, ask away.
Well, I have been through a Google on-site Interview for an SRE position. I did not get an offer (although they have contacted me again recently), and in retrospect,I believe the problem was that I have done real and often complicated work in too many different languages and think in terms of the problem and algorithmics, as I am sure I can code it later in whatever.r That means ttanstansi@tansi:disqus i@tansi.orghey are systematically screening out people with broad programming experience that regard one more language as one more tool. This strikes me as an extremely bad thing. In my experience, developers that only know how to do real things in one or two languages usually think in terms of the language and are completely unsuitable as designers or architects and often have serious trouble learning anything new.
Consequentially, I now have to explain to a Google recruiter that after that interview 2 years back I am not interested anymore. I have already exhausted the polite options. Seems to me they are really not used to that reaction.
I went through exactly the same thing (on-site for SRE) many years ago and came away thoroughly unimpressed with the interview process. I got asked a lot of what I call “manual page” questions: things I know about, have forgotten the details and know where to go for reference next time the need arises. It ended with “we’re not interested because we think you’re too broad and not deep enough.” I had to chuckle at that because I was working for a company that values people with broad experience and am still there because the problems I work on require breadth of experience to solve effectively.
Many of the people who interviewed me were much younger than I was, which put them in a phase of their careers where being “good” means depth as compensation for lack of breadth. I don’t fault them for that because I went through the same thing but was fortunate to have been mentored by people who’d been around the block and came to appreciate what that experience brings.
They’ve called back a couple of times since then, and I can’t help but think you’re absolutely right, that their recruiting process is predicated on the idea that people will fall all over themselves to work there. The recruiters also had no clue whatsoever that I’d interviewed there before. *SHRUG*
So to sum up , doesn’t matter what you did in your last 20+ years if you don’t have CS degree you will not work for Google ?
There are Google engineers with no CS degree (like me). You have to know computer science, and how to write code.
I like what I do and I’m good at it; been coding over 20 years. Made it on-site last year in Mountain View only to find that everyone there is about 29 years old. Never had a chance…..
@6123237b4d6e901a2f58e7c0bbd883a7:disqus I’m laughing right along with you! I’m damn good at what I do, but I’m too “old” for this job market. Anyway, something must have happened to the English laanguage while I was away working, because I can’t understand a damn thing the HR people say these days.
Laughing right along with you! I’d love to see all these hotshots in 20 years when they realize no one’s hiring THEM because they’re “too old.” A word of advice, kids: plan for the future, and I don’t mean hoping you’re going to score big in an IPO.
Allen,
Thanks for taking the time to share your thoughts. Very good advice.
Ridiculous company.
What an absurd company, interviewers that grill people like fish with ridiculous demands, and yet can’t even spell or use proper grammar.
they have choice to hire the best (available), so why not to grill those people? 🙂
so apparently you are going to have a company filled with CS fresh graduates? a set of newbies fairly homogeneous with no variety in style or ways of thinking or even age?
why not simply hire the next 6,000 resumes that come in as “interns” (if their resumes are vaguely in the ball park) telling them that they might not be there in 2 months, and then see who actually produces and who’s personalities you like, and let the rest go not caring what was on their original resume)… you’ll end up with maybe 500 candidates in three months, and then hire another 6,000 etc… it’s not like you pay “interns” do you? or at least you pay them very little correct? so you’ll spend a little more on managers managing for a year before you are at 1/2 speed, big deal. how is that going to be any different after hiring 6000 new people anyway?
At least now you will have a lot better/varied environment of talent after one year than a set of CS kids that probably all think too similarly (freshly taken a binary search database class) if they pass the standard interview process, this is the type of person who will pass such phone interviews anyway.
A number of problems w/ your assertions/ideas:
– No, we don’t hire just fresh CS grads. Turns out good engineers still remember their CS after having years of industry exp. I myself joined after being in the industry for 6+ years.
– I’d recken we don’t even get 50 hires after screening 6000, much less 500.
– Yes, we, like most other tech. companies pay our interns, and probably above industry average.
– You’d have to find projects self-contained enough and small enough for interns to do. Turns out those are hard to find.
– Interns actually cost a lot of money, not in salary but in having to spend engineering time to manage them. What’s the easiest way to piss off a bunch of good engineers? Make them work with bad ones.
“figure out whether the environment and atmosphere jives with your personality” Not to focus language trivia, but you mean “jibe”, not “jive”. And certainly not “jives”. http://www.wsu.edu/~brians/errors/gibe.html
Fixed, thanks.
All you coders and programmers are lucky. Don’t complain. I was a 6th grade teacher for 7 years and got laid off. I had to buy my kid’s birthday presents at Goodwill this year. I work three part time jobs and still visit the food bank. Be happy for what you have.
After the second interview I had two years ago the arrogance and sense of general superiority I found in both the interviewers and to some extent the questions themesemlves really struck me, so much so that when last year they contacted me again, I politly refused the interview at all…
Neat post! Really helpful for upcoming Software Engineers to get a good look at how interviews are designed.
Its really a good news.Thanks for sharing this post with us.I really like this post.Keep in touch with us in future too.
Thanks for sharing these tips with us.I get it clear idea about your topic.Most of the people looking this kind of valuable tips.
Well written post.You have done a great job by sharing this information with us.Its really an informative post.Keep in touch with us in future too.
All the point covered in the article are very useful not only for interview in Google but in any software company. I just completed my graduation and going through some interview in local companies. I find them little tough specially with cross platform questions. I just imagine how tough a interview can be in Google. 🙂
Brilliant blog. Definitely given me something to think about.This is my first time reading this blog. Definitely won’t be my last though, really enjoyed it.
Interesting! I always love hearing about new ways to do sentiment analysis.
With the help of Google any kind of information we can get.I like this blog.Thanks to share.
Very informative post about rugs.I enjoyed reading post.Thanks for sharing such useful post.
Really great to finally find a blog I can relate to. Just my kind of thing.I hadn’t thought of some of these Interesting piece.